鸿蒙 Stage模型-应用组件-配置、UIAbility

本文对比了Ohos操作系统中的UIAbility和ExtensionAbility,探讨了它们的概念、模块、生命周期、启动模式、数据传递机制以及ExtensionAbility组件的用途。重点介绍了配置文件、EventHub通信和数据同步策略,以及与Android类似的组件模型和功能实现。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前提:基于官网3.1/4.0文档。参考官网文档
基于Android开发体系来进行比较和思考。(或有偏颇,自行斟酌)

一、概念

在这里插入图片描述
可以看到分为运行期、编译器,主要关注UIAbility(类似Activity,UI相关)、ExtensionAbility(其他非UI相关)。
另外AbilityState暂时不确定是类似Android 中的Application。

为什么会单独有个Stage模型?
其实就是整体架构,只不过为了区分另外一个```Feature模型``,后者已经不主推。

二、模块

1.配置

.json5文件为配置文件,分为:
app.json5:app级别的配置
module.json5:模块级别的配置

示例:

{
   
  "module": {
   
    // ...
    "abilities": [
      {
   
        // $开头的为资源值
        "icon": "$media:icon",
        "label": "$string:EntryAbility_label",
        "skills": [
          {
   
            "entities": [
              "entity.system.home"
            ],
            "actions": [
              "action.system.home"
            ]
          }
        ],
      }
    ]
  }
}

通过json文件来配置,也是和之前

2.UIAbility

是什么?
类似Activity

1.生命周期

在这里插入图片描述

onNewIntent等生命周期是否有?
有,见如下

2.启动模式

singleton(单实例模式):与Android一致,配置文件中配置
multiton(多实例模式):对应Android的standard
specified(指定实例模式):对Ability标记key,一致的key则是统一Ability。

针对第三种模式示例:
1.配置

{
   
  "module": {
   
    // ...
    "abilities": [
      {
   
        "launchType": "specified",
        // ...
      }
    ]
  }
}

2.启动

// 在启动指定实例模式的UIAbility时,给每一个UIAbility实例配置一个独立的Key标识
// 例如在文档使用场景中,可以用文档路径作为Key标识
function getInstance() {
   
    // ...
}

let want = {
   
    deviceId: '', // deviceId为空表示本设备
    bundleName: 'com.example.myapplication',
    abilityName: 'FuncAbility',
    moduleName: 'module1', // moduleName非必选
    parameters: {
    // 自定义信息
        instanceKey: getInstance(),
    },
}
// context为调用方UIAbility的AbilityContext
this.context.startAbility(want).then(() => {
   
    // ...
}).catch((err) => {
   
    // ...
}
### 软件开发中的 Stage 模型生命周期及其各阶段的作用 #### 生命周期概述 Stage 模型是一种现代化的软件开发生命周期模型,尤其适用于复杂的分布式系统开发环境。它不仅定义了清晰的开发流程,还强调模块化设计组件化的实现方式。这种模型通常被应用于现代操作系统(如 HarmonyOS)的应用程序开发中[^2]。 在 Stage 模型中,整个生命周期可以分为多个关键阶段,每个阶段都具有特定的目标职责。以下是其主要阶段以及它们的具体作用: --- #### 1. 需求分析阶段 此阶段的主要目标是对业务需求进行全面收集整理,形成详细的文档描述。这是整个项目的基础,任何后续工作都需要依赖于这一阶段的结果。如果在此阶段未能充分理解客户需求,则可能导致后期频繁修改甚至失败的风险增加[^1]。 #### 2. 设计阶段 进入设计环节后,开发者需依据前一阶段确立的功能规格说明书来制定技术解决方案。对于采用 Stage 架构的产品而言,在这个过程中特别需要注意如何合理划分不同的 Ability 单元——比如区分哪些部分应该由 UIAbility 承担界面展示任务;而另一些后台服务逻辑则更适合交给 ExtensionAbility 来处理[^3]。 此外还需规划好各个模块之间的通信机制,确保数据能够高效准确地传输共享[^4]。 ```javascript // 示例:通过 Want 实现两个 Ability 的参数传递 let want = { bundleName: "com.example.myapp", abilityName: "SecondAbility" }; context.startAbility(want); ``` #### 3. 编码实施阶段 当设计方案得到确认之后便进入到实际编写代码的工作当中去了。按照预先设定好的接口标准分别去实现每一个单独的能力单元 (Ability),并保证他们之间可以通过标准化的方式相互协作互动起来。 值得注意的是,在 HarmonyOS 平台上的具体实践中,每当一个新的 UIAbility 实例被创建出来以后,紧接着就会经历一系列的状态转换过程,其中包括但不限于 Create -> Foreground 这样的典型路径变化轨迹等等。 ```python def create_ui_ability(): """ 创建一个简单的 UIAbility,并初始化窗口舞台。 """ window_stage_created = False def on_window_stage_create(window_stage): nonlocal window_stage_created window_stage.load_content("main_page.xml") # 加载页面布局文件 window_stage.on('windowStageEvent', handle_event) # 订阅事件 window_stage_created = True return on_window_stage_create ``` #### 4. 测试验证阶段 不同于传统的瀑布流模式仅允许线性的推进顺序执行各项操作步骤那样简单明了的做法,在这里由于引入了更多灵活性较高的特性支持的缘故所以相应也增加了不少复杂度方面的考量因素进来考虑范围之内。因此在整个测试期间除了常规意义上的功能性检测之外还需要额外关注跨平台兼容性表现情况等问题是否存在异常状况出现的可能性大小程度等方面的信息反馈回来作为最终评估结论的一部分组成部分之一加以利用参考价值所在之处体现得淋漓尽致。 #### 5. 发布部署阶段 一旦所有的前期准备工作都已经顺利完成并通过严格的质量检验体系认证合格之后就可以正式对外发布上线运行版本供广大用户群体下载安装体验试用了。与此同时为了保障系统的长期稳定可靠运转下去还会持续不断地对其进行优化改进升级维护等工作直至达到预期使用寿命期限为止才停止进一步的动作行为动作[^2]。 --- ### 总结 综上所述可以看出,stage 模型不仅仅只是单纯的一个理论框架概念而已,而是切实可行的一套完整的实践指南手册,帮助团队成员们更好地理解遵循既定规则制度开展各项工作活动从而提高整体效率水平的同时降低潜在风险发生的概率几率大大减少不必要的麻烦困扰局面产生发展蔓延开来影响全局大局观瞻形象声誉受损严重后果不堪设想难以挽回弥补损失惨重代价高昂令人痛心疾首不已!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

ganshenml

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值