最好的实时更新是用户几乎察觉不到的。
这通常意味着三个事情：
- 下载很小。
- 滚动更新受控。
- 如果出现问题，恢复速度极快。
与 React Native 相同的“保持 OTA 低延迟”建议也适用于 Capgo。不同之处在于 Capgo 给 Capacitor 团队提供了几个额外的杠杆： 增量更新, 频道, 自动回滚, 版本目标和可选的 端到端加密.
如果您同时使用这些，您会得到更小的负载、更快的安装和更少的运营混乱。
即使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包静默地膨胀的巨大资产是哪里。
Some practical rules:
- 当使用普通资产文件时，不要在 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’s 渠道系统 是控制的最干净的方式：
staging用于QAbeta用于邀请的测试者production用于所有人hotfix用于紧急恢复
一个简单的流程如下：
- 上传到
staging. - 在真实设备上验证。
- 逐渐发布，是否通过受控渠道或基于百分比的发布。
- 如果您的应用程序在野外有多个本机基线，则将渠道与之配对。
__CAPGO_KEEP_0__ 版本目标. 这样可以避免向旧版二进制文件推送不兼容或不必要的包。
对于希望有更紧密的审查循环的团队,Capgo也非常适合 PR预览. 这样产品、QA和利益相关者就可以在等待新版TestFlight或Play内部构建之前测试JS-only更改。
5. 如果您启用直接更新，优化启动硬件
您希望更新应用的速度越快，启动路径就越需要纪律。
Capgo的 更新行为 文档明确建议将其与Delta更新配对。 这是正确的默认值。 directUpdate 第二个防护栏是
The second guardrail is notifyAppReady().
import { CapacitorUpdater } from '@capgo/capacitor-updater'
CapacitorUpdater.notifyAppReady()If your app does not report ready within the default 10-second window, or within whatever you set in your __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ 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() Call 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. 使用内部更新通道而不是不必要的原生重建 6. 使用内部更新通道而不是不必要的原生重建 6. 使用内部更新通道而不是不必要的原生重建
6. 使用内部更新通道而不是不必要的原生重建
许多移动团队浪费时间在构建明显是web-only的更改的二进制文件。
如果更改是：
- 复制
- UI细化
- 引导流程
- 定价屏幕逻辑
- 分析连接
- 特性标志
- 提示或API响应渲染
那么Capgo更新通常是更快的审查文档。
That means fewer native rebuilds, less TestFlight churn, and a tighter feedback loop for the team. It is one of the most underused benefits of Capgo: you can move more review and QA work into the OTA lane without breaking the native/web boundary.
这是__CAPGO_KEEP_0__最不被利用的好处之一：您可以将审查和QA工作移到OTA通道中，而不破坏原生/WEB边界。 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
__CAPGO_KEEP_2__
__CAPGO_KEEP_3__
__CAPGO_KEEP_4__
__CAPGO_KEEP_5__
- __CAPGO_KEEP_6__ __CAPGO_KEEP_7__,
- __CAPGO_KEEP_8__ __CAPGO_KEEP_9__,
- __CAPGO_KEEP_10__
__CAPGO_KEEP_11__
- 为了速度而精简,
- 加密的传输控制,
- 渠道控制,
- 回滚恢复.
实用的“精简Capgo”工作流程
如果您想要一个简单的默认运营模型，请使用此：
- 保持原生和OTA发布通道分开.
- 上传JS更改时
--delta默认情况下. - 使用
staging和beta渠道之前production. - Watch update stats and logs after rollout, not just before it.
- Turn PRs into installable previews when a native build is unnecessary.
- Keep large, frequently changing media out of the bundle where possible.
- Refresh the native baseline after major asset growth or native changes.
- Treat
notifyAppReady()and rollback behavior as part of release engineering, not setup trivia.
That combination stays fast much longer than the common “just upload whatever changed” approach.
Closing thought
For Capgo teams, “lean and fast” is not just a bundle-size problem.
It is a release design problem.
使用Delta更新来减少数据包大小，使用频道来减少发布大小，使用回滚来减少失败大小。 一旦你以这种方式思考OTA，更新就能保持快速，即使应用程序、团队和用户基数越来越大。
从如何保持Capgo更新快速和轻便的指南中继续
如果您正在使用 如何保持Capgo更新快速和轻便 来规划频道路由和分阶段发布，连接它到 Channels 频道 频道 频道 Beta测试解决方案 Beta测试解决方案 Beta测试解决方案 在 Beta Testing Solution 中的产品工作流程，和 Version Targeting Solution 在 Version Targeting Solution 中的产品工作流程。
