济南网站制作技术交流,seo网站建设培训,锐速做网站,pc站和手机网站HarmonyOS 应用模块化设计 - 面试核心知识点 在 HarmonyOS 开发面试中#xff0c;模块化设计是必考知识点。本文从面试官角度深度解析 HarmonyOS 应用模块化设计#xff0c;涵盖 HAP、HAR、HSP 等核心概念#xff0c;助你轻松应对技术面试#xff01; #x1f3af; 面试高…HarmonyOS 应用模块化设计 - 面试核心知识点 在 HarmonyOS 开发面试中模块化设计是必考知识点。本文从面试官角度深度解析 HarmonyOS 应用模块化设计涵盖 HAP、HAR、HSP 等核心概念助你轻松应对技术面试 面试高频问题什么是模块化设计
面试官常问请解释 HarmonyOS 应用模块化设计的核心理念
标准答案
在大型软件工程中模块化设计是现代软件工程的核心原则之一。通过将大型复杂系统拆解为更小、更易管理和理解的功能模块提高系统的可维护性和可扩展性。
核心特点
多团队弱耦合协作开发契约化接口定义业务交互各团队业务独立发展互不影响支持快速迭代演进
在 HarmonyOS 中的体现
模块化既是设计原则也是开发实践将应用程序拆分为多个功能模块每个模块负责特定功能或特性支持独立开发、编译和部署可在不同设备上灵活组合和调用 面试重点一应用程序包结构
面试官HarmonyOS 的应用包结构有哪些类型
回答要点
在进行模块化设计时需要考虑 HarmonyOS 的应用包结构选型
开发态源码组织方式编译态编译过程中的包形态发布态最终发布的应用包结构
关键概念
HAPHarmonyOS Ability PackageHARHarmonyOS ArchiveHSPHarmonyOS Shared Package 面试重点二Ability 应用组件设计
面试官在多设备场景下如何设计 Ability 组件 面试要点 1多任务多窗口场景
手机设备应用场景
// 笔记应用 - 多页面复制场景
// 文档编辑应用 - 多文档同时编辑
// 导航应用 - 后台运行 主页查找
// 购物应用 - 客服界面快速切换
// 支付应用 - 信息查找复制实际应用示例
笔记应用可让用户将信息从笔记的一页复制到另一页文档编辑应用可让用户同时打开编辑多个文档可让用户将内容从一个文档复制或移动到另一个文档导航/打车应用可以让导航后台运行回到主页查找新的位置信息或其它信息购物类临时客服界面可让用户通过任务管理快速从商品浏览页切换回到客服会话界面避免用户一层层打开查找在应用支付/登录页面用户可以切换到其他页面查找并复制相关信息
大屏设备应用场景
// 视频播放器 - 播放 浏览列表
// 电子邮件 - 撰写 查看收件箱
// 地址簿 - 并排比较联系信息
// 阅读应用 - 多篇文章同时打开实际应用示例
视频播放器应用可让用户在观看播放内容的同时浏览其他可能感兴趣的视频列表电子邮件应用可让用户在撰写电子邮件的同时查看收到的邮件列表地址簿应用可让用户并排比较多个人员的联系信息阅读应用可让用户在查阅所有标题概要后打开多篇文章供稍后阅读 面试要点 2Ability 设计原则
单 Ability 情况
单窗口类型应用多实例或指定实例的多任务应用普通游戏应用建议采用单 HAP 承载 UIAbility
多 Ability 情况 多窗口类型应用 每个窗口对应不同功能通过不同的 UIAbility 承载可设计为 Feature 类型的 HAP 应用扩展功能 卡片和分享业务由系统提供的 ExtensionAbility 承载建议通过 Feature 类型的 HAP 承载 面试重点三应用模块化选型
面试官如何选择合适的模块类型 面试技巧三种模块类型对比
模块类型特点使用场景面试要点Entry HAP应用主入口默认存在且唯一应用启动入口每个应用必须有且仅有一个Feature HAP独立功能模块可按需加载独立功能、扩展能力支持独立安装和运行HAR静态共享库代码复用、跨应用共享编译时打包进目标模块HSP动态共享库按需加载、运行时共享独立安装运行时加载 面试加分项三种业务场景分析
1. 共享模块场景
图 1 多工程合作模式
面试官什么是共享模块
回答要点
某个功能模块需要在多个应用之间共享代码逻辑和资源通过公司私有的 OHPM 仓发布和集成编译产物支持多团队代码仓隔离开发只能使用 HAR 模块实现
2. 按需加载模块场景
面试官按需加载模块有什么优势
回答要点
减少包体积首次下载不包含按需加载模块减少系统资源节省 ROM 和 RAM 空间架构演进模块间耦合关系清晰
技术选型
Feature 类型的 HAP可包含 Ability 组件HSP不包含 Ability 组件的按需加载
场景划分
单 HAP 场景只包含一个 UIAbility 组件优先采用单 HAPEntry 类型的 HAP来实现应用开发多 HAP 场景要实现多任务承载多个 UIAbility 组件以及使用 ExtensionAbility 组件实现扩展功能
3. 多 HAP/HSP 引用相同 HAR 包的影响
图 2 HAP 包和 HSP 包分别引用相同 HAR 包
面试官多模块引用同一 HAR 包会有什么问题
回答要点
破坏 HAR 的单例模式导致方法在多个模块中重复执行增加应用冷启动时间
技术原理 工程内包含三个模块HAP 包作为应用主入口模块HSP 包作为应用主界面显示模块HAR_COMMON 集成了所有通用工具类其中 funcResult 是 func 方法的执行结果。
当 HAP 和 HSP 模块同时引用 HAR_COMMON 模块时会破坏 HAR 的单例模式。因此HAP 和 HSP 模块在使用 HAR_COMMON 中的 funcResult 时会导致 func 方法在两个模块加载时各执行一次从而增加文件的执行时间。
优化方案
图 3 切换为 HAP 包和 HAR 包分别引用相同 HAR 包
优化建议
在多 HAP/HSP 引用相同 HAR 包的情况下如果 HSP 包和 HAR 包均能满足业务需求建议将 HSP 包改为 HAR 包若使用的 HSP 为集成态 HSP可跳过该优化方案
性能测试代码示例
// 1. 在被引用 HAR_COMMON 包中写入功能示例
// 2. 分别通过使用 HSP 包和 HAR 包来引用该 HAR_COMMON 包中的功能进行性能对比实验// 使用 HAP 包和 HSP 包引用该 HAR_COMMON 包中的功能
// HAP 包引用 HAR_COMMON 包中的功能// 使用 HAP 包和 HAR 包引用该 HAR_COMMON 包中的功能
// HAP 包引用 HAR_COMMON 包中的功能性能分析 使用 Launch 模板对优化前后启动性能进行对比分析。
分析阶段的起点为启动 Ability即 H:void OHOS::AppExecFwk::MainThread::HandleLaunchAbility 的开始点阶段终点为应用第一次接到 vsync即 H:ReceiveVsync dataCount:24Bytes now:timestamp expectedEnd:timestamp vsyncId:int 的开始点。
图 4 优化前使用 HSP 包
图 5 优化后使用 HAR 代替 HSP
性能对比数据
方案阶段时长(毫秒)性能提升优化前使用 HSP 包3125-优化后使用 HAR 代替 HSP853.973% ↑
说明 上述示例为凸显出差异func 执行函数循环次数为 100000000开发者实际修改后收益需根据实际情况测试。
测试数据表明将 HSP 替换为 HAR 包后应用启动耗时明显缩短。 面试重点四单 HAP 工程设计
面试官单 HAP 工程如何进行模块化设计 面试要点 1不包含按需加载模块
图 6 非按需加载工程模型
设计原则 对于不需要按需加载且仅包含一个 Entry 类型的 HAP 的 App可以直接全部采用 HAR 进行开发设计。
说明 这里提到的仅有一个 HAP是指一种设备类型仅包含一个 HAP而不是指.app 文件包中仅有一个 HAP。.app 文件包可以包含其他设备的 HAP 包例如手表和大屏设备的 HAP 包以支持多设备分发。
架构特点
除产品模块层的 HAP 外其他模块均为 HAR所有 HAR 最终编译进 HAP 中
优点
无额外 HSP节省安装和加载成本利用 ArkTS 语言特性和编译器优化代码工程架构简单演进灵活 面试要点 2包含按需加载模块
面试官如何在单 HAP 工程中实现按需加载
技术选型考虑 在单 HAP 工程中实现按需加载功能时对应的组件需采用 HSP 作为按需加载模块。HAR 是静态共享库若多个 HAP 或 HSP 依赖同一份 HAR该 HAR 在应用内会被重复存储。HSP 是动态共享库其安装和加载会有性能损失过多的 HSP 可能影响安装效率和 App 启动性能。需考虑 App 占用空间是否受限及启动性能的敏感度根据业务需求在 App Size 与启动性能之间做好平衡。
说明 这里提到的 App Size 指用户安装按需加载模块后应用的整体大小。
App Size 优先方案
图 7 公共依赖模块通过 HSP 模块壳承载
设计思路 对于 App Size 优先的可以考虑将公共依赖的模块封装在一个 HSP 模块壳中。
// 模块依赖关系示例
// hap_A 依赖har_A har_C har_D
// hsp_B 依赖har_B har_C har_D
// 解决方案将 har_C 和 har_D 封装到 common_hsp 中实现方案 hap_A 依赖于独有的共享库 har_A同时需要依赖于 har_C 和 har_D而按需加载模块 hsp_B 依赖于独有的共享库 har_B同时需要依赖于 har_C 和 har_D。
说明 这里的共享库 har_A、har_B、har_C、har_D 不一定本地工程有可能是从 ohpm 仓上依赖下载的。
因为 har_C 和 har_D 同时被 hap_A 和 hsp_B 工程所依赖所以为了节省 App Size可以将其封装到名为common_hsp的 Module 中对外暴露 har_C 和 har_D 的接口将 har_C 和 har_D 打包到 common_hsp 中最后让 hap_A 和 hsp_B 依赖于 common_hsp 工程。common_hsp 工程是无实际意义的它仅是一个模块壳是为了最小化 App Size 而存在的。
性能优先方案
图 8 公共依赖模块使用 HAR 模块承载
设计思路 对于性能优先的则不需要再封装一个公共的 HSP 模块直接依赖公共 HAR 包。
因为公共 HSP 包需要安装和加载所以会有一些性能损耗。对于启动性能敏感型的应用则将 hap_A 和 hsp_B 直接依赖于 har_C 和 har_D。最终编译产物里面有 2 个hap_A.hap 和 hsp_B.hsp但是这两个编译产物里面均会包含 har_C 和 har_DApp Size 会比采用公共 HSP 模型大。 面试重点五多 HAP 工程设计
面试官多 HAP 工程的设计原则是什么 面试技巧多 HAP 应用场景
适用场景 对于同一个设备类型如果要实现不同的独立功能模块并且相对独立以及具有单独的入口的功能特性建议做成一个独立特性的 HAP按需下载安装。
组成结构 此时一个 App 包中就会有多个 HAP 包其中有且仅有一个 Entry 类型的 HAP其他的均是 Feature 类型的 HAP。多 HAP 之间业务独立但是可能会有业务能力共享所以在进行模块化设计时需要根据是否具有公共能力来进行选择。 面试要点 1包含公共能力模块
面试官多 HAP 工程如何处理公共能力模块
对于具备公共能力模块的工程和上述 HAPHSP 组合是类似的需要考虑在 App Size 与启动性能之间做平衡。
性能优先方案
图 9 多 HAP 工程模块示意图
特点 一般多 HAP 应用架构普适性采用以下模型除了产品组件中存在 HAP 包之外其余的均是 HAR 包。
编译产物中多个 HAP 之间存在相同的 HAR 包如 har_2、har_3、har_C、har_D、har_E。这种情况下App Size 可能会增大。如果 App Size 不是应用的瓶颈或者 HAR 包的大小较小对 App Size 的影响可控可以采用这种模型从而减少动态加载的性能损耗。
App Size 优先方案
图 10 多 HAP 工程模块示意图
设计思路 上述问题的本质在于如何在 HAP 和 HSP 之间分布 HAR 包以最小化 App 的大小并减少 HAR 的重复编译和打包。主要思路是将公共能力模块封装为公共 HSP从而最小化 App Size。
⚠️ 重要注意事项 需要注意在应用间共享的 HAR 包原则上是不允许依赖 HSP 包因为 HSP 包是专属于应用和 bundleName 进行了绑定一旦 HAR 包依赖于应用内 HSP该 HAR 包就丢失了共享性无法再给其他应用共享。
实现方案 如上图所示有 3 个 HAP 包1 个 entry 和 2 个 feature将公共的 HAR 包封装到 HSP 工程中例如 common_wrap_hsp 和 feature_wrap_hsp。
// 模块壳设计示例
// common_wrap_hsp 和 feature_wrap_hsp 仅为模块壳
// 用于合理放置模块在编译产物中的位置
// 不具备模块功能不能共享仅能在 App 应用内使用这两个 HSP 从严格意义上讲不能称为模块仅称为模块壳用于合理放置模块在编译产物中的位置不具备模块功能不能共享仅能在 App 应用内使用依赖这些模块壳的模块也无法在应用间共享。
上述的模型通过 HSP 将 HAR 包合理分配到编译产物中确保每个 HAR 包在 App 编译产物中仅出现一次从而减小 App Size。模块壳数量不宜过多否则可能影响安装速度和启动性能。
平衡方案 这两种模型都是理想模型业务模型通常是两者的平衡态或组合。例如某个共享库代码和资源较少占用空间较小如打印日志模块。将该模块编译进所有编译产物中App Size 增加较少同时性能较好。 面试要点 2不包含公共能力模块
回答要点 这种应用较少即使有的话也是一些规模较小的应用可以参考单 HAP 的场景。 面试总结模块化设计决策树 决策流程图
应用模块化设计
├── 是否需要独立运行和安装
│ ├── 是 → Feature HAP
│ └── 否 → 继续判断
├── 是否需要按需加载
│ ├── 是 → HSP
│ └── 否 → 继续判断
├── 是否需要跨应用共享
│ ├── 是 → HAR (通过 OHPM 仓)
│ └── 否 → HAR (应用内使用)
└── 性能 vs App Size 权衡├── 性能优先 → HAR└── App Size 优先 → HSP 模块壳面试记忆口诀
“独立运行选 HAP按需加载用 HSP跨应用共享靠 HAR”
HAP独立 Ability独立安装HSP动态共享按需加载HAR静态共享编译打包 面试优势回答模板
面试官如何选择合适的模块化方案
完美回答
应用开发者需根据技术架构选择适合的工程模块化模型。工程模块化模型需根据业务和技术架构演进而演进。根据诉求在 HAP、HAR 和 HSP 中选择使用。
具体选择标准
独立运行和安装的模块只能选择 HAP 包并将其作为 Feature 类型的 HAP 存在于 App 中按需加载模块对于不具备独立特性部分用户使用频率较少的模块将其做成 HSP 按需加载模块存在于 App 中共享模块对于需要共享的模块只能采用 HAR 包将其通过 OHPM 仓共享给其他工程使用性能优化HAR 是静态共享库在多 HAP 或者按需加载场景下在编译后可能会在物理上存在多份所以需要合理采用公共 HSP 模块壳使 App Size 最小化
