HarmonyOS 鸿蒙Next中优化应用多余数据
HarmonyOS 鸿蒙Next中优化应用多余数据 【问题描述】:像这个我应该如何优化?数据包应该是400多M,突然多出这么多内存出来
【问题现象】:数据包多出来很多数据,有没有上面办法可以优化多余数据

【版本信息】:未涉及
【复现代码】:未涉及
【尝试解决方案】:未涉及
更多关于HarmonyOS 鸿蒙Next中优化应用多余数据的实战教程也可以访问 https://www.itying.com/category-93-b0.html
【背景知识】 减小应用包大小是提升应用下载和安装体验的重要方式。通过压缩、精简或者复用应用中的代码或资源,可以有效降低应用包体积大小,减少空间占用,从而达到提升应用下载和安装速度的目的。在了解如何优化包大小之前,需要先了解HarmonyOS应用的应用程序包结构。在进行应用程序包大小优化分析时,可以使用扫描工具扫描分析App包,根据输出的检测报告,采取相应措施优化应用。
【解决方案】 优化应用包大小主要有以下手段:
-
对于含有so库的App工程,可以配置so库压缩选项,通过压缩so库来减小应用包大小。当前DevEco Studio默认打包应用时不压缩so库文件,配置so压缩选项后,DevEco Studio会将so库文件以压缩形式打包到包中,从而减小应用包大小。 配置方法:修改应用模块配置文件module.json5中的compressNativeLibs字段,将值配置为true,重新编译、打包应用。
{ "module": { // ... "compressNativeLibs": true // 标识libs库以压缩存储方式打包 } } -
应用存在多包(HAP、HSP)的场景时,可以使用HSP动态共享包在应用的多个包(HAP、HSP)之间共享代码和资源,消除使用HAR静态共享包造成的多包(HAP、HSP)间代码和资源的重复拷贝,从而减小应用包大小。参考文档:多包场景下使用HSP共享代码和资源。
-
使用ohpm的override机制或者开启resolve_conflict解决依赖冲突减少依赖包导致的重复编译问题。对于ohpm 1.5.0之前的版本,如果HAP依赖了不同版本的HAR(如下图中V1版本的harC和V2版本的harC),在打包HAP时,默认会把V1和V2两个版本的harC都打包到包中。开发者可以使用ohpm的override机制,指定只打包一份。
-
如果使用的是ohpm1.4.0版本,可以使用override机制,开发者可以在项目级别的oh-package.json5 (即项目根目录下的oh-package.json5)文件中添加overrides配置,将依赖树中的依赖替换为另一个版本。替换的版本既可以是一个具体的版本号,也可以是本地存在的HAR包或源码目录。
-
将用户不常用功能作为按需加载模块。参考文档:按需分发。
更多关于HarmonyOS 鸿蒙Next中优化应用多余数据的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
在HarmonyOS Next中,优化应用多余数据主要通过系统级数据管理实现。系统会自动清理应用缓存、临时文件等非必要数据,并限制后台应用的数据存储行为。开发者可使用ArkTS的API管理应用数据生命周期,例如通过storage模块进行本地数据清理,或利用dataShare模块共享数据以减少冗余。应用应遵循最小数据存储原则,及时释放不再使用的资源。系统设置中提供存储空间管理功能,用户可手动清理应用数据。


