对有一定经验的 Android 玩家来说,在下载 App 这件事情上,Play 商店依然是那个值得排除万难、能上就上的选择,没有之一。坊间还流传着各种关于「Play 版」应用的传闻:Play 版应用有 FCM 推送、Play 版应用更省电、Play 版应用没广告、Play 版应用有更适合现代设备的 64 位版本……
这种「Play 版更好」的说法究竟是科技圈的都市传说还是确有其事?为什么国产应用在 Play 商店中正变得越来越少了?
今天这篇文章,我们从一个对普通用户而言可能会有点陌生的概念——目标 API 级别入手,希望能为你解答上面所提到的一部分问题。
Android 有几种写法?对 Android 系统而言,同一个系统版本一般都对应了不止一种名称,比如对消费者而言 Android 12 是 Android 12,或者根据 Google 按照字母表顺序命名的习惯叫做 Android S;而如果 2019 年 Google 没有官宣取消甜品代号命名方式,Android 12 的甜品代号 Snow Cone 应该也会更加为大众所熟知。
针对开发者,每个 Android 版本还会被分配到一个唯一的整数标识符,这个整数标识符就是 API 级别。
针对这些不同的命名方式,GitHub 上也有人做了一个清晰明了的网站,有兴趣的朋友可以去看看。从网站提供的表格不难看出,和一个甜品代号可以对应多个 Android 版本不同——比如 Android 7.0 和 Android 7.1 都可以叫「牛轧糖」——API 级别和 Android 版本是严格对应的。
API 级别 32 只可能对应 Android 12L,Android 12L 的 API 级别也只能是 32。对于市面上运行系统版本千差万别的 Android 设备而言(你同样可以在上面那个网站中看到不同 Android 版本的累计用户占比),API 级别也成为了开发者辨别用户系统版本和应用运行环境、保证应用兼容性的重要参考。
具体而言:
- 最低 API 级别:代表了应用可以运行的最低系统版本。如果一款应用的最低 API 级别为 28,那么这款应用只能保证在 Android 9 及以上系统版本中的兼容性
- 目标 API 级别:代表了应用被设计用于运行的系统版本。如果一款应用的目标 API 级别为 32,则代表这款应用被设计用于在 Android 12L 中运行,因此也理所当然地支持 Android 12L 引入的新特性
参考链接:
- 了解 Android API 级别 - Xamarin | Microsoft Docs
- API Levels
聊完概念我们再来聊聊现象。
即便不谈应用商店本身的使用体验,在能不能下到好应用这一核心需求上,Google Play 和各种国内应用商店都有着天壤之别。
对国内应用商店而言,兼容各种鱼龙混杂、质量参差不齐的应用才是头等大事。毕竟为了赚钱,大部分 Android 设备默认的应用商店也都是自家的,如果用户发现某个应用无法正常运行,即便这个应用本身做得非常糟糕,他们往往也会将「锅」扔给手机厂商。一传十十传百,这家厂商的手机在这位朋友的圈子里就会被打上「不推荐」的评级。
Google Play 商店不一样。
在更广泛的 Android 生态里,大多数 Android 设备都会搭载 GMS 套件、不同厂商的 Android 设备也能从同一个 Google Play 商店中获取应用。因此 Play 商店作为由 Google 直接控制的应用商店,需要做好的就是平台本身:如何规范应用行为、如何保证设备安全、如何进行高效分发……
关联阅读:必须兼容 PD 快充,Google 为 Android 设下了这些新标准
相对而言,Google 的地位也更加主动一点,如果某款 Play 商店的应用无法正常运行,用户只会将责任归咎于手机和手机系统本身,或是在商店里留个一星差评骂骂开发者。
解决方案藏在目标 API 级别这个概念里。
通过读取应用开发者为应用声明的 targetSdkVersion 清单属性,Android 系统得以判断这款应用的目标 API 级别是多少,进而确定哪些新特性可以在这款应用中启用、哪些特性则需要做适当的兼容处理。
以前几年大家热切期盼的「沙盒」机制分区存储为例,应用必须首先通过清单属性告诉 Android 系统「我的目标 API 级别是 30,是支持最新特性的好应用」,系统在读取到这一声明后才会为应用启用分区存储机制;而对当时需要时间过渡的应用而言,它们在告诉系统自己的目标 API 级别不够 30 之后,系统则不会为这些应用启用「沙盒」机制。
所以在 Android 开发者网站所列出的各种 API 接口、声明数值、字符串等信息旁,也都会有一行小字说明这个功能是在哪一个 API 级别中所加入的;在 Android 13 的介绍中,Google 也有一个专门的页面来说明目标 API 级别在 Android 13 及以上(另一种说法是「以 Android 13 或更高版本为目标平台」)的应用将受到哪些行为变更影响。
两年为期、相对严格我们可以将 2017 年看作是 Google 开始着手治理 Android 系统「碎片化」问题的开始,这一年,Android 系统本身引入了著名的 Project Treble,让那些有开发实力的团队在系统大版本更新这件事情上直接转入了「快车道」。
但系统更新仅仅是一方面,系统更新带来的各种新功能,除了手机厂商的配合,还是需要应用开发者这边积极响应,才能将 Google 所预想的 Android 体验带到用户手中。
因此也是在 2017 年,Google 开始通过 Play 商店对 Android 应用的最终体验进行干预,首先在 64 位应用支持这件事情上开始了筹备。2021 年 8 月,经过四年多的筹备和过渡,Play 商店中的所有应用都具备了向 64 位设备提供对应支持的能力。