解读

面试官问的是“禁止未经审核的热更新”背后的商业、合规与技术考量，而不是“热更新技术怎么做”。
国内候选人常把焦点放在 Tinker、Sophix、Robust 等框架实现上，却忽略 Google 作为平台方的立场：

1. 大陆以外市场几乎 100 % 依赖 Google Play 分发，Google 必须对最终用户体验、品牌声誉与法律风险兜底；
2. 国内监管环境虽不同，但出海产品一旦触发 Google Play 政策，会直接下架甚至封号，业务损失巨大；
3. 企业面试希望听到候选人能把“技术可行性”与“平台合规”分开讨论，体现对双轨市场（AOSP+GMS）的理解深度。

知识点

1. Google Play 政策 4.8：任何“可远程修改 APK 字节码、资源或逻辑”的机制均视为热更新，必须走 Play 审核；
2. 合规链条：开发者账号 → 签名证书 → 应用声明 → 用户可见内容 → Google 后端扫描（Safety Center、Play Protect）；
3. 技术红线：
   • 禁止动态加载 dex、so 并替换原有组件（绕过签名验证）；
   • 禁止通过 JavaScript 引擎或插件化框架动态下发可执行脚本；
   • 禁止利用 Reflection 或 JNI 修改 Zygote 已加载的类；
4. 例外路径：
   • 资源包（asset）更新，但不得包含可执行逻辑；
   • ABTest 框架使用 Firebase Remote Config，只能下发开关，不能下发代码；
   • WebView 内纯前端更新，需满足 CSP、不允许调用私有 API；
5. 国内对比：国内商店无统一签名强制校验，厂商 ROM 允许插件化，因此热更新普遍；出海包必须拆分为“国内 flavor”与“海外 flavor”，否则一经举报即下架。

答案

Google Play 的核心职责是保证用户在任何时间下载到的 APK/AAB 与后台审核过的二进制完全一致。
第一，安全：热更新可能动态下发恶意代码，绕过 Play Protect 的云端扫描与设备端沙箱，形成“日抛”木马；
第二，合规：欧美对数据欺诈、博彩、加密货币有严格法律，若 App 通过热更新切换业务形态，Google 作为分发平台需承担连带责任；
第三，生态信任：用户依赖系统更新提示与权限复审，热更新让“静默变业务”成为可能，削弱平台透明度；
第四，技术一致性：Android 的签名机制仅保证首次安装完整，后续若允许自行替换 dex，会打破 Keystore、Attestation、SafetyNet 的信任链；
因此 Google Play 明确禁止未经审核的热更新，开发者只能使用官方提供的 Update API 或 In-App Update 强制流程，走完整版本升级通道。

拓展思考

1. 灰度策略：海外灰度应使用 Google Play 自带“分阶段发布”（Staged Rollout），结合 Crashlytics 实时监控，而不是私自下发补丁；
2. 双包维护：国内渠道包可集成 Sophix，但出海包必须移除所有热更新 SDK，否则签名指纹会被 Google 扫描到，触发下架；
3. 动态模块：Dynamic Feature Module 与 Google Play App Signing 结合，可在审核框架内实现“按需下载”，是官方认可的“动态交付”方案；
4. 面试加分：能提到“2021 年 Google 下架 120 万违规应用，其中 47 % 因隐藏热更新能力”，并给出自己项目里如何配置 CI 任务自动剔除 tinker*.so，可体现工程化落地能力。