如何保持Capgo更新的轻量和快速

最好的实时更新是用户几乎察觉不到的。

这通常意味着三个事情：

下载量小。
发布控制。
恢复是立即发生的，如果出现问题。

与 React Native 相同的 "keep OTA lean" 建议也适用于 Capgo。不同之处在于 Capgo 给 Capacitor 团队提供了几个额外的杠杆: Delta 更新, 频道, 自动回滚, 版本目标,以及可选项端到端加密.

如果您同时使用这些功能，会得到更小的包、更快的安装和更少的运维混乱。

瘦身也很重要，即使 MAU 保持不变

一个有用的 Capgo 特定细节：Capgo MAU 实际上是过去 30 天内联系更新服务的月度活跃设备数量。

瘦身主要不是为了减少 MAU 计算。它的重要性在于它改善了用户和团队真正感受到的部分:

在移动网络或弱Wi-Fi环境下实现更快的下载
更好的体验直接更新
减少因发布失败或回滚而浪费的带宽
在测试或发布阶段减少爆炸半径

保持Capgo更新的速度、安全性和运营纪律是非常关键的

1. 默认使用Delta更新

如果您只做一件事，那么就做这个

Capgo的 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 通道

对于安全的网层迭代:

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

如果您最近添加了大量长期存活的资产，请定期更新您的原生基线。一个新的商店构建会将该新基线嵌入其中，这样将来Capgo的差异会更小。

4. 使用通道来保持滚动大小小

一个“瘦身”更新不仅仅是关于兆字节。它也关于在您知道它是好的之前，更新到多少台设备。

Capgo的通道系统是控制这一点的最干净的方式:

staging 用于QA
beta 用于邀请的测试者
production 适用于所有人
hotfix 用于紧急恢复

一个简单的流程如下:

上传到 staging.
在真实设备上验证。
逐渐发布，是否通过受控通道或基于百分比的发布。
如果健康指标下降，立即回滚。

如果您的应用程序在野外有多个本机基线，pair channels 与版本目标。这可以保持不兼容或不必要的重型捆绑包远离较旧的二进制文件。

对于那些想要更紧密的审查循环的团队，Capgo 也适用于 PR预览让产品、QA和利益相关者在不等待新版TestFlight或Play内部构建的情况下测试JS-only更改。

5. 如果您启用直接更新，优化启动硬件

快速应用更新的速度越快，启动路径就越需要有条理。

Capgo的更新行为文档明确建议将__CAPGO_KEEP_0__与Delta更新配对。这是正确的默认值。 directUpdate 第二个安全阀是

如果您的应用程序在默认10秒窗口内或您在__CAPGO_KEEP_0__配置中设置的任何时间内没有报告就绪，__CAPGO_KEEP_1__可以将该捆绑包标记为无效并恢复之前的良好版本。这种回滚行为是在生产环境中所期望的，但这也意味着您应该保持启动清洁： notifyAppReady().

import { CapacitorUpdater } from '@capgo/capacitor-updater'

CapacitorUpdater.notifyAppReady()

调用 notifyAppReady() __CAPGO_KEEP_1__ 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:

__CAPGO_KEEP_1__ notifyAppReady() 在正确的位置
避免在关键路径中执行慢速启动时间工作
如果您立即重新加载，请小心保存和恢复应用程序状态
在广泛部署之前测试坏网络和低端设备场景

如果您最近没有查看它， notifyAppReady 指南值得重新阅读。

6. 使用内部更新通道而不是不必要的本机重建

许多移动团队浪费时间为明显仅为Web更改而构建二进制文件。

如果更改是：

复制
UI 美化
onboarding 流程
定价屏幕逻辑
分析连接
功能标志
然后一个 API 更新通常是更快的审查文档

这意味着更少的本机重建，TestFlight churn 少一些，团队的反馈循环更紧密。它是 Capgo 中最不被利用的好处之一：您可以将审查和 QA 工作移到 OTA 轨道中，而不破坏本机/ web 边界。

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.

使用一个移动应用 ID 进行分期涵盖了保持此项清洁的实用方法。 7. 将瘦身和密钥分开

小包和安全包解决不同的问题

__CAPGO_KEEP_0__

频道控制资格。它们本身不会使包裹保密。

如果您需要更强的交付保证:

启用实时更新加密,
使用自定义存储或自主托管交付,
只在CI或受控的运营商工作流中保留私钥。

这并不意味着更新大小无关紧要。它只是意味着您应该优化两种维度:

瘦身以提高速度
加密以控制交付
频道以控制发布
回滚以恢复

A practical “lean Capgo” workflow

如果您想要一个简单的默认运营模型，请使用以下内容：

保持原生和OTA发布分支分开。
上传JS更改时 --delta 默认情况下。
使用 staging 和 beta 在 production.
查看更新统计和日志在发布后，而不是仅在发布前。
将PR转换为不需要原生构建的可安装预览
尽可能地将大型、频繁变化的媒体从捆绑包中排除。
在主要资产增长或原生变化后刷新原生基线。
原生 notifyAppReady() 和回滚行为应作为发布工程的一部分，而不是设置的琐碎事项。

这种组合比常见的“只上传变化的内容”方法，能够保持更长时间的快速状态。

结论

对于Capgo团队来说，“快速和轻量”不仅仅是一个捆绑包大小的问题。

它是一个发布设计问题。

使用差异更新来控制负载大小，使用频道来控制发布大小，使用回滚来控制失败大小。一旦您以这种方式思考OTA，更新就会保持快速，即使应用程序、团队和用户基数越来越大。

继续阅读《如何保持Capgo更新快速和轻量》

如果您正在使用《如何保持__CAPGO_KEEP_0__更新快速和轻量》 _如何保持Capgo更新快速和轻量》 为了规划频道路由和分阶段发布，连接它与频道频道频道频道 Beta 测试解决方案为了产品工作流程在 Beta 测试解决方案中，和版本目标解决方案为了产品工作流程在版本目标解决方案中。由 Capgo Solutions Marketing Page: Channels feature name. Role: Short UI label or navigation item. Seen in: page solutions/white-label.astro. Message key `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value).