鸿蒙App包体积瘦身（资源压缩/无用代码剔除）

一、引言与技术背景

1. 代码与资源 (APP Pack)：这是最主要的组成部分，包括：
   • 应用代码 (ABC/SO)：ArkTS/JS 代码编译后的字节码或方舟编译器生成的 native 代码。
   • 资源文件 (Resources)：应用使用的图片、字符串、媒体文件、布局文件等。
   • 配置文件 (Config Files)：module.json5, app.json5等。
2. 原生库 (Native Library)：如果集成了 C/C++ 代码（通过 NDK），会包含 .so文件。
3. 依赖库 (Dependencies)：应用依赖的第三方 HAR（HarmonyOS Ability Resource）包或 HSP（HarmonyOS Shared Package）。

二、核心概念与原理

1. 包体积分析工具

• Build Analyzer (构建分析器)：
  • 位置：Build -> Build Analyzer(在 DevEco Studio 中)。
  • 原理：在构建完成后，分析构建产物（如 .hap文件），并以图形化方式展示各个模块、依赖和资源文件所占的体积大小。
  • 作用：宏观定位。快速识别出是哪个 HAP、哪个依赖库或哪类资源（如图片）贡献了最大的体积。
• Apk Analyzer (APK 分析器类比)：
  • 位置：构建完成后，在项目的 build/outputs/default/packaging/目录下找到生成的 .hap文件，将其后缀改为 .zip并解压，或者直接通过 DevEco Studio 的 Profile或 Analyze APK(概念上) 功能来查看内部结构。
  • 原理：直接审视构建产物的内部目录结构。
  • 作用：微观审查。查看具体是哪些文件过大，例如一个未被压缩的 .png文件或一个巨大的 .json配置文件。
• 混淆与压缩报告：
  • 在 build/default/intermediates目录下，可以找到代码混淆和压缩后的报告，了解哪些类和方法被保留或剔除。

2. 优化核心技术

• 资源压缩：
  • 无损压缩：如使用 webp替代 png/jpg，在保持视觉质量不变的情况下减小文件体积。
  • 有损压缩：适度降低图片/音频的质量和分辨率。
  • 资源精简：移除未使用的资源（Unused Resources），如废弃的图片、字符串、布局等。
  • 资源混淆与去重：对资源文件名进行短名称混淆，并对重复资源进行去重。
• 无用代码剔除：
  • Tree-Shaking (摇树优化)：在编译构建过程中，静态分析代码的依赖关系，移除那些在代码中没有被引用（未被“摇晃到”）的类、函数、变量。
  • ProGuard/R8 (代码混淆与优化)：对 Java/Kotlin 代码进行混淆、优化和压缩。虽然 ArkTS/JS 不直接使用，但其思想类似。鸿蒙的 ArkCompiler 也有自己的优化过程。
  • Dead Code Elimination (DCE)：编译器在生成最终代码时，自动移除不可达的代码（如永远为 false的 if分支内的代码）。
  • 按需加载/懒加载：将某些非核心功能模块从主包中剥离，放到云端或按需下载。

三、应用使用场景

• 所有鸿蒙应用：包体积是产品竞争力的基础指标。
• 应用市场上架：减小包体可以加快审核速度，提升用户下载意愿。
• 蜂窝网络用户：对流量敏感的用户群体，小包体意味着更高的转化率。
• 低端设备/存储空间紧张的设备：小包体更容易被用户接受和安装。

四、环境准备

• DevEco Studio：最新版本，确保拥有最新的构建优化工具链。
• 待优化项目：一个包含多种资源（图片、JSON、字体）和依赖的示例项目。
• 测试设备/模拟器：用于安装和测试优化前后的 HAP 包。

五、不同场景的代码实现与优化

优化前：基线建立与分析

src/main/resources/
  base/
    media/
      large_png_image.png  (5MB, 一个大尺寸PNG)
      redundant_icon.svg    (一个未使用的图标)
    rawfile/
      large_config.json    (2MB, 一个包含大量注释和格式化空格的JSON)
    element/
      strings.json         (包含一个未使用的字符串 "unused_string")

src/main/ets/
  pages/
    Index.ets             (只使用了 "hello_world" 字符串)
  model/
    HeavyModel.ts         (一个包含大量无用方法的类)

export class HeavyModel {
  // 这是一个会被使用的方法
  public usefulMethod(): string {
    return "I am useful!";
  }

  // 这是一个永远不会被调用的方法，应该被剔除
  private giganticUnusedMethod(): void {
    let data: string[] = [];
    for (let i = 0; i < 10000; i++) {
      data.push(`This is a very long string to simulate a large method body. Item ${i}`);
    }
    console.log("This method should be tree-shaken.");
  }

  // 另一个无用方法
  public anotherUnusedMethod(): number {
    return 42; // The answer to life, but not used.
  }
}

场景一：资源压缩与格式优化

1. 图片格式转换：将 large_png_image.png转换为 webp格式。WebP 通常比 PNG 小 25%-35%，且支持透明通道。
2. 移除未使用资源：删除 redundant_icon.svg和在 strings.json中删除 "unused_string"。
3. 精简 Rawfile：清理 large_config.json中的注释和多余空格，或使用更紧凑的格式（如 MessagePack）。

1. 转换图片：
   • 使用在线工具或 PhotoShop 将 large_png_image.png另存为 large_webp_image.webp。
   • 在代码中引用新的 WebP 图片（通常引用路径不变，只需替换文件）。

   // 在 Index.ets 中
   Image($r('app.media.large_webp_image')) // 引用新图片
     .width(300)
     .height(200)

   • DevEco Studio 设置：确保在 build-profile.json5中开启了图片资源的自动压缩（通常默认开启）。

     "buildOption": {
       "arkOptions": {
         "compressIcon": true // 确保此选项为true
       }
     }

2. 清理资源：
   • 直接从 resources目录下删除 redundant_icon.svg。
   • 编辑 src/main/resources/base/element/strings.json，移除未使用的键值对。

     {
       "string": [
         {
           "name": "hello_world",
           "value": "Hello World"
         }
         // "unused_string" 已被删除
       ]
     }

场景二：代码混淆与无用代码剔除 (Tree-Shaking)

1. 开启代码压缩与混淆：在构建配置中启用更高级别的优化。
2. 确保代码可静态分析：避免动态加载代码（如 eval）和过度使用反射，这些是 Tree-Shaking 的天敌。
3. 显式移除无用引用：确保 HeavyModel中无用的方法没有被其他任何地方引用。

1. 配置构建优化：修改 build-profile.json5文件，在 release构建模式下启用最严格的优化。

   "buildOption": {
     "strictMode": {
       "useNormalizedOHMUrl": true // 规范化OHMUrl，有助于资源优化
     },
     "arkOptions": {
       "compressIcon": true,
       "mergeArkCompilerOutput": true, // 合并方舟编译器输出
       "stripDebugInfo": true, // 发行版strip掉debug信息，大幅减小体积
       "sourceMap": false, // 发行版不生成source map
       "optimize": "speed" // 优化级别: "none", "size", "speed"。"size"更有利于瘦身
     },
     "buildMode": "release" // 确保在release模式下构建
   }

   关键参数：
   • stripDebugInfo: true：移除调试符号，效果显著。
   • optimize: "size"：指示编译器以减小体积为首要目标进行优化。
2. 验证 Tree-Shaking：
   • 完成配置后，进行一次新的 release构建。
   • 对比新旧构建产物的大小。
   • 虽然无法直接看到哪些函数被剔除，但体积的显著减小是 Tree-Shaking 生效的最直接证据。如果 giganticUnusedMethod仍然存在，可能是因为编译器无法确定其完全无用（例如，它可能被子类重写或有复杂的引用）。确保其完全私有且未被引用是关键。

场景三：依赖管理与按需加载 (高级策略)

1. 分析依赖：使用 Build Analyzer找出体积最大的 HAR/HSP 依赖。
2. 评估必要性：是否所有依赖都在主包中使用？能否将部分功能移至云端或按需加载？
3. 使用 HSP 共享公共库：如果多个 HAP 依赖同一个体积较大的公共库，可以将其打包成 HSP，实现共享，避免重复打包。

• 方案A (懒加载)：将图表功能做成一个独立的 Feature Ability 或 Page，通过 Want在需要时才拉起，而不是在启动时加载整个库。
• 方案B (HSP)：如果主 HAP 和另一个 HAP 都用到这个库，将其打包成 ChartLibrary.hsp。在 module.json5中配置依赖，系统在安装时会保证只存在一份 ChartLibrary.hsp副本，主 HAP 和其他 HAP 共享它。

六、运行结果与测试步骤

1. 基线测试：
   • 执行一次干净的 release构建。
   • 记录 Build Analyzer显示的总包体积​ (例如: 15MB)。
   • 记录 media目录大小和 rawfile目录大小。
2. 分阶段优化与验证：
   • 完成场景一（资源优化）后：再次 release构建。观察包体积变化 (例如: 降至 12MB)。通过 Build Analyzer确认 Resources类别体积减小。
   • 完成场景二（代码优化）后：再次 release构建。观察包体积进一步减小 (例如: 降至 9MB)。通过对比构建产物大小，确认 stripDebugInfo等参数的效果。
   • 分析最终产物：解压最终的 .hap文件，确认 large_png_image.png已被 webp替换，redundant_icon.svg已消失。
3. 功能验证：
   • 将优化后的 HAP 包安装到设备或模拟器上。
   • 完整走查所有功能，确保资源替换、代码混淆和优化没有影响任何业务逻辑和 UI 展示。特别注意图片是否正常显示，字符串是否正确加载。

七、部署场景与疑难解答

部署场景

• Release 版本必选：所有上架应用商店的版本都必须经过严格的 Release 模式构建和优化。
• 持续集成 (CI)：将包体积检查和上限监控集成到 CI/CD 流程中，防止包体因新功能引入而失控增长。
• 多渠道包体：针对不同渠道（如应用宝、华为商店）可能需要生成不同的包，但优化策略应保持一致。

疑难解答

1. 问题：开启 stripDebugInfo后，线上崩溃无法定位。
   • 原因：调试信息被移除，无法通过 addr2line等工具将崩溃堆栈还原为代码行号。
   • 解决：保留一份带符号表的构建产物（不要 stripDebugInfo），仅在需要分析线上问题时使用。同时，集成更强大的 crash 上报 SDK，它们可能自带符号表上传和解析功能。
2. 问题：Tree-Shaking 似乎没生效，无用代码还在。
   • 原因：代码存在副作用（Side Effects）或动态引用，导致编译器不敢移除。
   • 解决：检查代码，避免使用 eval、动态 import()（在构建时无法确定）等。对于纯工具类，确保其方法是纯粹的，没有操作外部状态。可以将这些类/方法标记为 /*#__PURE__*/(如果编译器支持注释提示)。
3. 问题：资源压缩后，图片出现失真。
   • 原因：有损压缩过度或 WebP 转换参数设置不当。
   • 解决：使用质量较高的有损压缩参数重新转换图片，或对于极少数对质量要求极高的图片，保留为原格式，但通过其他方式（如按需加载）减少其对主包的影响。

八、未来展望与技术趋势

• 更智能的构建工具链：未来的 DevEco Studio 可能会提供更精细化的包体分析视图，甚至能给出具体的优化建议。
• AI 驱动的压缩：利用 AI 模型对图片、音频等资源进行内容感知的智能压缩，在指定质量损失阈值下获得最佳压缩率。
• 更强大的按需分发：结合鸿蒙的原子化服务理念，将应用功能拆解得更细粒度，用户可以在需要某个功能时才下载对应的 HAP/HSP，实现“用时即所得”，从根本上解决包体问题。
• 编译时优化 (AOT)：方舟编译器持续优化，生成的 native 代码体积更小，执行效率更高，间接减少了为兼容解释执行而保留的冗余代码。

九、总结

1. 先分析，后动手：始终以 Build Analyzer的数据为指导，优先解决体积占比最高的部分。
2. 组合拳：单一手段效果有限，必须综合运用资源、代码、依赖等多方面的优化技术。
3. 自动化与监控：将优化融入日常开发和 CI 流程，形成长效机制，防止体积反弹。