鸿蒙5.0 APP性能优化实战——优化应用包体积大小问题

往期推文全新看点（文中附带全新鸿蒙5.0全栈学习笔录）

✏️ 鸿蒙应用开发与鸿蒙系统开发哪个更有前景？

✏️ 嵌入式开发适不适合做鸿蒙南向开发？看完这篇你就了解了~

✏️ 对于大前端开发来说，转鸿蒙开发究竟是福还是祸？

✏️ 鸿蒙岗位需求突增！移动端、PC端、IoT到底该怎么选？

✏️ 记录一场鸿蒙开发岗位面试经历~

✏️ 持续更新中……

---

概述

减小应用包大小是提升应用下载和安装体验的重要方式。通过压缩、精简或者复用应用中的代码或资源，可以有效降低应用包体积大小，减少空间占用，从而达到提升应用下载和安装速度的目的。在了解如何优化包大小之前，需要先了解HarmonyOS应用的 应用程序包结构 。在进行应用程序包大小优化分析时，可以使用扫描工具扫描分析App包，根据输出的检测报告，采取相应措施优化应用。

可以参考以下方法减小应用包大小：

1. 对于含有so库的app工程，可以配置so库压缩选项，通过压缩so库来减小应用包大小。
2. 应用存在多包（HAP、HSP）的场景时，可以使用HSP动态共享包在应用的多个包（HAP、HSP）之间共享代码和资源，消除使用HAR静态共享包造成的多包（HAP、HSP）间代码和资源的重复拷贝，从而减小应用包大小。
3. 使用ohpm的override机制或者开启resolve_conflict解决依赖冲突减少依赖包导致的重复编译问题。
4. 将用户不常用功能作为按需加载模块。

使用扫描工具分析App大小

扫描工具可用于分析检测应用包，根据不同的参数设定，扫描指定路径的App、HAP、HSP包内容并输出检测结果报告，为开发者优化包结构或排查问题提供数据支撑。

根据扫描结果按照如下方式优化应用：

1、重复文件

• 同一包内有重复资源，删除重复资源。
• 多包（HAP、HSP）间重复资源，可以使用HSP实现资源的复用。

2、较大文件

• 确认是否为应用必需，是否可删除。
• JPG、PNG、GIF等文件，可以考虑压缩图片。

3、特定类型文件

so文件，通过配置so库压缩选项来实现压缩打包。

减小应用包大小的方法

配置so压缩选项

当前DevEco Studio默认打包应用时不压缩so库文件，配置so压缩选项后，DevEco Studio会将so库文件以压缩形式打包到包中，从而减小应用包大小。

配置方法

修改应用模块配置文件module.json5中的compressNativeLibs字段，将值配置为true，重新编译、打包应用。

{
  "module": { 
    // ...
    "compressNativeLibs": true // 标识libs库以压缩存储方式打包
  }
}

so压缩效果

以DevEco Studio中C++默认库文件为例，压缩前后的文件大小对比如下：

文件名	原始大小	压缩后大小	压缩率
armeabi-v7a/libc++_shared.so	1108k	386k	34%

解决依赖减少依赖包重复编译

对于ohpm 1.5.0之前的版本，如果hap依赖了不同版本的har（如下图中V1版本的harC和V2版本的harC），在打包hap时，默认会把V1和V2两个版本的harC都打包到包中。开发者可以使用ohpm的 override 机制，指定只打包一份。

如果使用的是ohpm 1.4.0 版本，可以使用override机制，开发者可以在项目级别的 oh-package.json5 （即项目根目录下的 oh-package.json5）文件中添加 overrides 配置，将依赖树中的依赖替换为另一个版本。替换的版本既可以是一个具体的版本号，也可以是本地存在的HAR包或源码目录。

注意：

overrides 必须配置在项目级别的 oh-package.json5 中，配置在模块级别的 oh-package.json5 中将不会生效。

例如，始终希望安装 foo 的 1.0.0 版本，可以在项目级的 oh-package.json5 中增加如下配置：

       {
         "overrides": {
           "foo": "1.0.0"
         }
       }

若本地存在 foo 的源码或者HAR包，想确保 foo 始终使用本地的版本，可以在项目级的 oh-package.json5 中这样配置：

       {
          "overrides": {
             // 本地存在"foo"的源码目录，如项目根目录下的foo目录
             // "foo": "file:./foo" 
             // 本地存在"foo"的HAR文件，如项目根目录下的libs目录中的foo.har（该路径可以为自行配置的合规路径）
             "foo": "file:./libs/foo.har"
          }
       }

对于1.5.0 版本之后的ohpm，可以通过开启resolve_conflict，自动解决依赖冲突，依赖冲突的处理策略为：当您的项目同时依赖了某个三方库的不同版本时，ohpm将选择其中的最高版本进行安装。

按需分发

对于应用中用户不常用的功能，可以考虑通过按需分发的方式，将下载时机交由用户选择，使用时从应用市场获取安装，减少用户初次下载的包大小。

多包场景下使用HSP共享代码和资源

当前系统提供了两种共享包，HAR静态共享包和HSP动态共享包。HAR与HSP都是为了实现代码和资源的共享，都可以包含代码、C++库、资源和配置文件，最大的不同之处在于：HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝；而HSP中的代码和资源可以独立编译，在运行时进程中代码和资源也只会存在一份。

在多包场景下，如果应用的多个HAP或HSP包使用HAR包实现代码和资源的共享，那么打包后的每个HAP或HSP包中都会存在一份共享HAR包的拷贝，导致App包中存在冗余代码和资源。如下图示例，应用模块HAP1和HAP2/HSP1都引用了HAR2和HAR3，打包后，App包中HAR2和HAR3存在多份重复拷贝，体积较大。

这种场景下，推荐开发者使用HSP代替HAR实现代码和资源共享。如下图示例，使用HSP2对原应用进行升级改造，打包后，APP包中HAR2和HAR3只存在一份拷贝，HAR2、HAR3总大小大于HSP时，可以减小应用包大小。