在 Capgo 中，3 个值被计算并且很重要理解
- 用户
- 存储
- 带宽
每个值有不同的计量方式
用户
每次用户下载并打开您的 Capacitor JS 应用时，它会向 Capgo 后端发送请求，以确定是否有更新可用。
当应用执行此操作时，它会发送少量信息，包括最重要的信息 DeviceID
DeviceID：是一个设备上生成的唯一 ID（UUID）。 从插件版本 v5.10.0、v6.25.0 和 v7.25.0 开始，此 ID 现在在应用重装时持久化（安全存储在设备存储中）。在这些版本之前，ID 在每次应用安装时都会重置。
每次您的帐户接收到一个新的设备 ID 时，它会在数据库中保存。
每次一个旧的 DeviceID 请求更新（应用打开），它会更新其记录（在数据库中更新 updated_at）。
数据保存在两个地方：
- 设备表格中，
update_at应用统计表格中， - 每日计数器，代表今天激活的设备数量，且本月未激活过的设备数量。
对于计划限制，使用第一个方法，因为它是100%可靠的；对于显示图表，使用第二个方法。 您可以在您的账户首页看到它们：
- 图表中使用的是第二个方法
- 应用表格中使用的是第一个方法
Capgo don’t count emulator and dev build in your usage. Keep in mind after the trial you can’t have more than 3% of them, or that will lock your account, until you fix it.
Capgo is also doing some filtering for you. If you have CI/CD configured to send your version to Google PLAY, Google is running your Capacitor app each time to 20+ real device. During the 4 first hours of a new bundle, we block Google data center IP to prevent them to being counted.
每个月，这些数据从零开始。
- 在每个设备请求时，创建或更新我的设备数据库
- 将每日计数器中未激活本月的设备数量添加到活跃设备数量中
第一个方法返回：900+用户 第二个方法在您的帐户上有200+用户 对于计划限制，我使用第一个方法，100%可靠，而用于显示图表的第二个方法。 您可以在帐户主页看到它们。
存储
每次上传一个捆绑包，这个数字都会增加上传的大小。
这个数据只与您的上传大小相关，应用程序大小越好，您在计划中的表现就越好。
如果您达到或接近限制，可以使用CLI列出捆绑包。
npx @capgo/cli@latest bundle list
查看您可以清除的内容，删除捆绑包，释放存储空间，但不要删除统计数据。
当您准备好清理时，请使用以下命令删除多个捆绑包：
npx @capgo/cli@latest bundle cleanup
PS：这对地球有益，但也对您的钱包有益 💪。
您还可以使用
--external的上传大小来使用您的存储空间，而不计算在您的计划中。
带宽
计算这个值的方法稍微复杂一些，但想法与存储相同。
每次用户下载一个包时，这个数字就会增加下载的包大小。
这个数据只与您的下载大小有关，Capacitor JS 应用程序大小越好，您就越有可能在您的计划中。
Capgo 不能看到下载的大小，它只看到包的大小。因此，如果您有一个大的包，并且有许多用户无法下载它，您将很快达到限制。
为了在您的计划中保持良好，建议您有一个小的包。如果您无法实现，请向您的用户显示下载进度条，并让他们知道他们还有多少可以下载。
在未来，Capgo 将改进下载系统，以增加一次下载包的机会。
继续阅读关于在 Capgo 中如何计算您的使用情况的内容。
如果您正在使用 在 Capgo 中如何计算您的使用情况 进行实时更新的计划交付，连接它到 Capgo Live Updates 在 Capgo Live Updates 中的产品工作流程 概览 概述中的实现细节 功能 功能中的实现细节 更新行为 更新行为中的实现细节 更新类型 更新类型中的实现细节
