鸿蒙技术分享：❓❓[鸿蒙应用开发]怎么更好的管理模块生命周期？

鸿蒙HarmonyOS NEXT应用开发架构设计-模块生命周期管理

模块化开发

模块化开发已经是应用开发中的一个共识，一般对于公司级的应用开发，都会考虑是否可以进行模块化开发。

HarmonyOS NEXT系统应用开发目前使用的Stage模型其实就有涉及模块化开发的部分，比如HAP、UIAbility。

但是，官方模式总是存在一些莫名其妙的问题。

HAP

官方对于通过HAP进行模块化开发的场景见MultiHap。

使用多HAP时，那最常见的HAP见跳转如何处理？

使用Want跳转到其他的Ability：在entry模块的index.ets中通过common.UIAbilityContext()配置Want，作为多hap间信息传递的载体，用于应用组件间的信息传递；
新hap的跳转：在entry模块index.ets首页中，在按钮.onclick()事件内，通过Want配置显式拉起一个新的指定的Ability。
例如：以配置videoFeature模块Want配置为例，在触发按钮事件中加入配置的Want：
· btn.onClick(() => {this.context.startAbility({ bundleName: BUNDLE_NAME, abilityName: AUDIO_ABILITY_NAME }}
· 其中bundleName为appscope文件夹下app.json5中"bundleName": "com.samples.multihap"。
· abilityName为videoFeature模块src/main/module.json5中abilities：["name": "VideoAbility"]

也就是跨模块跳转需要用startAbility。

而正常的页面跳转是用router或者Navigation。

这样就存在方案的不一致性，在做统一的路由管理时反而不方便。

AbilityStage组件容器

上面的HAP方案是基于应用包结构的。
而Stage开发模型和应用包结构不等同，官方文档也是分开讲述的。

多HAP方案对于模块生命周期的使用，其实也是基于UIAbility的。

而UIAbility其实是不唯一的，就算是在一个HAP中也可能存在多个。那么严格来说，用UIAbility来进行模块生命周期管理其实也不足够恰当。

而Stage模型中也有一个专门的模块级别容器，专门用来托管模块的生命周期，AbilityStage组件容器。

AbilityStage是一个Module级别的组件容器，应用的HAP在首次加载时会创建一个AbilityStage实例，可以对该Module进行初始化等操作。
AbilityStage与Module一一对应，即一个Module拥有一个AbilityStage。

所以，当你采用多HAP方案进行模块化开发时，其实更应该用AbilityStage进行生命周期管理。

自主管理模块生命周期

那么除了HAP，还有没有其他的模块生命周期管理方案呢？

有的。

    /*** Register ability lifecycle callback.** @param { 'abilityLifecycle' } type - abilityLifecycle.* @param { AbilityLifecycleCallback } callback - The ability lifecycle callback.* @returns { number } Returns the number code of the callback.* @throws { BusinessError } 401 - Parameter error. Possible causes: 1.Mandatory parameters are left unspecified. 2.Incorrect parameter types.* @syscap SystemCapability.Ability.AbilityRuntime.Core* @stagemodelonly* @crossplatform* @atomicservice* @since 11*/on(type: 'abilityLifecycle', callback: AbilityLifecycleCallback): number;

系统其实开放了Ability级别的生命周期方法监听，你可以通过注册的方式托管系统的生命周期管理方法，然后用自己的逻辑进行处理。

比如：

1. 自定义一个ModuleLifecycleManager类，通过监听方法接管生命周期管理。
2. ModuleLifecycleManager类增加管理方法，允许自主添加具体模块的实例。
3. ModuleLifecycleManager类内部在触发相关方法时，遍历调用已添加模块的同名方法。
4. 可以使用HSP、HAR作为模块，只需要在模块中创建模块实例，并添加到ModuleLifecycleManager类中；

参考实现

import LinkedList from '@ohos.util.LinkedList'
import AbilityLifecycleCallback from '@ohos.app.ability.AbilityLifecycleCallback';
import UIAbility from '@ohos.app.ability.UIAbility';
import window from '@ohos.window';
import { Context } from '@ohos.abilityAccessCtrl';export declare class CustomAbilityLifecycleCallback extends AbilityLifecycleCallback {lazyInit(context : Context): void;onRegiste?(context : Context): void;
}export class ModuleLifecycleManager {private constructor() {}private static instance: ModuleLifecycleManagerprivate lifecycleId = 0context?: Contextpublic static getInstance(): ModuleLifecycleManager {if (!ModuleLifecycleManager.instance) {ModuleLifecycleManager.instance = new ModuleLifecycleManager()}return ModuleLifecycleManager.instance}async init(context: Context, moduleFiles?: Array<Promise<ESObject>>) {this.context = contexttry {for (let item of moduleFiles) {await item.then((result: ESObject) => {result.registerAbilityLifecycleCallback()}).catch((error: ESObject) => {})}this.lifecycleId = this.context?.getApplicationContext().on('abilityLifecycle', abilityLifecycleCallback);} catch (paramError) {console.error(`error: ${paramError.code}, ${paramError.message}`);}}async append(moduleFiles?: Array<Promise<ESObject>>) {try {for (let item of moduleFiles) {await item.then((result: ESObject) => {result.registerAbilityLifecycleCallback()}).catch((error: ESObject) => {})}} catch (paramError) {console.error(`error: ${paramError.code}, ${paramError.message}`);}}unInit() {this.context?.getApplicationContext().off("abilityLifecycle", this.lifecycleId)}agreePrivacyPolicy() {for (let item of this.abilityLifecycleCallbacks) {item.lazyInit(this.context!)}}private abilityLifecycleCallbacks = new LinkedList<CustomAbilityLifecycleCallback>()getAbilityLifecycleCallbacks(): LinkedList<CustomAbilityLifecycleCallback> {return this.abilityLifecycleCallbacks}registerAbilityLifecycleCallback(abilityLifecycleCallback: CustomAbilityLifecycleCallback) {this.abilityLifecycleCallbacks.add(abilityLifecycleCallback)if (abilityLifecycleCallback.onRegiste != undefined) {abilityLifecycleCallback.onRegiste(this.context)}}unRegisterAbilityLifecycleCallback(abilityLifecycleCallback: CustomAbilityLifecycleCallback) {this.abilityLifecycleCallbacks.remove(abilityLifecycleCallback)}
}let abilityLifecycleCallback: AbilityLifecycleCallback = {onAbilityCreate: function (ability: UIAbility): void {for (let item of ModuleLifecycleManager.getInstance().getAbilityLifecycleCallbacks()) {item?.onAbilityCreate(ability)}},onWindowStageCreate: function (ability: UIAbility, windowStage: window.WindowStage): void {for (let item of ModuleLifecycleManager.getInstance().getAbilityLifecycleCallbacks()) {item?.onWindowStageCreate(ability, windowStage)}},// 其他方法省略...
}

总结

鸿蒙官方文档中罗列了太多的概念，HAP/HSP/HAR、Entry/feature、Application/Ability/Window/Stage，其实对于正常开发模式的讲解并不清晰。

而且build-profile.json5/module.json5等配置化的开发模式对于应用开发架构的灵活性有很大限制。

就像router/Navigation的路由表配置那样，一旦涉及配置文件，最终的方案基本都会归拢到hvigor插件上，而不是纯代码的运行时。

配置化和运行时各自可能有利有弊吧，本文仅提供一种新的架构解决方案供大家参考。