7 月中旬，手中这台 OPPO Reno 10 倍变焦版终于收到了 6 月更新补丁，虽说在与世隔绝的国内安卓生态内保证「虽迟但到」的安全补丁更新已然不易，但个人比较在意的自动填充框架依然缺席。
这里我们不妨暂时停止抱怨：这篇文章在讲的自动填充框架究竟是什么？
使用 Chrome 浏览器的用户应该不会对 Chrome 的密码保存和密码自动填充功能感到陌生，如果我们此前允许过浏览器保存某个网站的登录信息，下次浏览这个网站时，Chrome 就会弹出自动填充选项来帮助我们一键填好用户信息。
借助一些密码管理应用，我们在 Android 平台上也能实现类似的使用效果（早期实现方法我们后面会提到）。而 Google 为了让 Android 平台上的自动填充体验更加统一、规范，在 Android 8.0 中正式引入了系统级的自动填充框架。
适配了这一特性之后，诸如 1Password、LastPass 这类第三方密码管理应用就能在无需调用无障碍功能的前提下进行登录信息一键填写，即便是复杂密码也能避免手动填写造成错误。
因此在搭载了完整 Google 服务的 Android 8.0+ 设备上，你也许会在 语言和输入法 设置中的 自动填充服务 选项下看到内置的 Google 密码填充，这个服务与 Google 自家的密码管理高度整合，甚至能够调用我们在其他设备的 Chrome 浏览器中保存的登录信息；如果你觉得 Google 密码填充服务提供的功能有限，如不支持两步验证密码、不支持密码生成等，也可以安装上面提到的 1Password 这类第三方密码管理应用，它们在第一时间适配并跟进了自动填充框架，安装后我们就可以在 自动填充服务 设置中进行选择了。
使用搭载了自动填充框架的设备进行初始设置是一种享受。
一方面，当前 Android 平台鲜有将应用数据备份与还原做好的 OEM 厂商，当我们拿到一台新设备还原好应用，接下来还需要一个个应用进行登录和设置，自动填充框架对这个繁琐的流程进行了大幅简化，登录信息输入界面出现的同时，点击输入框下方出现的自动填充服务填写选项即可一键填写登录，节省大量时间。
另一方面，系统级自动填充框架能够在不依赖系统无障碍功能的前提下进行密码填充，对那些开启无障碍功能后喜欢自作聪明在状态栏塞下「无障碍」三个大字挤占空间的定制系统而言可谓「福音」。
读到这里，如果不考虑 OEM 厂商对无障碍功能的视觉呈现处理方式不妥，你可能会问为什么我们不用「老一套」、借助 Android 系统近乎「万能」的无障碍设置进行密码自动填充呢？毕竟上面提到的密码填充应用在适配自动填充框架的同时大多也依然保留着无障碍填写功能。
这里就涉及到了另一个很多人都感同身受，但鲜有人愿意深究原因的问题：为了使用某些应用而不得不开启无障碍功能后，你有没有留意到自己的设备变得不那么跟手了？
无障碍会让你的 Android 机变卡，这种卡的具体表现或为多任务动画的掉帧，或为进入应用抽屉时那一瞬的反应迟滞。这些本不该有的体验劣化，其实都是某天你无意中为某个应用开启无障碍功能带来的后果。
但这里的卡顿却是被 Google 官方所认可的——早在三年前就有用户注意到了无障碍功能对 UI 性能的影响并提交了 BUG 报告，而 Google 方面给出的回复简单明了：
无论在哪个版本的 Android 操作系统中，无障碍服务启用时总会带来「卡顿」。这是因为除了标准的 UI 界面之外，系统还必须向无障碍服务提供大量额外信息来为那些真正有使用障碍的用户保障使用体验。
Google 认为无障碍功能带来的卡顿是理所当然的，XDA 也就此事做过 报道 并在这份报道中对个中原理进行了详尽的阐述。
具体而言，任何一个应用与无障碍功能的「交接」，都是基于对 无障碍活动 的实时监控来完成的。在没有无障碍服务被启用的状态下，系统并不会向任何应用收集和发送无障碍活动，而一旦有无障碍服务启用，Android 系统就会根据具体请求帮助应用监控和收集所有符合条件的无障碍活动。
以我们在这篇文章中所讨论的密码自动填充服务为例，1Password 这类应用在启用基于无障碍服务的密码自动填充功能时，用到的无障碍活动主要有两项：
其中扫描屏幕内容是最为关键的无障碍活动，在 1Password 开启无障碍服务后，系统会帮助在后台持续扫描前台出现的窗口内容并提交给 1Password，1Password 随后从这些提交过来的信息中索引登录信息填写区域，出现符合内容的填写区域时则弹出自动填充窗口。
将以上无障碍活动内容的传递流程即时化，我们也就不难想象无障碍功能对系统资源的请求负载了。除了界面变化，图标、按键、文本……为了让真正需要的用户顺畅使用 Android，无障碍服务需要对 UI 界面中的内容进行一次又一次的即时「扫描」，然后将得到的信息反馈给各种各样的无障碍工具，如 Talk Back、随选朗读、实时字幕等等。
所以尽管 Google 也清楚无障碍功能会带来 UI 性能的锐减，但他们并不打算对这个问题进行修正，或者说现阶段他们也没有更好的解决方案。Google 能做的，是对使用无障碍功能的应用进行肃清：他们曾在 2017 年年末对那些滥用无障碍功能的应用进行过一次 清理，但收效甚微，甚至还因此「得罪」了不少开发者和用户。
因此最终 Google 只能选择从 Android 系统层面解决那个呼声最高的需求——密码自动填充，Android 8.0 正式引入了系统级的密码自动填充框架，为密码管理应用开辟了一条无障碍功能以外的「新路子」。1Password、Dashlane、LastPass 等知名密码管理工具也在第一时间进行了适配，在当前市面上的主流密码管理工具中，我们几乎看不到还没适配这一特性的密码管理应用。
显然，无障碍功能并不是解决密码自动填充这一需求的最佳选择，毕竟这也并非无障碍功能设计之初的本意。在我们讨论系统级自动填充框架之前，传统的自动填充方案就只剩下了输入法。
类似 1Password 这样的应用都提供了密码自动填充输入法作为补充手段，在登录信息填写界面，我们只需要将输入法切换到 1Password 键盘，即可通过长按空格左侧的 1Password 图标呼出自动填写选单：
相比之下，密码键盘仅增加了少量操作成本，对 UI 性能又不会产生影响，对于系统版本为 Android 8.0 以下的用户而言应是首选。但问题在于，很多 OEM 厂商在自家系统中都内置了由第三方服务商提供了定制版输入法，而并非所有的定制版输入法都能像 GBoard 那样方便快捷地在不同输入法之间快速切换。
现阶段 ColorOS 6 内置的搜狗输入法定制版默认就没有输入法快速切换功能，同时 ColorOS 6 也没有在通知栏提供用于输入法切换通知，为了在设置应用时快速录入登录信息，我们必须得在系统设置中不断翻查才能来回切换输入法。
这种设计让输入法切换变成了一件令人头疼的事，所以问题的关键还是回到了用户选择权这件事情上。对用户而言，无论密码填充输入法还是系统级自动填充框架，相较对系统 UI 性能影响巨大的无障碍功能，它们都是更好的选择，而 OEM 厂商在对 Android 系统进行定制的过程中，有意或无意中将这些应有的便利给抹除掉了。
考虑到那些系统底层不能满足系统级自动填充框架要求的用户，输入法切换这件事理应变得简单易用一点；而对那些 Android 8.0 及以上系统版本的用户来说，OEM 厂商更加没有理由「阉割」掉系统级自动填充框架。因此我们也在此倡议：国内的 OEM 厂商在定制系统的同时请尽量保留这样的功能，把选择权交回到 Android 用户自己的手上。
替用户做决定不一定总是坏事，但在追求「和而不同」的 Android 生态内，在系统级密码自动填充框架这件事情上，我们反对这样的做法。
你最反感安卓手机厂商「阉割」哪些功能？欢迎在评论区留下你的看法。
关联阅读：Android O 真叫奥利奥，这 15 个重要新变化你该知道 | 具透
参考链接：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。