共享LiteRT运行时，让应用验收多了一只时钟

Google在2026年10月28日的公告中，为LiteRT的Play服务共享运行时引入CompiledModel GPU支持；运行时可分阶段更新，不必等待应用发布。对应用团队来说，关键变化是多出了一只发布时钟。

本文讨论这种交付关系，而不是提供新的性能测试。由应用之外的组件承担维护，可以减少重复工作。但用户安装的应用版本，已不能独自说明执行环境中发生过哪些相关变化。验收依据需要回答测了什么、在哪里测、何时测，而不能只留下“这个构建通过了”的结论。

用户购买的是体验，不是一次成功调用

设想一款给商品照片去除背景的手机工具。用户希望在离开编辑页面之前拿到可用图片，开发者的测试却可能只检查模型是否返回有效张量。两种检查都有价值，但回答的不是同一个问题：计算成功，仍可能意味着等待过久、视觉结果不稳定，或操作流程衔接得不好。

CompiledModel指南列出17.0.0依赖，并提供显式同时配置GPU与CPU的方式，在GPU加速不可用时回退到CPU。因此，回退路径应作为一种产品体验接受检验，而不能被当作所有设备提供相同服务的证明。

对上述假想编辑器而言，较慢路径处理一张静态照片也许可以接受，持续实时预览却未必合适。这是用来解释设计取舍的例子，不是LiteRT实测结论。验收标准取决于产品承诺的交互方式。如果持续处理不合适，应用可以考虑提供静态图片模式，但前提是这个替代模式真的被设计、实现和测试过。返回了结果，不能替代团队决定用户应该看到怎样的体验。

留下能够解释变化的证据

我们建议把应用构建、模型文件、输入预处理、设备与系统信息、配置的执行路径、观察日期和输出测量联系起来。这是一套编辑部提出的证据思路，不是Google认证要求。运行时信息只能通过受支持的接口获取；接口没有暴露的标识，应作为证据缺口保留，不能凭空补成一个版本号。

这样的记录首先用于排除轻率归因。同一个模型在一次应用更新后看起来变差，团队不应立即认定共享组件出了问题。图片缩放、后处理以及设备条件，都可能改变比较结果。用受控样本重复观察，比拿两个互不相关的用户反馈直接比较，更有助于判断原因。反过来，只冻结应用二进制，也不能证明周围所有条件都没有变化。

证据还需要保留失败的含义。一次测试未达到体验要求，可能意味着某种使用方式暂时不应开放，并不自动意味着整个模型不可用。把问题定位到具体交互和设备条件，可以避免一边过度承诺兼容，另一边又因为局部失败而否定所有场景。验收的价值在于缩小不确定性，而不只是生产一个绿色标记。

覆盖范围不必等于穷举所有组合。更有用的做法，是说明哪些组合已经支持产品承诺，哪些仍没有足够依据。团队可以优先验证功能不可或缺的设备与交互，再将其余组合明确留在尚未验证的范围内。这比没有复现条件的“全面兼容”标签更诚实，也更便于后续补充测试。

恢复方案要符合实际控制权

当组件分开交付时，不应假设回退应用构建就能让整个环境回到原状。这是运维层面的推论，不是在声称Google提供或拒绝某个特定回滚接口。团队需要分清自己真正掌握的控制手段，以及哪些恢复动作依赖另一个分发方。

应用层可以考虑暂时关闭可选功能，或提供已经测试过的替代流程。但这些不是LiteRT自动附送的能力，运行时错误也不会凭空生成第二套实现。提前设计这些响应，才能明确谁有权启用、什么证据足以恢复正常体验。恢复于是成为有工程证据支撑的产品决定，而不是一句无法兑现的“全部回滚”。

这种区分也影响团队内部的责任安排。维护模型的人未必负责手机界面的等待状态，管理发布的人也未必能控制外部分发节奏。若各自只确认自己的局部检查通过，最终可能没有人验证完整用户旅程。把验收记录交给能够对整段体验作决定的人，比增加一个孤立的技术指标更重要。

迁移之前还有架构选择。当前官方概览要求需要NPU加速、自定义运算，或必须运行在没有Google Play服务设备上的应用使用独立版LiteRT。分发要求因此应当在选型时进入讨论，而不是接入完成后才发现它限制了目标用户。

看重集中维护、又能持续验证体验的团队，可能适合共享运行时。另一些团队的部署条件，则可能要求更自包含的交付方式。两者都不能免除测试，只是把不同部分的工作交给不同的责任方。判断依据应是实际部署与恢复需求，而不是抽象地认定共享或打包总有一种更先进。

这次发布最值得推动的，是把责任写得足够具体：Google维护共享执行组件，应用仍对客户能否正常使用某项功能作出承诺。可靠的采用方式，需要用带日期、可复现的证据连接这两端，并让恢复路径真实存在于产品之中，而不是把一次接入成功当成兼容性已经永久解决。