HarmonyOS-ArkUI Ability进阶系列-UIAbility与各类Context

UIAbility及相关类关系

• 一个模块编译的时候会出一个HAP包， 每一个HAP包在运行时都对应一个AbilityStage。 AbilityStage持有一个AbilityStageContext
• 一个APP， 有时候会有很多个HAP包， 至少一个。 一个APP运行时，对应的是我们的Application。 持有一个ApplicationContext
• 每一个HAP包下，可能存在至少一个UIAbility。 一个UIAbility持有一个UIAbilityContext。
• 每个UIAbility， 都会对应联动创建一个 WindowStage， WindowStage持有Window。 Window会加载我们写的各种Page页面。

大致就是这种关系。

Context

上面我们已经了解了，Application，AbilityStage， UIAbility，ExtensionAbility， WindowStage， Window， Page这些元素， 和他们之间的关系。

下面我们对上图中的红色区域--Context做下讲解。

Context的类关系及分布

上图中的红色区域都是Context。 对于Context而言，它也是一个体系。下图为，Context类继承结构，和其所在位置

Context之间的差异

如果您有开发Android的经验，那Context简直不能太熟了，而且Android上的Context同样存在继承关系，同样具备不同的功能。Context是一种系统设计上的解决方案，几乎所有的界面的，非界面的系统，都需要一种上下文的存在，用来串联各子模块必要的数据。我们这里重点梳理下，上图6个类，类图！看看他们的能力在哪里，边界在哪里。便于以后用到的时候，至少在盘算属性设计的时候，考虑应该更为科学的用哪个。

就拿我们最简单的，Preference(用户首选项)的使用， ApplicationContext创建出来的，和UIAbilityContext创建出来的文件，调用同样的代码，context类型不一样，文件位置就不一样。不太懂得这个细节的，就可能会在这块趟坑。着实没必要浪费这时间。如果了解差异，就会节省出很多的时间。

我花了一天半的时间梳理了所有的Cotext相关类。大大小小加起来约有60个。根本讲不完。我们只捡重点的吧。

BaseContext与Context类

这两个类是总父类，意味着以后得子类都具备他们的特性。

由图中可见，Context在能力

• 记录各类本应用相关的系统存放目录
• 提供了资源管理类-RessourceManager
• 提供了本应用的信息-ApplicationInfo
• 记录了存储加密等级相关信息
• 为事件分发提供了一个工具 EventHub

也就是Context类本身提供的能力，无关于任何界面，任何窗口，也无关什么生命周期。而是相当基础的信息。就是经常用到的，系统相关的一些路径。你也可以理解为，与文件系统相关的那些。

注意在Context类里已经提供了一个获取ApplicationContext的接口。就意味着以后的， UIAbilityContext， AbilityStageContext， ExtensionContext等等，本身就具备获取这个ApplicationContext 的能力。也能调用它的一些方法。

ApplicationContext

ApplicationContext是一个应用试用期间，全局唯一的实例。尽管它的地址在创建各种Ability的时候到处被赋值。但它全局仅仅存在那么一个实例。

ApplicationContext的主要能力从接口中就可以看出

• 感知生命周期
• 感知环境变动
• 管理进程
• 设置语言， 颜色模式(白，还是暗黑)

基本就这些，它的边界其实就是应用级的一些操作。

AbilityStageContext

AbilityStageContext是ApplicationContext的兄弟类！注意是兄弟类。

它的实例关系是，应用由几个HAP包组成，就会有几个AbilityStageContext实例。它的主要能力是记住：

• 模块信息
• 系统配置

应该是它之后的逻辑会用到这些信息。

UIAbilityContext

UIAbilityContext的类层次，同样也是ApplicationContext的兄弟。 可以看出来，尽管他们包管的部分不一样，生命周期不一样，但人家并不是什么父类子类的关系。而是兄弟类。

UIAbilityContext是这几个Context中最复杂的一个，复杂在其持有的参数。几乎每一个都值得去看一下。因为这些参数比如 AbilityInfo， 您写代码的时候怎么在json文件中配置的，它都会最终形成一个实例，这些实例是间接被UIAbilityContext持有的

UIAbilityContext是一个Ability对应一个UIAbilityContext的。它的作用范围也限制在管理当前这个Ability，或者开启其他的Ability。

UIAbilityContext的重点在于

• 管理当前的UIAbility， 杀死自己，或者展示，隐藏。
• 开启其他的Ability，包含但不限于开启UIAbility, 服务等等

ExtensionContext

首先我们得了解一下Extension是什么！

是 HarmonyOS 中用于扩展应用功能的组件，面向特定场景（如输入法、服务卡片、设备驱动等），为应用提供独立于主程序（UIAbility）的扩展服务。它通过 ExtensionAbility 基类实现，具有独立的生命周期和资源管理能力

而其持有一个ExtensionContext， 这个上下文乎主要就是提供包信息， 收集信息

UIAbility中的this.context 与 getContext(this)获得到的Context有无区别

// UIAbility中的.context
export default class entryAbility extends UIAbility {

  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
  getContext(this) //这个是引自common文件的一个方法。获取到的也是UIAbilityContext
   this.context //这个获取的是UIAbility中自带的UIAbilityContext
  }
}

总结：

UIAbility中的this.context 与 getContext(this) 这两种方式都可以获取UIAbilityContext对象，而且获取的都是同样的实例。 只是二者来源不同

• this.context 直接取自UIAbility存储的context句柄
• getContext(this) 是UIAbility引入的包，common中的一个方法。

其实getContext(this) 多在组件中使用，因为组件它没有context属性。所以会靠getContext(this) 拿到context属性。在UIAbility中尽管也能这样用，但有点不对最初设计的味儿。