HarmonyOS 鸿蒙Next多包结构下的包大小治理——HAP 和 HSP 越来越胖怎么减
HarmonyOS 鸿蒙Next多包结构下的包大小治理——HAP 和 HSP 越来越胖怎么减 鸿蒙的应用发布单位是 App Pack（.app），里面包含一个或多个 HAP（Harmony Ability Package）和若干个 HSP（Harmony Shared Package）。跟 Android 的 APK + Dynamic Feature Module 类似，但有自己的特点。
7 回复
尊敬的开发者，您好，
关于您反馈的App Pack体积越来越大的问题，推荐进行应用包体积优化，具体优化方法可以参考以下内容：
- 对于含有so库的App工程，可以配置so库压缩选项，以减小应用包大小。
- 在应用存在多包（HAP、HSP）的场景中，可以使用HSP动态共享包在多个包（HAP、HSP）之间共享代码和资源，消除使用HAR静态共享包导致的代码和资源重复拷贝，从而减小应用包大小，同时开发者需要综合评估对编译性能的影响：大量使用HSP替代HAR，会在编译引用这些HSP共享包的模块时触发更多的语言编译任务，导致编译耗时、编译内存占用增加。
- 使用ohpm的override机制或开启
resolve_conflict解决依赖冲突，减少依赖包导致的重复编译问题。 - 将不常用的功能作为按需加载的模块。
参考文档如下：应用包体积优化。
更多关于HarmonyOS 鸿蒙Next多包结构下的包大小治理——HAP 和 HSP 越来越胖怎么减的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
包体变大建议先做归因，不要直接“压缩一下”。可以把 App Pack 拆开看每个 HAP/HSP 的资源、so、字体、图片、rawfile、三方库分别占多少。
常见治理路径：
- 图片按实际显示尺寸出多套资源，避免把大图原样塞进包；可远程下发的运营图不要内置。
- 多模块重复资源、重复三方库要抽到共享层，避免每个 HAP/HSP 各带一份。
- Native so 检查 ABI、符号和未使用库，release 包关闭调试符号或做符号分离。
- rawfile 里的模型、地图、音视频资源优先考虑按需下载和版本缓存。
- CI 里加包体报告，按模块设置阈值，哪个模块超了能第一时间看到。
HSP 不是天然减包，只有真正被多个模块共享、且避免重复打入时才有收益。
针对HarmonyOS NEXT多包结构，HAP和HSP体积增大可采取以下措施：
- 启用代码混淆与资源压缩（hvigor配置
minifyEnabled、shrinkResources）。 - 使用AppAnalyzer工具分析依赖，移除未使用的HSP/HAR模块。
- 将公共代码放入HSP，但避免过度拆分，按页面或功能动态导入（
import()）。 - 资源优化：压缩图片（WebP）、移除重复资源、按限定词拆分。
- 针对不同设备形态构建专属HAP，利用
targetDevice过滤无用资源与so库。 - 使用
ohos-ohpm清理冗余依赖，开启useNormalizedOHM。
鸿蒙Next的HAP和HSP体积膨胀，主要源于多包间重复打包和资源冗余。治理方向包括：
- 公共资源下沉HSP：多个HAP共用的代码、工具库、图片等放入HSP，由各HAP动态共享，避免各自重复打包。
- 按需拆分Feature HAP：将低频功能拆成独立HAP，用户需要时再下载加载，减小首包体积。
- 资源压缩：图片优先使用WebP/AVIF，开启构建时的资源压缩和混淆，自动剔除未引用资源。
- 代码裁剪：开启ArkTS混淆与Tree Shaking，减少第三方库的全量依赖，只保留实际调用部分。
- Native .so瘦身：用
abiFilters限定目标CPU架构，只打包需要的so文件，并考虑延迟加载或把大so放入HSP。 - 包体积分析：用DevEco Studio自带的包分析工具，查看HAP/HSP内各目录占比，定位大文件后精准处理。
