我们参照一多的样例工程,将功能较独立的模块拆出来作为一个module(HSP),原entry依赖各个功能module的形式,打release包的时候发现,生成的app文件比原来大了好几倍,将app解压发现里面的.hsp每个都40M+,然而每个功能Module并未携带大文件只是些源码。
感觉像是每个Module都携带了可能重复的底层依赖的东西。
想问一下是否有什么需要配置的,可以避免携带系统或者框架的东西,避免导致多个Module形式的工程打出的APP尺寸过大?
我们参照一多的样例工程,将功能较独立的模块拆出来作为一个module(HSP),原entry依赖各个功能module的形式,打release包的时候发现,生成的app文件比原来大了好几倍,将app解压发现里面的.hsp每个都40M+,然而每个功能Module并未携带大文件只是些源码。
感觉像是每个Module都携带了可能重复的底层依赖的东西。
想问一下是否有什么需要配置的,可以避免携带系统或者框架的东西,避免导致多个Module形式的工程打出的APP尺寸过大?
1 回答1.1k 阅读✓ 已解决
1 回答1.4k 阅读
1 回答1.2k 阅读
1 回答1.1k 阅读
1 回答1.1k 阅读
1 回答989 阅读
1 回答967 阅读
可以先用app-check-tool扫描下,参考文档:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/app-check-tool-V5
app-check-tool的目录为D:\DevEco Studio 5.0.1.600\sdk\HarmonyOS-NEXT-DB3\openharmony\toolchains\lib下
根据扫描结果判断
1.是否有HAR包过多重复
如果应用中的某个HAR包被多个HAP/HSP引用,那么HAR包会存在多分拷贝,会存在冗余代码和资源,而使用HSP来替换HAR可以共享一份代码和资源,从而降低应用程序体积
2.其他类型文件重复
如果重复文件不是由于HAR重复引用导致的,且重复文件比较大,可以考虑重复文件是否必要,如果非必要可以删除,如果必要可以考虑压缩。
3.so文件大
3.1如果通过扫描发现是包中的so文件较大,可以在HAP/HSP(HAR中不需要配置)模块的module.json5中配置compressNativeLibs字段为true来压缩HAP/HSP包中的so的体积:
3.2配置so压缩打包的压缩率等级
在工程目录下的hvigor目录中的hvigor.json5中配置ohos.pack.compressLevel属性可以改变so压缩打包的压缩率。
3.3so文件未执行strip时,会包含大量的debug信息,导致so体积大大超出预期, IDE新建模块会默认开启release模式下的strip,但是部分应用可能仍然会漏配strip导致so体积过大。
so是否strip可以使用linux的file命令来查看,如果显示with debug\_info, not stripped说明so未strip,如果显示stripped说明so已strip。
linux命令:file libentry.so
可通过在HAP/HSP(HAR中不需要配置)模块的build-profile.json5中开启strip,来移除.so文件中的符号表、debug信息,从而可以大大降低so的体积。