适用版本：HarmonyOS 6.0+ / API 24（DevEco Studio 6.1.1）
阅读收益：掌握 HAP 体积构成、建立"代码+资源+分包"三维瘦身体系、学会用混淆/摇树/WebP/HSP 全策略把包体积压到极限

---

一、前置思考：包体积是"下载转化率的隐形杀手"

1.1 包体积的商业价值

事实	数据
下载转化率	包体积每增 10MB，转化率约下降 1%~2%
用户流失	弱网用户看到大包直接放弃
商店限制	各商店对超大包（>200MB）有限制或警告
分发成本	大包增加 CDN 与流量成本

核心认知：包体积不是技术指标，是商业指标。每 1MB 都是下载漏斗里流失的用户。

1.2 瘦身的原则

瘦身三原则：
1. 先量化后动手 —— 体积构成分析，抓大头
2. 代码 > 资源 > 分包 —— 按收益排序投入
3. 无损优先 —— 压缩不损质量，再去冗余

不要一上来就压图片——如果 60% 体积来自代码库，压图片收效甚微。
先看构成，再定策略。

---

二、核心原理：HAP 包体积构成

2.1 HAP 包内容构成

HAP 包 (Huawei Ability Package)
├── ets/           ArkTS 编译产物（代码 + 字节码）
├── resources/     资源（图片/布局/字符串/媒体）
│     ├── media/       图片、音频、视频
│     ├── rawfile/     原始文件（字体/配置文件）
│     └── base/        字符串/颜色/主题
├── libs/          Native 动态库（.so）
├── module.json5   模块配置
└── pack.info      包信息

2.2 典型体积分布（未优化 HAP）

组成部分	占比	说明
resources/media 图片	40%~60%	最大头！
libs (.so 库)	15%~30%	多架构复制翻倍
ets 代码产物	10%~20%	含未使用代码
其他（rawfile/配置）	5%~15%	字体/媒体文件

结论：图片通常是第一大头，但 .so 库的"多架构复制"是隐藏炸弹
（一份 .so 在 arm64/arm32/x86 各复制一份 = 3 倍体积）。

2.3 体积膨胀的四大源头

源头	典型场景	膨胀程度
高分辨率图片	放 4K 图给 2K 屏	⭐⭐⭐⭐⭐
多架构 .so	全套 ABI 全带	⭐⭐⭐⭐
三方 SDK 冗余	引入 SDK 连带大量资源	⭐⭐⭐⭐
无用代码/资源	迭代后遗留	⭐⭐⭐

---

三、源码/API 深度解析：四大核心策略

3.1 代码混淆（Obfuscation）

原理：把标识符（类名/方法名/变量名）替换为无意义短名，压缩代码 + 增加逆向难度。

HarmonyOS 工程通过 build-profile.json5 配置混淆：

{
  "buildOption": {
    "arkOptions": {
      "obfuscation": {
        "ruleOptions": {
          "enable": true,
          "files": ["./obfuscation-rules.txt"]
        }
      }
    }
  }
}

// obfuscation-rules.txt
-enable-property-obfuscation
-enable-toplevel-obfuscation
-enable-filename-obfuscation
-keep-global-name: com.example.MainAbility

混淆收益：

项	收益
代码体积	减少 10%~25%（长名→短名）
逆向难度	大幅提升
字符串保护	可选加密字符串

注意事项：入口类、路由表、反射调用的类必须 -keep，否则运行时报错。

3.2 Tree Shaking（无用代码剔除）

原理：构建时静态分析 import/export，剔除从未被引用的导出与分支。

手段	说明
未引用的导出函数	构建器剔除
死代码分支	常量折叠后移除
未使用资源	构建时检查并移除
调试代码	生产构建剔除日志/断言

最佳实践：

• 用具名导出而非整对象导出（利于摇树）；
• 工具函数按需引入，不用 import * as utils；
• 调试代码包在 if (__DEV__) 中，生产构建剔除。

3.3 图片压缩：WebP / AVIF

图片是无损压缩的主战场：

格式	体积（相对 PNG）	质量	支持
PNG	100%	无损	全平台
JPG	40%~60%	有损	全平台
WebP	25%~35%	无损/有损	现代平台 ✅
AVIF	15%~25%	有损	新一代 ✅

# 图片压缩策略
1. 纯色/图标 → WebP 无损（或 SVG 矢量）
2. 照片 → WebP 有损 q75 或 AVIF
3. 超大图 → 等比缩放后压缩（不要原图直出）
4. 启动图/Logo → SVG/矢量（体积近 0）

压缩工具链：DevEco Studio 自带图片压缩；命令行可用 cwebp / avifenc。

3.4 HSP 动态分包（Harmony Shared Package）

原理：把低频功能模块（商城、直播、AR）拆分为 HSP（共享包）或 HAP 独立模块，
按需加载，首包只含核心功能。

主 HAP（首包, 60MB）
├── 首页/核心流程/框架
└── 运行时按需加载 ↓

HSP-直播（20MB）  → 用户进入直播才下载
HSP-商城（25MB）  → 用户进入商城才下载
HSP-AR（15MB）    → 用户使用 AR 才下载

实现方式：

// 工程结构: entry(主) + live(动态模块) + shop(动态模块)
{
  "module": {
    "name": "live",
    "type": "shared",          // 或 "entry" 独立模块
    "deviceTypes": ["phone", "tablet"]
  }
}

按需加载代码：

import { router } from '@kit.ArkUI';

// 跳转到动态模块页面
router.pushUrl({
  url: 'live/pages/LiveHome',   // 动态模块路由
  params: { id: 'room123' }
});

收益：

场景	首包体积	用户下载
全量打包	120MB	所有用户下载 120MB
动态分包	60MB	60MB + 按需增量

---

四、企业级实战：全链路瘦身手册

4.1 代码层瘦身

手段	收益	风险
开启混淆	-10%~25%	需 keep 白名单
Tree Shaking	-5%~15%	低
剔除冗余 SDK	看 SDK 大小	需替换实现
重复代码合并	不定	低
反射/动态代码清理	不定	需测试

4.2 资源层瘦身

手段	收益	说明
图片转 WebP/AVIF	-50%~80%	最大单点收益
图片降分辨率	-30%~60%	按屏幕最大尺寸
大图改 9patch/矢量	趋近 0	可拉伸区域用矢量
音频压缩	-40%~60%	AAC/OPUS 替代 WAV
字体子集化	-70%~90%	只打包用到的字形
rawfile 清理	不定	删未用文件

4.3 库层瘦身（.so）

手段	收益	说明
只带目标 ABI	-60%	仅 arm64-v8a（放弃 32 位）
移除无用 .so	看库大小	检查实际调用
Native 库裁剪	不定	编译期去掉无用符号
动态加载 .so	按需	低频能力延后加载

4.4 分包层瘦身

方案	适用	收益
HSP 共享包	多模块共享代码/资源	模块间去重
动态 HAP	低频独立功能	首包大幅下降
按需下载	游戏资源/大模型	极致首包
远程资源	图片/配置	零体积

4.5 瘦身优先级矩阵

优先级	动作	预估收益
P0	图片压缩 + 分辨率控制	-30%~50%
P0	多 ABI 裁剪	-15%~30%
P1	开启混淆 + 摇树	-10%~25%
P1	无用资源/代码清理	-5%~15%
P2	HSP 动态分包	首包再降 30%+
P3	字体子集/音频压缩	-3%~8%

---

五、排查与优化：体积分析工具链

5.1 体积分析流程

步骤	动作	工具
① 构建产物	打出 release HAP	hvigorw assembleHap
② 拆包分析	查看各目录占比	解压 + 分析脚本
③ 图片扫描	找出超大图片	资源扫描工具
④ .so 检查	ABI 与体积	libs 目录分析
⑤ 代码分析	无用代码定位	混淆报告/摇树日志

5.2 体积对比口径

指标	定义
HAP 体积	单模块包体积
首包体积	用户首次下载体积
增量体积	分包按需下载量
安装后体积	解压后占用（≈ 1.5~2 倍 HAP）

5.3 高频坑点速查

• 图片是否全部 WebP/AVIF 化？
• 图片分辨率是否超过屏幕需求 2 倍以上？
• .so 是否带了多余 ABI？
• 混淆是否开启且 keep 规则完备？
• 是否还有未使用的 SDK 依赖？
• rawfile 是否有遗留大文件？
• 字体是否全量打包？
• 低频功能是否已拆分为动态模块？
• 是否有重复资源（多目录同名图）？
• 音频是否为压缩格式？

---

六、总结与进阶

6.1 瘦身收益模型（参考实测）

指标	优化前	优化后	提升
HAP 体积	128MB	42MB	-67%
首包体积	128MB	42MB（+分包按需）	用户下载降 67%
图片资源	58MB	12MB	-79%
代码产物	22MB	15MB	-32%
下载转化率	基准	+3.1%	商业正收益

6.2 工程规范

1. 体积门禁：每次发版对比体积增量，超阈值拦截；
2. 图片规范：新图默认 WebP，超分辨率自动告警；
3. 依赖审计：新引入 SDK 必须评估体积成本；
4. 定期瘦身：每季度做一次无用资源/代码清理；
5. 分包评审：新功能评估是否走动态模块。

6.3 进阶方向

• App Bundle 按需交付：不同设备下发不同资源集；
• 资源混淆：资源路径/名称混淆进一步压缩；
• ABI 策略：根据目标市场设备占比决定 ABI 集合（第 38 篇编译联动）；
• 构建产物自动化分析：CI 中自动出体积报告（第 44 篇联动）。

---

附：Demo 演示说明

Tab	演示内容
📦 体积构成	HAP 内部各模块占比条形图（图片/.so/代码/其他）
✂️ 瘦身手段	混淆/摇树/压缩/裁剪 各手段贡献度对比
🖼️ 图片压缩	PNG/WebP/AVIF 体积对比 + 质量说明
🧩 动态分包	HSP 按需加载流程：首包 vs 增量下载模拟
📊 瘦身报告	优化前后体积对比 + 优先级矩阵