昨天聊的是商业底线——我们不从应用内购、广告、交易或收入中抽成。今天说点具体的：最新发版里最实在的平台能力。PR #5281 直接给 com.codename1.car 包塞进了 Apple CarPlay 和 Google Android Auto 支持。

先搞清楚这不是什么。CarPlay 和 Android Auto 不是把你的 Codename One Form 照搬到第二块屏上。它们是面向行车安全的模板系统。苹果和谷歌决定了车里能出现哪些模板、页面最多能显示几行、哪类应用才有资格接入，以及哪些操作在驾驶中是安全的。你能做的，就是在这套严密的壳子里填内容。

打开网易新闻 查看精彩图片

Codename One 现在做的事情，就是用一套可移植的描述方式，让你一次写出这些模板。核心玩法很简单：声明一个 CarApplication，当车机连接时，应用返回一个根 CarScreen。每个 Screen 再返回一个 CarTemplate 子类——列表、网格、面板、消息、导航、正在播放，总共六种，刚好覆盖车载场景的基本盘。

看一段代码就明白了。定义一个 LibraryScreen 继承 CarScreen，在其 onCreateTemplate 方法里返回一个 CarListTemplate，设个标题，往里面加行。每一行可以带文字、可浏览标记、点击回调，以及跳转新 Screen 的导航操作。这段代码在 CarPlay 侧会映射到 CPListTemplate，在 Android Auto 侧则映射到 ListTemplate。网格行列对应 CPGridButton 和 GridItem；正在播放模板直连系统媒体浮层；导航模板给你预留了控制区和预计到达时间栏位，地图移动浮层已搭好脚手架，仍在填充中。

导航和生命周期也没有落下。CarContext 提供了一套车机端页面栈，pushScreen、popScreen 随手可用，还能让 Screen 调用 invalidate 或弹出 toast。CarScreen 自带了创建、恢复、暂停、销毁四个钩子，CarApplication 则放出连接和断开的全局回调。在车机连接时才需要启动的位置流，正好就能挂在这些回调里启动和停止。

对不使用车机功能的用户，这套东西零成本。构建系统会扫描字节码，一旦检测到 com.codename1.car 的使用痕迹，就注入原生桥接线；如果完全没碰，应用包体里连一丁点多余的代码都不会带进去。对于一个既要服务桌面、移动端、Web，又不想给任何平台增负的框架来说，这个设计比多出一个轻量模块本身更有价值。