如何让Capgo保持快速和轻量

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

通常意味着三个事情：

下载量很小。
滚动更新受控。
如果出现问题，恢复速度极快。

与 React Native 相同的 "保持 OTA 低延迟" 的建议也适用于 Capgo。不同之处在于 Capgo 给 Capacitor 团队提供了几个额外的杠杆：增量更新, 渠道, 自动回滚, 版本目标和可选的端到端加密.

如果您同时使用它们，会得到更小的负载、更快的安装和更少的运营混乱。

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

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

瘦身一个捆绑包并不是主要为了减少MAU计数。它的重要性在于它改善了用户和团队真正感受到的部分：

在移动网络或弱 Wi-Fi 上更快的下载
更好的体验直接更新
在失败或回滚的发布中浪费的带宽更少
在测试或分阶段发布时的爆炸半径更小

瘦身更新真正是关于速度、安全性和运营纪律。

1. 默认使用Delta更新

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

Capgo的增量更新只发送版本之间变化的文件，而不是重新下载整个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 这尤其重要，如果您使用

，因为用户可见的更新时间和应用重新加载时间之间的时间差会变得更加明显。 directUpdate2. 将资产视为资产，而不是JavaScript包裹

大型资产是OTA包静默膨胀的主要原因。

Delta updates

一些实用的规则：

不要将大图像或媒体直接嵌入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 用于QA
beta 用于邀请的测试者
production 用于所有人
hotfix 用于紧急恢复

一个简单的流程如下：

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

如果您的应用程序在野外有多个本地基线，请将频道与针对版本. 这样可以避免向旧版二进制文件推送不兼容或不必要的包。

对于那些希望更紧密的审查循环的团队,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() 在生产环境中，回滚行为是你想要的，但这也意味着你应该保持启动过程干净： 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. 使用内部更新通道而不是不必要的原生重建

A lot of mobile teams waste time building binaries for changes that are clearly web-only.

如果变化是：

复制
UI 美化
引导流程
定价屏幕逻辑
分析连接
特性标志
提示或 API 响应渲染

然后一个 Capgo 更新通常是更快的审查文档。

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

我们的指南使用一个移动应用ID进行预发布介绍了保持此项清洁的实用方法。

7. 将瘦身和密钥分开

小型捆绑包和安全捆绑包解决不同的问题。

频道控制资格。它们本身无法使捆绑包保密。

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

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

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

以速度为主
加密传输
渠道控制
回滚

实用的“Capgo”流程

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

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

这种结合比常见的“仅上传改变的内容”方法保持速度更长时间

结语

对于Capgo团队，“瘦身”和“快速”不仅仅是捆绑包大小的问题

它是一个发布设计问题

使用Delta更新来减少包大小、使用渠道来减少发布大小、使用回滚来减少失败大小。一旦你以这种方式思考OTA，更新就能保持快速，即使应用、团队和用户基数都在增长。

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

如果你正在使用《如何让__CAPGO_KEEP_0__保持更新快速和轻便》 《如何让Capgo保持更新快速和轻便》 规划渠道路由和分阶段发布，连接它到《渠道》《渠道》渠道《渠道》《渠道》《渠道》《渠道》《Beta测试解决方案》为 Beta Testing Solution 的产品工作流程, 和 Version Targeting Solution 为 Version Targeting Solution 的产品工作流程