8.3 签名上架与热更新

8.3 签名上架与热更新

本节摘要：发布有双轨：正规轨（签名、商店审核、版本灰度）与快速轨（热更新，仅 JavaScript 层、两端政策不同）。本节讲清双端签名体系的构成与不可补办的纪律，走通上架材料与审核要点，再给热更新通道立下合规与灰度的规矩。这一节处理的是「门禁」：签对名才进得了店，守得住规矩才用得了快速通道。

签名：产物的户口制度

签名回答「这个包是谁的、有没有被改过」。iOS 侧是一套证书与描述文件的组合：开发证书用于调试设备直装，发布证书给商店产物签名，描述文件把证书、应用标识、设备清单（调试期）绑在一起。Android 侧是密钥库：应用包用密钥库中的私钥签名，商店靠签名验证升级包的同一性。两端的共同铁律：发布签名必须视为最高级别资产——iOS 证书过期或吊销会导致推送与部分能力失效，Android 密钥库一旦丢失，没有任何办法为原应用发布升级（除非当初启用了商店侧的密钥升级保护）。工程纪律由此而来：发布签名进独立保管（专人加权限隔离），构建机只拿授权副本，任何「重签一个先发着」的操作都要走审批。

版本号体系也要交代：对内区分每次构建（构建号），对外呈现版本号（语义化或按平台惯例），商店要求对外版本严格递增。版本号在双端要分开管理又保持对齐——「两端同版本发布」是大多数团队的默认纪律，热更新则用独立的包版本标记 JS 层变更。

上架：材料、审核与灰度

上架材料两端各有清单，共性的核心项：应用描述与截图、隐私政策链接、权限用途说明（7.3 的文案在此第二次生效——审核员真的会看）、以及应用内购买与外部支付的合规声明。审核差异值得单列：iOS 审核以严格著称，常被拒的点包括权限文案含糊、热更新能力描述不当、引导外部支付的痕迹；Android 审核相对宽松但政策逐年收紧，数据安全表单是近年新增的重点项。策略上，首次提审预留充足周期，后续版本利用加急通道处理紧急修复。

灰度发布是正规轨的安全带：Android 侧商店原生支持按比例放量与分阶段发布；iOS 侧可用 phased release 分七天递增。灰度期盯什么？8.4 的监控数据——崩溃率、关键链路转化、性能指标与上一版本基线对比，异常即熔断暂停放量。版本回滚两端都做不到「撤回已装应用」，熔断的实质是「停止继续扩散加热修救援」，这再次凸显热更新通道的价值。

图：双轨发布与灰度熔断的全景

发布检查单：把纪律固化成清单

上架的失败大多不是能力问题，是遗漏问题。一份随版本走的双端发布检查单能挡住绝大多数低级事故，条目按交付时序排列。构建前：版本号与构建号递增、变体指向生产配置、密钥与签名资产就位（8.1 的产物自检在流水线里跑过）。提交前：8.2 的三层测试结论齐备、核心链路双端真机通过、权限文案与隐私政策与实际行为一致（7.3 的对账）、上架材料截图与描述匹配新版本界面——「截图还是上一版界面」是审核意见里的常客。发布中：灰度比例计划、监控基线与熔断阈值确认、客服与运营知情（他们比崩溃报告更早收到用户咆哮）。发布后：观察期指标回顾、遗留问题入册、热更预案确认。

检查单的价值在「随版本演进」：每次事故的复盘结论都应该变成新条目——8.1 案例之后，清单里多了「产物特征自检」；每次审核被拒的理由也值得收录（「引导外部支付的痕迹」这类坑，踩一次就该免疫）。清单是团队的记忆，比任何人的细心都可靠。

热更新：快速轨的规矩

热更新的原理直白：应用启动（或合适时机）向热更服务查询 JS 包版本，发现新包则下载替换，下次启动生效——因为改的只是 8.1 流水线里 Metro 的产物，原生工程原封未动，所以能绕过商店审核。但「绕过审核」正是政策的敏感区：iOS 条款禁止应用「改变与商店提交时显著不同的行为」，务实共识是热更新只用于缺陷修复、文案与配置调整，禁止借道上线新功能或大改界面；Android 生态相对宽容，但应用商店政策同样要求透明。两条技术纪律：其一，包版本与原生底包绑定——热更包是针对某个原生版本编译的，给错底包推热更包就是 8.1 案例的同款事故，只是更隐蔽；其二，灰度加回滚——热更先放量小比例，监控异常立即回退到上一包，回滚速度是热更通道的生命线。另外别忘了 2.3 的伏笔：热更后的首次启动是「深链级」的敏感场景（新包首次执行），回归测试要覆盖冷启动加热更组合。

完整案例：一次大促前的紧急修复

背景：大促当天上午发现价格展示页在特定条件下显示旧价，后果是资损级。操作：确认根因在 JS 层（缓存策略未考虑活动价切换），原生无需变更——具备走快速轨的条件；热更包按规范打出，包版本绑定当前线上原生底包；先放量百分之五灰度，监控该页崩溃率与价格正确性埋点；三十分钟无异常放量全量，全程未经过商店审核，从发现到全量修复不到两小时。解读：这次救援成立依赖三件事——快速轨的合规使用（纯缺陷修复）、包版本纪律（绑对了底包）、监控埋点在关键页面早已就位（8.4 的伏笔）。变式：若根因在原生层，快速轨无能为力，只能走商店加急审核，两小时变两天——这正是「关键路径别押注在 JS 层」的架构理由，也回应了 1.2 选型时的发布节奏分析。

版本对齐：双端同版与例外处理

双端版本管理还有一处实践细节值得立规矩：默认「两端同版本号发布」还是「各自编号、各自节奏」？同版的好处是沟通与测试口径统一——「这个功能在哪个版本」一句话说清，测试矩阵、线上问题对账都省心；分版的好处是两端节奏独立，iOS 被审核卡住时不拖累 Android 先发。主流做法是「对外同版本号、对内构建号分离」：用户看到的版本号两端一致，构建产物用各自的构建号区分，审核被卡的一端延迟发版但保持同号。配套纪律是测试与灰度结论标注平台——「本版本 iOS 侧滞后发布」要写进发布说明，否则「Android 上没问题」的结论会被误用到 iOS 上。版本对齐是小事，但它是两端团队协作语言的一部分，含糊的代价会在每次线上对账时重复支付。

本节要点回顾

• 签名是最高级资产：iOS 证书加描述文件、Android 密钥库，丢失不可补办，独立保管；
• 灰度是正规轨的安全带：按比例放量、盯基线、异常熔断，回滚靠热修不靠撤包；
• 热更新只修不改：缺陷修复与文案配置合规，借道上线新功能踩政策红线；
• 包版本绑底包：热更包与原生版本严格匹配，错配是隐蔽的上线事故；
• 审核材料即合规文案：权限用途、隐私政策在 7.3 就该写好，审核员会看。

双轨都通了，最后一节站好最后一班岗：安全、合规与长期的守护。