10 月 15 日，Google 向自家 Pixel 机型推送 Android 15 正式版更新，从 8 月最后一个 Beta 测试版发布，到 9 月 4 日 Android 15 正式版源码向 AOSP 推送，Google Pixel 今年的正式版推送着实让 Pixel 用户等了许久。

但即便有版本特性、首轮更新、加上独家定制体验等多重 buff，Google 最终给 Pixel 用户呈上的更新内容也可以说是毫无惊喜，甚至还略显敷衍。

在社区爱好者和热心开发者的携手推动下，Android 15 终于为原生 Android 的中、日、韩（CJK）文字体带来了可变字重支持。

这个特性很好理解：以往的 Android 系统并不怎么重视 CJK 字体的显示效果，当应用需要显示粗体时，系统会直接拿常规字体机械加粗渲染，无法借助字体粗细体现排版、布局层级，也很容易导致渲染出来的「伪粗体」出现笔画粘连、结构变形等问题。

相比之下可变字体就更像是气球，需要粗一点的字体，就通过字体属性加点参数多吹点气，需要细一点的字体，就通过字体属性下调这些参数（主要是 wght）打开气球嘴放点气。和 iOS 那边财大气粗直接内置不同粗细、多个中文字体文件的做法不同，可变字体既省空间、也更灵活。在 Android 15 正式版中，我们能够看到的最直观的变化就是快速设置开关、通知标题、部分 app 中的粗体标题等区域的粗体更粗，效果也更细腻了。

不幸的是因为 Unity 游戏目前并不兼容可变字体，所以这些游戏在调用系统字体时无法通过上述方式调用粗细正常的字体，而是会回落到 wght 值最小（100）、显示效果最细的版本。考虑到市面上采用 Unity 开发的应用和游戏不少，Google 在 Android 15 Beta 3 中决定直接砍掉 wght 值小于 400 的部分，并且在正式版中也没有加回来。

所以 Android 15 的中文可变字体严格来说是没有细体的。

400 往下的中文字体粗细，都是一般模样

这又是一个「在推动向上适配和保证向下兼容性之间选择后者」的经典 Android 幕后小故事，而且我去看了看 Unity 开发者社区那边的讨论，只能说硅谷公司一家亲——早在 2020 年 8 月就有开发者提出支持可变字体的建议、并且也获得了来自 Unity 员工的认可，但这事就是这样奇怪的不了了之了。

中文区用户最为在意的字体这边留下了遗憾，Android 15 本就不多的更新内容里，最为重要的部分似乎就只剩下「私密空间」了。毕竟这个功能听上去更像是大家在国产 Android 系统中司空见惯的「平行空间」或「手机分身」，而原生系统支持应用多开这件事，意义是仅次于 CJK 字体支持可变字重的。

但实际体验下来「私密空间」也并没有多么复杂，在功能上相比成熟、完备的 OEM 方案甚至稍显简陋。如果真要给 Google 这套「私密空间」定个性，那我更愿称其为三星 One UI「安全文件夹」的原生版本。

Android 15 的私密空间基于从 Android 4.x 时代就已经内置的多用户功能以及 Android 11 引入的用户类型，开启「私密空间」的本质，其实是新建了一个用户类型为私密的新用户。在这个用户角色中，我们可以登录与主用户相同或不同的 Google 账号，也可以在个人资料隔离的情况下将主用户中安装的应用一键「克隆」安装到新用户这边（仅限 Play 商店已上架的应用），并且默认情况下，跨用户分享文件、内容也只能通过系统分享选单、照片选择器等支持多用户选择的系统组件来完成。

和随时可见的常规多用户账号或工作账号唯一的不同点在于，私密空间多了解锁、锁定和隐藏三种状态。锁定状态下空间内的资料、app 和最近任务均会从前台隐去，开启「隐藏私密空间」选项后，私密空间的入口也会直接从启动器应用抽屉底部消失。

总体来说，私密空间就是一个自带隐藏状态和入口显隐设置的多用户功能增强版本。当私密空间处于锁定或隐藏状态时，空间内应用的通知、后台活动都会停止，所以它其实并不适合直接当作能够长期运行的「应用双开」功能使用——除非你愿意承受续航的负担让「私密空间」永不锁定/隐藏。

另外，即便我们可以登录与主空间相同或不同的 Google 账号来使用私密空间，但私密空间内安装的应用并不会像主空间那样通过系统备份功能同步，这也意味这私密空间更像是一次性保险箱。它真的不适合你放太多数据，甚至将其作为「手机分身」那样的主力模式来使用。

我仍然记得今年 2 月 Android 15 首个开发者预览版亮相后，某些无聊的国内媒体拿「没有 AI」批评这次更新的滑稽景象。且不说彼时距离 I/O 大会也还有三个月时间，指望 Google 向 AOSP 的部分塞自家 AI 这种期待也十分不合理。

更重要的是，从 10 月的正式版表现来看，Android 15 最大的问题反而可能是 AI 太多了一点。

10 月 30 日，Google 首席执行官 Sundar Pichai 在公司 2024 年 Q3 财报电话会议上透露，Google 现在有四成的新代码都是 AI 生成的。一时间，Android 15 中一个困扰我许久的问题似乎也在这里找到了答案：从 Android 14 的某次月度安全更新开始，Pixel 7、8 两代设备便突然迎来了幅度极为夸张的性能下降问题，以我个人在玩的《英雄联盟》为例，这类原本能跑到接近 120fps 的手游（海外版 Wild Rift），也突然变成了偶尔 60fps、团战直接掉帧到 24fps「电竞帧率」的压力测试工具。

市面上很难找到这种水平的「旗舰机」了吧？

这个问题自今年 5 月有人在 Android 15 Beta 项目中反馈至今依然没有得到修复，与此同时，不少用户也一直在抱怨的 Pixel 8 系列存在系统级滑动卡顿问题，无论是社交应用的时间流还是 Chrome 里的网页浏览，以丝滑、流畅著称的 Pixel 系统体验，在 Pixel 8 系列这里也荡然无存了。Google 这边早前虽然针对后者承诺过修复，但似乎也一直没找到靠谱的解决方法。所以 10 月推送给 Pixel 的正式版本和目前正在测试的 QPR Beta 版本都存在这个严重的性能问题。

Tensor 再弱，罪不至此。问题的转机来自 Android 开发社区一位人尽皆知的内核开发者 Sultan，他在某个给 Pixel 8 系列的第三方内核更新中修复了这个问题，并且向 Google 贡献了一条相关的代码提交，从提交内容和开发者评论来看，Google 在 Tensor 的 exynos_bts 驱动代码中用错了函数（应该用 btsdev->mutex_lock 而不是 btsdev->lock），短短六个字节的差异，让显示带宽获取到的需求（带宽投票计算结果）严重落后于实际带宽需求，直接导致包括显示控制器在内的多个处理器模块出现性能下降或功能异常。

这种错误是不是更有 AI 那味儿了？这条修复提交时间已经超过半个月，目前仍在等待审核阶段。

把视角从台前移向幕后，Android 15 最值得关注的两大重要变化应该就是预测性返回手势和「边到边」了。

预测性返回手势自 Android 13 以来便放在「开发者选项」中供开发者测试，它有一个非常朴素且实际的设计初衷：在以跨应用活动（activity）堆叠的 Android 系统中，为滑动返回手势提供一点确定性，让我们无论什么时候都能在滑动返回这个操作的决定窗口中，看看我们即将跳转的「目的地」是哪里。

关于预测性返回手势的详细分析，可以移步早前我们在少数派 PRIME 会员中发布的这篇文章：都是边缘划动，Android 与 iOS 的返回手势到底有什么区别？ ｜ 少数派会员 π+Prime

在 Android 15 中，预测性返回手势结束测试并「转正」为正式功能。如果开发者为应用适配了该特性，那返回主屏、应用内层级切换以及跨应用窗口切换等场景中都能调用系统级的预览动画；同时 Google 也为包括官方 Material Design 组件库在内的标准组件加入了预测性返回动画支持，方便开发者取用和适配。

跨应用的返回预览动画，左边这一瞥够不够预览另说，动画是好看的

虽然预测性返回手势的测试时间长，但它依然不属于 Google 要求 app 强制适配的特性，因此从 Android 13 到这次的 Android 15 正式版，除了少数 Google 自家应用，我在 Pixel 设备上见过的、适配过这一特性的第三方 app 加起来数量不超过 10 个。大家熟知的那些国内应用自然也不包括在内。

这个动画也像 Material Design 本身一样，曲高和寡

另外，个人认为这个特性所带来的影响多少也与 Android 开发团队的构想有所偏差。在实际使用过程中，返回手势的动画、尤其是拥有特别效果的 Material Design 3 组件动画成为了这个特性最为吸引人的部分。预测性返回手势提供的「目的地」预览实在是非常有限，在 iOS 用户仍为返回交互的混乱和反人类设计困扰的当下，作为 Android 用户我大多数时候其实也并没有「返回手势会将我带向意料之外的 app」这个困扰。

即便真遇到了这种情况，这不是还有多任务交互吗？

相比之下，「边到边」仍是测试中的改动，但因目前 Google 对该特性的强制执行态度，实际上要更值得我们期待一点。

扩展阅读：填满 Android 全面屏，怎么就这么难？ ｜ 少数派会员 π+Prime

适配 Android 15 的应用，同时也需要针对强制「边到边」处理好各种安全区

Android 15 中，target SDK 35 的应用将强制以「边到边」的方式渲染，考虑到大部分应用目前都不满足前提条件在 Android 15 中你依然会看见很多导航栏或状态栏「黑边」，但总归是有个盼头——就像当初的分区存储和最近的照片选择器一样，Android 开发团队这些年似乎也是想明白了，在基础体验这一块，有些东西是必须要强制执行的。

除此之外，Android 15 也为很多现代化平台特性铺好了路，如 16KB 内存页面支持、ANGLE 模块推进规划、内置 dav1d 编解码器、混合显示场景下的 HDR 余量控制等，相关细节我们在此前的 Beta 1 测试版具透文章中已有提及，这里不再赘述。这些特性在后续的版本更新中将如何发展、又会为 AOSP 生态带来怎样的影响还有待观察。

而往细了说，Google 为自家 Pixel 设备带来的新特性，除了官方博客中提到的「盗窃防护」和平板设备多用户优化，基本上就没有更多实质上的「新功能」了。事实上，从「具透」栏目最后一次更新的 Beta 2 到现在的正式版，很多肉眼可见的改动重点都放在「样式调整」而非「可用性改进」上，比如音量面板无法缩小了、电池小组件多用了几组 Material You 动态取色了、截图预览下方的菜单更圆了、甚至某个设置的名称变了……

这种调整在测试阶段都是反反复复，甚至像微调桌面主题图标配色方案这种细节还招来了很多用户的不满（在现阶段测试的 QPR Beta 中 Google 仍在调整）。

但喜欢原生系统、追求尝鲜体验的朋友也不必沮丧——不确定是不是性能部分提到的 AI 助力提高了交付效率，在为自家设备和高通旗舰处理器提供 7 年系统更新、每季度向 Pixel 设备提供 feature drop 功能推送之外，Google 又于 10 月底宣布对明年的 Android 系统更新节奏进行调整。Android 16 的正式版更新将分别在 2025 年第二和第四季度推送两次，第一次更新包含主要功能，第二次则以更新、优化和错误修复。据说是为了与之相对应的，Android 16 的开发者预览版本应该很快就会与大家见面。

尽管有着中文地区用户喜闻乐见的可变字重支持、听上去还不错的原生「应用双开」支持，以及不少让人觉得后续有所期待的平台特性铺垫，Android 15 总体上能带给人新鲜感的新功能其实不多。即便 Google 自家 Pixel 机型也是如此。

在国内主流定制系统先后减少甚至完全脱离对 AOSP 生态依赖的大趋势下，这份「新意」能够传达至你我手中「安卓」设备的相信更是寥寥。结合 Google 对系统更新推送节奏的调整，有时候你难免会感慨 Android 系统一个（或几个）版本一个样的时代或许真的已经过去了——那 Android 版本号还有小数点的日子，会不会又要回归呢？