鸿蒙开发5.0【应用包体积大小优化】解决方案

应用包体积大小也是应用体验的一个重要指标，体积过大会严重影响应用下载安装体验，且会占用较大的设备空间，因此包体积过大的应用会有包体积优化的诉求。想要优化应用包体积首先要分析应用包体积大的原因，一般包体积大的原因可以分为文件重复、大文件两大类，其中文件重复Har重复和其他类型文件重复，大文件可以分为so文件大和其他类型文件大，针对不同的原因有针对性的优化方案。

分析应用包体积大的原因

1. app-check-tool

   [app-check-tool]应用包扫描工具，可以扫描指定路径的HAP、HSP、App包内容并输出检测结果报告，为开发者优化包结构或排查问题提供数据支撑。目前扫描工具支持以下几种分析统计：

   • 扫描重复文件。
   • 扫描超出指定大小的文件。
   • 统计分析各类型文件的总大小和占比。

   使用app-check-tool扫描文件大小占比，找到占比大文件，看是否为so文件，是否为重复文件，如果是重复文件，进一步查看重复原因，是否HAR重复引用导致，通过这些判断基本可以初步是被应用包体积大的原因。

2. 从应用工程模块依赖判断是否存在HAR包重复

   HAR包重复问题还可以从工程模块依赖的维度来识别，应用方可以统计工程各目录的oh-package.json5中的依赖来判断是否存在HAR包重用的情况，如多个HAP或HSP依赖了同一个HAR。

文件重复

1. HAR包重复

   HarmonyOS应用采用模块化开发，模块类型包含HAP，HSP，HAR三种类型:

   模块类型	功能描述
   HAP（Harmony Ability Package）	用于实现应用的功能和特性，HAP包可以独立安装和运行，是应用安装的基本单位，一个应用中可以包含一个或多个HAP包
   HSP（Harmony Archive）	动态共享库，用于实现代码和资源的共享， HSP中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。
   HAR（Harmony Shared Package）	静态共享库，用于实现代码和资源的共享，HAR中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。

   HAR和HSP在APP包中的形态示意图：

   

   从上图可以看到如果应用中的某个HAR包被多个HAP/HSP引用，那么HAR包会存在多分拷贝，会存在冗余代码和资源，而使用HSP来替换HAR可以共享一份代码和资源，从而降低应用程序体积。

2. 其它类型文件重复

   如果重复文件不是由于HAR重复引用导致的，且重复文件比较大，可以考虑重复文件是否必要，如果非必要可以删除，如果必要可以考虑压缩。

大文件

1. so文件大

   配置so压缩打包。

   如果通过扫描发现是包中的so文件较大，可以在HAP/HSP（HAR中不需要配置）模块的module.json5中配置compressNativeLibs字段为true来压缩HAP/HSP包中的so的体积：

   // 模块的module.json5文件
   {
     "module": {
     // ...
     "compressNativeLibs": true // 标识libs库以压缩存储方式打包
   }
   }
   

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

   文件名	原始大小	压缩后大小
   armeabi-v7a/libc++_shared.so	1233k	436k

   配置so压缩打包的压缩率等级。

   在工程目录下的hvigor目录中的hvigor.json5中配置ohos.pack.compressLevel属性，可以改变so压缩打包的压缩率。

   //工程目录下的hvigor目录下的hvigor.json5
   {
     // ..
     "properties": {
     "ohos.pack.compressLevel": "fast"  //三种等级fast standard ultimate
   }
   }
   

   压缩等级	描述
   fast（缺省默认值）	最低等级的压缩率，压缩速度最快。
   standard	适中等级的压缩率，压缩速度适中。
   ultimate	最高等级的压缩率，压缩速度最慢。

   开启strip，去除debug信息。

   so文件未执行strip时，会包含大量的debug信息，导致so体积大大超出预期， IDE新建模块会默认开启release模式下的strip，但是部分应用可能仍然会漏配strip导致so体积过大。so是否strip可以使用linux的file命令来查看，如果显示with debug_info, not stripped说明so未strip，如果显示stripped说明so已strip。

   

   

   可通过在HAP/HSP（HAR中不需要配置）模块的build-profile.json5中开启strip，来移除.so文件中的符号表、debug信息，从而可以大大降低so的体积。

   {
     // 模块的build-profile.json5
     "buildOptionSet": [
       {
         "name": "release",
         // ...
         "nativeLib": {
           "debugSymbol": {
             "strip": true,
             "exclude": []
           }
         }
       },
       {
         "name": "debug",
         // ...
         "nativeLib": {
           "debugSymbol": {
             "strip": true,
             "exclude": []
           }
         }
       }
     ]
   }
   

   注：release模式和debug模式都可以开启strip。

   以DevEco Studio中C++默认库文件为例，压不开strip和开启strip的so体积大小对比如下：

   文件名	原始大小	strip后大小
   armeabi-v7a/libentry.so	531k	96k

2. 其它类型文件大

   其它类型的大文件根据业务实际情况看是否可以删除或压缩。

以上就是本篇文章所带来的鸿蒙开发中一小部分技术讲解；想要学习完整的鸿蒙全栈技术。可以在结尾找我可全部拿到！
下面是鸿蒙的完整学习路线，展示如下：

除此之外，根据这个学习鸿蒙全栈学习路线，也附带一整套完整的学习【文档+视频】，内容包含如下：

内容包含了：（ArkTS、ArkUI、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、鸿蒙南向开发、鸿蒙项目实战）等技术知识点。帮助大家在学习鸿蒙路上快速成长！

鸿蒙【北向应用开发+南向系统层开发】文档

鸿蒙【基础+实战项目】视频

鸿蒙面经

为了避免大家在学习过程中产生更多的时间成本，对比我把以上内容全部放在了↓↓↓想要的可以自拿喔！谢谢大家观看！