鸿蒙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，还有没有其他的模块生命周期管理方案呢？

有的。

TypeScript
 代码解读
复制代码
    /**
     * 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类中；

参考实现

typescript
 代码解读
复制代码
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: ModuleLifecycleManager
  private lifecycleId = 0
  context?: Context

  public static getInstance(): ModuleLifecycleManager {
    if (!ModuleLifecycleManager.instance) {
      ModuleLifecycleManager.instance = new ModuleLifecycleManager()
    }
    return ModuleLifecycleManager.instance
  }

  async init(context: Context, moduleFiles?: Array<Promise>) {
    this.context = context
    try {
      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>) {
    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插件上，而不是纯代码的运行时。

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