HarmonyOS鸿蒙Next中关于APP分层架构是否有问题？目前没啥功能打包成APP包后就已经接近150M了

HarmonyOS鸿蒙Next中关于APP分层架构是否有问题？目前没啥功能打包成APP包后就已经接近150M了 hap是壳工程
hsp是各个业务功能模块
har是底层的基础模块，由hsp依赖并统一对外暴露

APP包看了下，其中空的hsp基本上都是>=9M，这个是什么原理啊？根据我们的架构设计，后续开放大概会有三四十个hsp+har，APP会不会太大了？

3 回复 
HAR：HAR是静态共享包，可以包含代码、C++库、资源和配置文件，只能作为应用模块的依赖项被引用。打包构建时，HAR的编译产物会被放入HAP中，作为HAP的一部分。当HAR在项目中有被多个模块使用方时，使用它的HAP中都拥有一份相同的HAR编译产物。

HSP：HSP是动态共享包，可以包含代码、C++库、资源和配置文件，作为应用模块的依赖项被引用。相较与HAR，HSP中的代码和资源可以独立编译，运行时与应用在同一个进程中，代码只存在一份。应用安装时HSP将会随HAP依次安装至设备中。

hsp太大了，实际功能代码很少，排查一下编译产物里面是不是资源文件很多；

兄弟，你可以尝试这样优化下：
- HSP的resources/rawfile资源：移除非必要资源，改从其他方式获取(如向服务器请求)；打包前对资源进行压缩，应用初始化的时候再对资源文件进行解压。
- HSP本身存在代码冗余的部分：HSP间可以相互依赖，因此抽取公共部分，将HSP拆分为若干HSP，从而降低总的体积。

更多关于HarmonyOS鸿蒙Next中关于APP分层架构是否有问题？目前没啥功能打包成APP包后就已经接近150M了的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


HarmonyOS鸿蒙Next的APP分层架构主要包括应用层、框架层、系统服务层和内核层。应用层负责用户界面和业务逻辑，框架层提供基础服务和API，系统服务层管理硬件资源和系统功能，内核层处理底层硬件交互。APP包体积较大的原因可能包括以下几个方面：

  1. 资源文件过多：应用中可能包含了大量的图片、音频、视频或其他资源文件，这些文件会显著增加包体积。
  2. 依赖库较大：应用可能依赖了较多的第三方库或框架，这些库本身可能体积较大。
  3. 未优化的代码：代码中可能存在冗余或未优化的部分，导致编译后的体积增加。
  4. 未进行压缩或混淆：在打包过程中，未对资源文件或代码进行压缩和混淆处理，导致包体积较大。

要减少APP包体积，可以考虑优化资源文件、精简依赖库、优化代码结构，并在打包时进行压缩和混淆处理。

在HarmonyOS鸿蒙Next中，APP分层架构本身没有问题，但150M的包体积确实偏大。建议从以下几个方面优化：

  1. 资源优化：压缩图片、音频等资源文件，使用WebP等高效格式。
  2. 代码精简：移除未使用的代码和库，使用ProGuard或R8进行代码混淆和优化。
  3. 模块化：将应用拆分为多个模块，按需加载，减少初始包体积。
  4. 依赖管理：检查第三方库，移除不必要的依赖，选择轻量级替代方案。

通过这些措施，可以有效减少APP包体积，提升用户体验。

回到顶部