如何让Capgo实时更新保持快速和轻量

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

通常意味着三个事情：

下载量小.
发布控制.
恢复速度快，如果出现问题.

与React Native领域的“保持OTA瘦身”建议一样，Capgo也适用。不同的是，Capgo为Capacitor团队提供了几个额外的杠杆. Delta更新, 频道, 自动回滚, 版本目标,以及可选端到端加密.

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

Lean在MAU保持不变的情况下也很重要

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

因此，瘦身一个捆绑包并不是主要为了减少MAU计数的 trick。它很重要，因为它改善了用户和团队实际感受到的部分：

在移动网络或弱Wi-Fi环境下更快的下载
更好的用户体验直接更新
失败或回滚发布时浪费的带宽减少
测试或发布阶段时测试范围减小

Lean更新主要是关于速度、安全性和运营纪律。

1. 默认使用Delta更新

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

Capgo’s Delta更新仅发送版本之间变化的文件而不是重新下载完整的Web包

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 道路

For safe web-layer iteration:

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

如果您最近添加了大量长期存活的资产，请定期更新本地基线。一次新的商店构建包含了新的基线，这样将来Capgo 的差异会更小。

4. 使用通道来保持发布大小小

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

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

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

A simple flow looks like this:

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

如果您的应用程序在野外有多个本机基线，pair channels with 版本目标。这可以将不兼容或不必要的包从旧的二进制文件中排除。

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

5. 如果您启用直接更新，优化启动时间

越快地希望应用更新，启动路径就越需要有条理。

Capgo’s __CAPGO_KEEP_0__的更新行为 directUpdate docs明确建议将

与Delta更新配对。 That是正确的默认值。 notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

第二个安全栅栏是 notifyAppReady() 如果您的应用程序在默认10秒 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__可以将该捆绑包标记为无效并恢复上一个良好的版本。 That回滚行为是在生产环境中所期望的，但这也意味着您应该保持启动路径干净： notifyAppReady() Call
在正确的位置执行
在重新加载时，务必小心保存和恢复应用程序状态
在广泛部署之前，测试坏网络和低端设备场景

如果您最近没有查看过它，请重新阅读 notifyAppReady 指南 worth

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

许多移动团队浪费时间为明显是 web-only 的更改构建二进制文件。

如果更改是：

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

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

这意味着少了原生重建，减少了TestFlight的混乱，团队的反馈循环更紧密。它是Capgo中最不被利用的好处之一：您可以将审查和QA工作移到OTA通道中，而不破坏原生/WEB边界。

我们的指南使用一个移动应用程序ID进行分期涵盖了保持这一点在长期内保持清洁的实用方法。

7. 将瘦身与秘密分开

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

通道控制资格。它们本身不会使包文件保密。

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

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

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

优化速度
加密交付控制
渠道控制发布
回滚恢复

实践的“Capgo”工作流

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

保持原生和OTA发布分支分开。
上传JS变更 --delta 默认情况下。
使用 staging 和 beta 频道 production.
前更新统计和日志发布后，而不是仅在发布前。
将PR转换为不需要原生构建的可安装预览。
尽可能将大型、频繁变化的媒体从捆绑包中排除。
在原生资产增长或原生变化后刷新原生基线。
把回滚行为视为发布工程的一部分，而不是设置的琐碎事。 notifyAppReady() 这组合比常见的“只上传改变的内容”方法保持速度更长时间。

结论

对于__CAPGO_KEEP_0__团队来说，“精简和快速”不仅仅是包大小的问题。

For Capgo teams, “lean and fast” is not just a bundle-size problem.

使用Delta更新来减少载荷大小，使用通道来减少滚动大小，使用回滚来减少失败大小。一旦您以这种方式思考OTA，更新就会保持快速，即使应用程序、团队和用户基数越来越大。

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

Keep going from How to Keep Capgo Updates Lean and Fast

《如何让__CAPGO_KEEP_0__更新保持快速和轻便》 How to Keep Capgo Updates Lean and Fast 通道 Channels Channels的实现细节 Channels Channels的实现细节 Channels Channels的实现细节类于浏览器源端合的此东求端合端合类于浏览器源端合的此东求端合端合类于浏览器源端合的此东求端合端合类于浏览器源端合的此东求端合端合