新增安装包体积收费是否合理,是否需要增加大小

欢迎到专业群（ uni-app x技术交流群 ） 咨询，群中有相关专业的管理员和群友。

你提到的这个体积问题，确实是很多开发者在 uni-app x 开发中会遇到的痛点。

针对你的问题，我从几个方面来分析一下：

1. 关于安装包体积的构成

你提到的“纯净的 uni-app x 没有任何内容，双 CPU 类型就已经 54M 了”，这个体积确实包含了 uni-app x 的引擎和基础运行库。根据官方文档：

• 纯引擎体积：uni-app x 的 Android 引擎体积约 10M（这不包括地图、视频等三方库的体积）。
• 集成 SDK 体积：如果是以原生 SDK 的方式集成，Android 端默认只包含 arm64-v8a 时预计增加 8.1M；iOS 端预计增加 8.7M；鸿蒙端预计增加 1MB。
• 多 CPU 类型：每增加一种 CPU 类型，体积都会相应增加。例如：armeabi-v7a 约增加 679KB，arm64-v8a 约增加 858KB，x86 约增加 965KB，x86_64 约增加 970KB。

你提到的 libcronet 和 libbarhopper 这类基础库，它们确实是运行时依赖的一部分。不过需要注意的是，官方在跨平台框架对比测试中也提到，uni-app x 的常用模块（比如图片处理库）并没有被裁剪，因此实际业务中包体积会比纯引擎大一些，但相比其他框架仍有优势。

2. 目前的收费规则是怎样的？

当前官方的云打包计费规则如下（适用于非企业打包机用户）：

• 按原始体积计费：计费依据是项目编译后、压缩前的文件大小，不是最终的 APK 或 IPA。
  • 60MB—140MB：每次 10 元
  • 140MB—250MB：每次 20 元
  • 250MB 以上：每增加 100MB 费用增加 10 元
• 安装包体积超限收费：对于原始体积小于 60MB 的项目，如果最终的安装包体积超过 100MB，会额外收费 5 元，每增加 100MB 再增加 5 元。
• 多平台分别计费：Android 和 iOS 分别计费，同时勾选两个平台则扣费两次。

所以，你提到的“100MB 以下免费”是指安装包体积超限收费的免费额度，并不是指项目原始体积的免费额度。

3. 关于你的建议：“比例调整为系统 40%、用户 60%”和“免费额度提升到 120M”

目前来看，知识库和官方文档中没有关于调整系统与用户空间比例，或者将安装包体积免费额度从 100MB 提升到 120MB 的相关计划或说明。

4. 如何有效减小包体积？

既然规则是明确的，我们可以从优化项目本身入手。结合社区和 issue 系统中的讨论，这里有一些实用的建议：

• 压缩资源文件：这是最直接有效的方法。像图片、音频等静态资源，一定要先进行压缩再放入项目。有开发者在社区反馈，通过压缩图片和去掉开屏图，就解决了体积超限的问题。
• 插件依赖管理（关键）：
  • 使用远程仓储：如果使用了 UTS 插件，尽量将其原生依赖（Android 的 aar、iOS 的 framework 等）配置在远程仓储中（如 Maven、CocoaPods），而不是直接打包在插件里。这能显著减小项目体积。根据优先知识库，UTS 插件现在通过 config.json 来配置这些依赖。
  • 评估插件体积：注意某些插件本身可能很大。例如，社区中有开发者提到，官方的 Lottie 动画插件打包后会增加 30 多 M 的体积。在使用体积较大的插件前，需要做好权衡。
• 调整 CPU 类型：如果你明确知道目标用户的设备类型，可以只选择必要的 CPU 类型进行打包，这能立竿见影地减小安装包体积。
• 善用调试基座：在开发调试阶段，尽量使用自定义基座或内置基座，避免消耗正式的云打包次数和额度。

如果你已经做了这些优化但体积仍然很大，可以检查一下项目目录下的 uni_modules 和 nativeplugins，看看是否有不必要的原生依赖被打包进去了。

如果你还想深入了解，可以查阅官方文档中关于云打包计费规则和UTS 插件配置依赖的详细说明。