鸿蒙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级别的生命周期方法监听,你可以通过注册的方式托管系统的生命周期管理方法,然后用自己的逻辑进行处理。
比如:
- 自定义一个
ModuleLifecycleManager
类,通过监听方法接管生命周期管理。 ModuleLifecycleManager
类增加管理方法,允许自主添加具体模块的实例。ModuleLifecycleManager
类内部在触发相关方法时,遍历调用已添加模块的同名方法。- 可以使用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插件上,而不是纯代码的运行时。
配置化和运行时各自可能有利有弊吧,本文仅提供一种新的架构解决方案供大家参考。