解读

面试官问“灰度发布”并不是想听一个标准定义，而是考察候选人是否真正在 Android 交付链路上“踩过坑”。国内 App 发版节奏快、渠道杂、政策多变，灰度发布是降低线上事故的核心手段。回答时要体现三点：

1. 国内真实场景（应用商店、热更新、合规备案）。
2. 技术落地细节（服务端开关 + 客户端埋点 + 回滚能力）。
3. 数据驱动闭环（分群、监控、决策）。

只讲“按用户 ID 取模”会显得太学生气；必须提到“如何圈选人群、如何实时回滚、如何与合规要求对齐”。

知识点

1. 灰度发布（Gray Release）
   在正式全量之前，按可控策略把新版本交给部分真实用户验证，通过实时监控与业务指标对比，决定加速、减速或回滚。
2. 国内 Android 灰度关键约束
   • 应用商店灰度：华为、OPPO、vivo、小米均提供“分阶段发布”接口，可配置百分比、地域、机型，但最小粒度只能到“渠道包”级别，无法按业务标签细拆。
   • 热更新灰度：Tinker、Sophix、QZone 方案可在 24h 内完成代码/So 修复，但受 2023 年 4 月工信部《App 备案管理办法》限制，热更新必须走“可验证、可回滚、可审计”的闭环，且禁止动态下发核心业务逻辑。
   • 服务端开关灰度：Firebase Remote Config、阿里灰度、美团 Shark 平台，通过云端配置把“功能开关”+“人群规则”下放到客户端，实时生效，回滚秒级。
3. 用户分组维度
   • 静态属性：渠道、品牌、系统版本、省份、运营商、App 首次安装时间、是否登录、会员等级。
   • 动态行为：昨日活跃时长、崩溃次数、功能使用次数、支付成功率。
   • 业务标签：骑手/乘客、学生/白领、风控白名单、企业内测账号。
4. 分流算法
   • 白名单优先：内部员工、核心用户先走灰度。
   • Hash 分桶：对 userId + 版本号拼接后取 CRC32，再对 100 取模，可保证同一用户在同一版本始终进同一桶。
   • 时间窗口：按自然天切流，避免跨日指标污染。
5. 监控与决策
   • 技术指标：Java Crash、Native Crash、ANR、卡顿率、冷启动耗时、GC 次数、电量消耗。
   • 业务指标：关键路径转化率、GMV、次留、客诉量。
   • 熔断阈值：连续 30 min 内 Crash 率 > 0.3% 或业务指标跌幅 > 5% 即自动回滚。
6. 回滚手段
   • 服务端开关关闭 → 客户端下次拉配置自动回退到旧逻辑，无需重新发版。
   • 若灰度包本身存在启动 Crash，则通过应用商店“紧急下架”接口把灰度包置为“不可升级”，用户无感知回退到上一正式版。

答案

灰度发布是指新版本在全网发布前，先按策略挑选一小批真实用户进行验证，通过实时监控决定继续放量或立即回滚，从而把风险降到最低。
在国内 Android 环境下，由于应用商店分散且热更新受备案约束，通常采用“服务端配置开关 + 商店分阶段包”双轨方案：

1. 人群圈选：
   • 先用白名单把公司内部员工、种子用户放进灰度池；
   • 再按渠道+省份+机型三维度在商店后台配置 5% 放量；
   • 同时对核心功能使用服务端开关，按 userId 哈希取模 10% 进行二次切流，实现更细粒度控制。
2. 实时监控：
   • 技术上通过 Firebase Crashlytics、美团 Logan、阿里 SLS 采集 Crash、ANR、卡顿；
   • 业务上把支付成功率、次日留存写入埋点，每 15 min 与上一正式版同期对比。
3. 决策与回滚：
   • 若任意指标劣化超 5%，立即在灰度平台关闭开关，30 s 内全网生效；
   • 若灰度包自身启动崩溃，调用华为/小米开放 api 把该版本标记为“紧急下架”，用户下次打开商店即提示“已安装最新版”，自动回退到上一正式版。
4. 合规收尾：
   • 灰度结束后输出《灰度报告》留存 3 年，满足工信部备案审计要求；
   • 热更新补丁需同步到国内云厂商“版本库”，确保可追溯。

通过“白名单→百分比→全量”三级漏斗，可在 48 小时内完成一轮灰度，事故率控制在万分之一以下。

拓展思考

1. 折叠屏与 5G 新特性如何做灰度？
   折叠屏机型稀少，可直接用“设备型号白名单”+“服务端开关”双锁，避免商店百分比导致样本不足；5G 场景需把“网络类型”作为动态标签，防止 Wi-Fi 用户稀释指标。
2. 隐私沙盒（Android 13 限制 AD_ID）后，如何精准分群？
   国内合规要求不可强依赖 OAID，可改用“登录用户 ID + 服务端生成 UUID”做哈希分桶，同时把“是否授权个性化”作为前置条件，未授权用户默认走正式版，避免合规风险。
3. 多 APK（abi/密度/语言）场景下灰度策略？
   商店分阶段发布是按“版本号”维度而非“apk 文件”维度，因此灰度前需保证所有 apk 同时上传，否则会出现“x86 用户拿到灰度代码、arm 用户仍是旧代码”的指标污染。
4. 灰度与 A/B 实验的区别？
   灰度关注“新版本是否稳定”，决策结果是“放行 or 回滚”；A/B 实验关注“新功能是否更好”，决策结果是“全量 A or 全量 B”。两者可叠加：先灰度验证稳定性，再通过实验评估业务效果。