最好的实时更新是用户几乎察觉不到的。
这通常意味着三个事情：
- 下载文件很小。
- The rollout is controlled.
- Recovery is instant if something goes wrong.
The same “keep OTA lean” advice that works in React Native land also applies to Capgo. The difference is that Capgo gives Capacitor teams a few extra levers: 差分更新, 频道, 自动回滚, 版本目标和可选的 端到端加密.
如果您同时使用这些功能，会得到更小的包、更快的安装和更少的运维麻烦。
即使MAU保持不变，瘦身也很重要
一个有用的Capgo-特有的细节：Capgo MAU实际上是指过去30天内联系更新服务的月度活跃设备数量。
瘦身一个包不是主要为了减少MAU计数的技巧。它更重要的是因为它改善了用户和团队实际感受到的部分：
- 在移动网络或弱Wi-Fi环境下下载速度更快
- 通过 直接更新
- 失败或回滚发布时浪费的带宽更少
- 测试或发布阶段发布时的爆炸半径更小
瘦身更新主要是关于速度、安全性和运营纪律。
1. 默认使用Delta更新
如果你只做一件事，那就做这个。
Capgo’s Delta更新 只发送版本之间变化的文件，而不是重新下载整个Web包。这是日常OTA性能的最大单一胜利。
bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta当您的QA通过后：
bunx @capgo/cli@latest bundle upload --channel production --delta如果您希望CI保持严格，使用 --delta-only 以防止有人意外切换回全包上传：
bunx @capgo/cli@latest bundle upload --channel production --delta-only仅使用 --delta-only 当您的生产机队支持Delta更新时。混合插件版本的旧设备，无法支持基于清单的Delta传递将无法下载更新。
这在使用 directUpdate的情况下尤其重要，因为用户看到的“更新已找到”和“应用重新加载”的时间差变得可见。
2. 将资产视为资产，而不是JavaScript包裹
OTA包中的大资产是静默膨胀的来源。
一些实用的规则：
- 不要在JavaScript中内联大图像或媒体，如果正常的资产文件可以做到的话。
- 将频繁更改的内容放在自己的CDN或API上，如果它不需要存储在已打包的应用程序包中。
- 注意营销图片、引导视频和只用于一次活动的资产，它们每次发布都会被替换。
- 稳定的资产应该保持稳定。通过Delta更新，未变更的文件会重用而不是重新下载。
这是保持Capgo速度不减的最简单方法之一。最糟糕的模式是微小的UI修复，迫使用户下载一大堆与之无关的媒体。
3. 保留真正的原生变化
Capgo更新了Web层：HTML、CSS、JavaScript和在运行时加载的资产。
这不是适合的渠道：
- 新原生插件
- 权限变更
capacitor.config.ts变更- 任何修改iOS或Android原生项目状态的内容。
这条线对性能也很重要。如果您不断将重大结构性变化推入OTA通道，更新策略会变得越来越重且风险越来越大。
故意使用两个发布通道：
原生通道
对于插件变更、权限变更和原生配置：
bun run build
bunx cap sync然后发布一个正常的商店版本。
Capgo 通道
对于安全的 web 层迭代：
bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta如果您最近添加了大量长期存活的资产，请定期刷新您的原生基线。一个新的商店构建包含了该新基线，这样将来 Capgo 的差异会更小。
4. 使用通道来保持发布大小小
一个“瘦身”更新不仅仅是关于兆字节。它也关于在您知道它是好的之前，更新到多少台设备。
Capgo 的 通道系统 是控制这一点的最干净的方式：
staging用于 QAbeta为邀请的测试者production对所有人hotfix用于紧急恢复
一个简单的流程如下:
- 上传到
staging. - 在真实设备上验证。
- 逐渐发布，通过控制通道或百分比发布。
- 如果健康指标下降，立即回滚。
如果您的应用程序在野外有多个本机基线，pair channels with 版本目标. 这样可以将不兼容或不必要的包裹从旧的二进制文件中排除。
对于那些想要更紧密的审查循环的团队，Capgo也很适合 预览发布这让产品、QA和利益相关者能够在不等待新内部测试版或Play Flight之前测试JS-only更改。
5. 如果您启用直接更新，优化启动硬件
您想要应用更新的速度越快，启动路径就越需要有纪律。
Capgo’s 更新行为 文档明确建议将其与Delta更新配对。 That是正确的默认值。 directUpdate 第二个防护栏是
如果您的应用程序在默认10秒的窗口内或您在__CAPGO_KEEP_0__配置中设置的任何时间内没有报告就绪，__CAPGO_KEEP_1__可以将该捆绑包标记为无效并恢复上一个良好的版本。 That回滚行为是在生产环境中所期望的，但这也意味着您应该保持启动干净： notifyAppReady().
import { CapacitorUpdater } from '@capgo/capacitor-updater'
CapacitorUpdater.notifyAppReady()docs notifyAppReady() explicitly appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:
- 在正确的位置呼叫
notifyAppReady()避免在关键路径中执行慢速启动时间的工作 - 如果您立即重新加载，则务必要小心保存和恢复应用程序状态
- 在广泛部署之前，测试坏网络和低端设备场景
- 如果您最近没有查看过它，那么"notifyAppReady"指南值得重新阅读
6. 使用内部更新通道而不是不必要的本机重建 许多移动团队浪费时间为明显是网页的更改构建二进制文件 如果更改是：
复制
复制
复制
- 复制
- UI 美化
- 引导流程
- 定价屏幕逻辑
- 分析连接
- 特性标志
- 然后一个 API 更新通常是更快的审查文档。
then a Capgo update is often the faster review artifact.
这是 Capgo 最不被利用的好处之一：您可以将审查和QA 工作移到 OTA 轨道上而不破坏原生/网页边界。
我们的指南 使用一个移动应用 ID 进行分期 涵盖了保持此项清洁的实用方法。
7. 将瘦身和密钥分开
小型包和安全包解决不同的问题。
频道控制资格。它们本身不会使包文件保密。
如果您需要更强大的交付保证:
- 启用 实时更新加密,
- 使用 自定义存储或自主交付,
- 只在CI或受控的运营商工作流中保留私钥。
这并不意味着更新大小无关紧要。它只是意味着您应该优化两种维度：
- 以速度为主
- 以交付控制为主
- 以发布控制为主
- 恢复时使用回滚。
实践的“精简 Capgo”工作流程
如果您想使用一个简单的默认操作模型，请使用以下内容：
- 保持原生和OTA发布分支分开。
- 使用
--delta默认情况下。 - 使用
staging和beta在production. - 观看 更新统计信息和日志 在发布后，而不是仅在发布前。
- 将 PR 转换为不需要原生构建的可安装预览。
- 尽可能将大型、频繁变化的媒体从捆绑包中排除。
- 在原生资产增长或原生变化后刷新原生基线。
- 将
notifyAppReady()和回滚行为视为发布工程的一部分，而不是设置的琐碎事项。
这种组合比常见的“只上传变化的内容”方法保持速度更长时间。
关闭思考
对于Capgo团队来说，“瘦身快”不仅仅是捆绑包大小的问题。
它是一个发布设计问题。
使用Delta更新来降低载荷大小，使用通道来降低滚动大小，使用回滚来降低失败大小。一旦您以这种方式思考OTA，更新就会保持快速，即使应用程序、团队和用户基数越来越大。
