In 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值 - app_stats 表格中，使用每日计数器，表示今天活跃的设备数量和本月未活跃的设备数量。
对于计划限制，使用第一个方法，因为它是 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上传大小来使用您的存储空间，而不计算在您的计划中。
带宽
这个值的计算略微复杂，但与存储的想法相同。
每次用户下载一个包时，这个数字就会增加下载的大小。
这个数据仅与您的下载大小相关，越好的您的CapacitorJS应用大小，越好地您在您的计划中。
一个重要的事情是要注意的是，Capgo无法看到下载的大小，它只看到包的大小。因此，如果您有一个大的包，并且有很多用户无法下载它，您将很快达到限制。
为了在您的计划中保持最佳状态，最好的方法是拥有一个小的包，如果您无法做到这一点，请向您的用户显示一个下载进度条，并让他们知道他们还有多少可以下载。
在未来，Capgo将改进下载系统，以增加一次下载包的机会。
Keep going from How your usage is counted in Capgo
如果您正在使用 How your usage is counted in Capgo 来计划实时更新的传递，请将其连接到 Capgo Live Updates for the product workflow in Capgo Live Updates, Capgo Live Updates中的产品工作流程 对于概览中的实现细节 功能 对于功能中的实现细节 更新行为 对于更新行为中的实现细节,以及 更新类型 文章来源
