👋 你好，欢迎来到我的博客！我是【菜鸟学鸿蒙】
   我是一名在路上的移动端开发者，正从传统“小码农”转向鸿蒙原生开发的进阶之旅。为了把学习过的知识沉淀下来，也为了和更多同路人互相启发，我决定把探索 HarmonyOS 的过程都记录在这里。
  
  🛠️ 主要方向：ArkTS 语言基础、HarmonyOS 原生应用（Stage 模型、UIAbility/ServiceAbility）、分布式能力与软总线、元服务/卡片、应用签名与上架、性能与内存优化、项目实战，以及 Android → 鸿蒙的迁移踩坑与复盘。
  🧭 内容节奏：从基础到实战——小示例拆解框架认知、专项优化手记、实战项目拆包、面试题思考与复盘，让每篇都有可落地的代码与方法论。
  💡 我相信：写作是把知识内化的过程，分享是让生态更繁荣的方式。
  
   如果你也想拥抱鸿蒙、热爱成长，欢迎关注我，一起交流进步！🚀

先别急着改：先“体检”，再动刀 🔍

官方的建议很明确：优化前先了解 Stage 模型的包结构（HAP/HAR/HSP），然后用扫描工具分析包内容，再按报告优化。
我强烈建议你把流程固定成两步：

1. 扫描报告：看资源占比、so 占比、重复依赖、重复资源
2. 做一次改动就复测：不然你改半天，体积没降还引入崩溃，那就很尴尬🙂

1）资源裁剪：真正的大头，往往不是代码，是“素材包”🥲

1.1 图片：别让 PNG 当你包体积的“房贷”

常用硬招（最有效、最不伤功能）：

• 图标类：尽量用 矢量/符号（能省很多）
• 照片类：能 WebP 就 WebP（质量/体积更平衡）
• 大图：做多分辨率策略，别一张 4K 图全机型通吃

我个人经验：一套电商 App，光把“Banner + 运营活动图”压一轮，包能立刻瘦一截，立竿见影😅

1.2 字体：最容易被忽略的“隐形巨人”

• 只保留必要字重（别 Regular/Medium/Bold/Black 全塞）
• 能子集化就子集化（只打包用到的字符集）
• 多语言资源按需：别默认带一堆你根本不展示的语言资源

1.3 音视频：别把“内容”当“资源”打进包里

• 长音频、视频：优先走在线/分段加载，别打进 HAP
• 必须内置：控制码率/采样率，能压就压

2）模块拆分：把“常用”和“不常用”分家，别同居到老 😤

2.1 “多包 + 按需分发”：不常用功能别一上来就让用户下载

官方给的思路很清楚：把不常用功能作为按需加载模块，减少首包体积。
典型拆法：

• 首包（entry）：首页/登录/核心链路
• 功能包（feature）：扫一扫、AR、重度编辑、离线地图…

2.2 HAR vs HSP：别让共享库“重复拷贝”

官方点得非常直白：多包场景下，使用 HSP 动态共享包在多个 HAP/HSP 之间共享代码和资源，能避免使用 HAR 静态共享导致的重复拷贝，从而减小包体积；但大量用 HSP 可能增加编译耗时/内存占用，需要权衡。

人话总结：
想瘦包：HSP 更香；
想编译快：HAR 更省心；
想又瘦又快：那就得挑重点模块上 HSP，别全家桶一把梭🙂

2.3 依赖冲突与重复：能少引就少引

官方也提到用 ohpm 的 override 或 resolve_conflict 思路来减少依赖冲突导致的重复编译/重复引入。
实操建议：

• 每个 feature 模块只引它真正需要的包
• 定期做依赖树审计（“为了一个工具函数引入一座山”的情况太常见了😅）

3）代码混淆：既是“防抄”，也是“瘦身”（但别把自己也混淆没了🤣）

3.1 ArkGuard 混淆开关：Release 才生效

官方说明：DevEco Studio 5.0.3.600 之后，新建工程默认关闭混淆；要开启需要在模块 build-profile.json5 里把 ruleOptions.enable 设为 true，且仅对 Stage 工程 + release 编译生效。

示例：entry 模块 build-profile.json5（核心段）

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

3.2 混淆规则：先“保命”，再“加狠”

官方也提醒：开启更强的混淆选项（如属性/顶层/导出/文件名混淆）可能导致运行时错误，需要按“开启指导”修正规则。
我的建议顺序：

1. 先开基础混淆（默认参数名/局部变量）
2. 跑一轮回归测试
3. 再逐项开启更强选项，并补 keep 规则（别一步到位把自己送走😅）

4）构建配置优化：别把“调试料”打进 release 包里 🙃

4.1 so 库瘦身：压缩/strip 是最猛的一刀

官方最佳实践明确提到：含 so 的工程可以配置 so 压缩选项来减小包大小。
另外也有开发实践指出：在 HAP/HSP 模块的 build-profile.json5 里开启 strip，可移除 so 符号表和 debug 信息，体积会明显下降。

这块我特别爱用一句话吓唬人：
**“你以为你在发布应用，其实你在给用户发布调试符号。”**😤

4.2 Release 只带必要产物：别把测试资源、日志、冗余文件打进去

建议你做三件事（非常实用）：

• 清理工程里“仅测试用”的资源目录（demo 图、占位视频）
• Release 降低日志（尤其是大段字符串/JSON 拼接）
• 复查打包输出目录：看看是不是把无关文件一起带进去了（扫描工具一眼就能看出来）

4.3 多包场景：共享优先、重复清零

多包时最常见的“包体积冤案”是：

• entry 里有一份资源
• feature 里又拷了一份
• HAR 又静态打进去一份
  最后用户下载的是“三倍快乐”🙂
  你就按官方建议：多包共享尽量用 HSP，把重复拷贝砍掉。

一套我自己常用的“包体积瘦身清单”（按收益排序）✅

1. 扫描包 → 找 Top 10 大文件/目录（先抓最大头）
2. 图片批量压缩 + 替换格式（立竿见影）
3. 字体子集化（很多项目能直接省几 MB 甚至十几 MB）
4. 多包重复资源清理，能共享就共享（HSP vs HAR 评估）
5. so：strip + 压缩（猛）
6. Release 开混淆（先保守后加强）
7. 依赖树减肥（避免“为了一颗螺丝引入一辆车”）

📝 写在最后

如果你觉得这篇文章对你有帮助，或者有任何想法、建议，欢迎在评论区留言交流！你的每一个点赞 👍、收藏 ⭐、关注 ❤️，都是我持续更新的最大动力！

我是一个在代码世界里不断摸索的小码农，愿我们都能在成长的路上越走越远，越学越强！

感谢你的阅读，我们下篇文章再见～👋

✍️ 作者：某个被流“治愈”过的 移动端 老兵
📅 日期：2025-11-05
🧵 本文原创，转载请注明出处。