当前位置: 首页>后端>正文

鸿蒙应用开发-初见:入门知识、应用模型

基础知识

Stage模型应用程序包结构

开发并打包完成后的App的程序包结构如图

鸿蒙应用开发-初见:入门知识、应用模型,第1张
  1. 开发者通过DevEco Studio把应用程序编译为一个或者多个.hap后缀的文件,即HAP
  2. 一个应用中的.hap文件合在一起称为一个Bundle,bundleName是应用的唯一标识

需要特别说明的是:在应用上架到应用市场时,需要把应用包含的所有.hap文件(即Bundle)打包为一个.app后缀的文件用于上架,这个.app文件称为App Pack(Application Package),其中同时包含了描述App Pack属性的pack.info文件;在云端(服务器)分发和终端设备安装时,都是以HAP为单位进行分发和安装的。

  1. 所有的HAP最终会编译到一个App Pack中(以.app为后缀的包文件),用于发布到应用市场
鸿蒙应用开发-初见:入门知识、应用模型,第2张

HAP

  1. HAP是HarmonyOS应用安装的基本单位,包含了编译后的代码、资源、三方库及配置文件
  2. 打包后的HAP包结构包括ets、libs、resources等文件夹和resources.index、module.json、pack.info等文件。
  • ets目录用于存放应用代码编译后的字节码文件
  • libs目录用于存放库文件。库文件是HarmonyOS应用依赖的第三方代码(.so二进制文件)。
  • resources目录用于存放应用的资源文件(字符串、图片等)
  • resources.index是资源索引表,由IDE编译工程时生成
  • module.json是HAP的配置文件,内容由工程配置中的module.json5和app.json5组成,该文件是HAP中必不可少的文件。
鸿蒙应用开发-初见:入门知识、应用模型,第3张

Entry类型的HAP

  1. 应用的主模块,在 module.json5配置文件中的type标签配置为“entry”类型。
  2. 同一个应用中,同一设备类型只支持一个Entry类型的HAP,通常用于实现应用的入口界面、入口图标、主特性功能等。

Feature类型的HAP

  1. 应用的动态特性模块,在 module.json5配置文件 中的type标签配置为“feature”类型。
  2. 一个应用程序包可以包含一个或多个Feature类型的HAP,也可以不包含;
  3. Feature类型的HAP通常用于实现应用的特性功能,可以配置成按需下载安装,也可以配置成随Entry类型的HAP一起下载安装

Module

  1. 一个开发态的Module编译后生成一个部署态的HAP,Module和HAP一一对应
  2. Module是HarmonyOS应用/服务的基本功能单元,包含了源代码、资源文件、第三方库及应用/服务配置文件,每一个Module都可以独立进行编译和运行。一个DevEco Studio工程可以包含多个Module
  3. Module分为“Ability”和“Library”两种类型
  • “Ability”类型的Module对应于编译后的HAP(Harmony Ability Package);
  • “Library”类型的Module对应于 HAR 静态共享包(Harmony Archive),或者 HSP 动态共享包(Harmony Shared Package)
鸿蒙应用开发-初见:入门知识、应用模型,第4张

4. 一个Module可以包含一个或多个 UIAbility 组件

  • Ability组件是一种包含用户界面的应用组件,用于与用户交互
  • Ability组件是系统调度的基本单元,为应用提供绘制界面的窗口
  • 一个Ability组件中可以通过多个页面来实现一个模块功能

建议将不同模块功能拆解为不同的Ability组件单独实现,即将一个独立的功能模块放到一个Ability组件中,以多页面的形式呈现。每一个Ability组件实例,都对应于一个任务,可以在最近任务列表中呈现

鸿蒙应用开发-初见:入门知识、应用模型,第5张

鸿蒙支持快速修复包

快速修复包结构

鸿蒙应用开发-初见:入门知识、应用模型,第6张

appqf(Application Quick Fix)

  1. appqf与应用的app pack包是一一对应关系
  2. appqf包是HarmonyOS应用用于发布到应用市场的单元,不能够直接安装到设备上
  3. 由一个或多个hqf组成,这些hqf包在应用市场会从appqf包中拆分出来,再被分发到具体的设备上

hqf(Harmony Ability Package Quick Fix)

  1. hqf包是修复HAP中问题的快速修复包,用于安装到设备上的快速修复单元
  2. 一个hqf可以包含.abc的快速修复文件,.so的快速修复文件和描述该包的配置文件
  • .abc文件:应用中修改后的ts代码,编译后生成的字节码文件
  • libs目录:存放.so库文件的差分文件,以.so.diff为后缀。区分的不同的系统cpu架构,例如arm平台、x86平台
  • patch.json:用于描述hqf包版本信息的配置文件,由开发者填写

快速修复包的发布部署流程

鸿蒙应用开发-初见:入门知识、应用模型,第7张

Stage模型

鸿蒙应用开发-初见:入门知识、应用模型,第8张

应用组件

鸿蒙应用开发-初见:入门知识、应用模型,第9张

AbilityStage组件容器

  1. AbilityStage是一个 Module 级别的组件容器,应用的HAP在首次加载时会创建一个AbilityStage实例,可以对该Module进行初始化等操作
  2. AbilityStage与Module一一对应,即一个Module拥有一个AbilityStage
  3. AbilityStage 拥有 onCreate()] 生命周期回调和 onAcceptWant() 、onConfigurationUpdated()、onMemoryLevel() 事件回调
onCreate() 生命周期回调
  1. 在开始加载对应Module的第一个UIAbility实例之前会先创建AbilityStage,并在AbilityStage创建完成之后执行其onCreate()生命周期回调
  2. AbilityStage模块提供在Module加载的时候,通知开发者,可以在此进行该Module的初始化(如资源预加载,线程创建等)能力
onAcceptWant()事件回调

UIAbility 指定实例模式(specified)启动时候触发的事件回调

onConfigurationUpdated()事件回调

系统全局配置发生变更时触发的事件,系统语言、深浅色等,配置项目前均定义在 Configuration 类中

onMemoryLevel() 事件回调

当系统调整内存时触发的事件

应用上下文Context

  1. Context 是应用中对象的上下文,其提供了应用的一些基础信息
  2. UIAbility组件和各种ExtensionAbility派生类组件都有各自不同的Context类。分别有基类Context、ApplicationContext、AbilityStageContext、UIAbilityContext、ExtensionContext、ServiceExtensionContext等Context
鸿蒙应用开发-初见:入门知识、应用模型,第10张
鸿蒙应用开发-初见:入门知识、应用模型,第11张

UIAbility组件

  • 包含UI界面,提供展示UI的能力,主要用于和用户交互。详细介绍请参见 UIAbility组件概述。
UIAbility组件生命周期
鸿蒙应用开发-初见:入门知识、应用模型,第12张
鸿蒙应用开发-初见:入门知识、应用模型,第13张
UIAbility组件启动模式
  • singleton(单实例模式)
  1. 每次调用startAbility()方法时,如果应用进程中该类型的UIAbility实例已经存在,则复用系统中的UIAbility实例。
  2. 系统中只存在唯一一个该UIAbility实例,即在最近任务列表中只存在一个该类型的UIAbility实例
  3. 在 module.json5配置文件 中的"launchType"字段配置为"singleton"
  • standard(标准实例模式)
  1. 每次调用startAbility()方法时,都会在应用进程中创建一个新的该类型UIAbility实例
  2. 即在最近任务列表中可以看到有多个该类型的UIAbility实例
  3. 在 module.json5配置文件 中的"launchType"字段配置为"standard"
  • specified(指定实例模式)
  1. 在UIAbility实例创建之前,允许开发者为该实例创建一个唯一的字符串Key
  2. 创建的UIAbility实例绑定Key之后,后续每次调用startAbility()方法时,都会询问应用使用哪个Key对应的UIAbility实例来响应startAbility()请求。通过AbilityStage的onAcceptWant实现
  3. 运行时由UIAbility内部业务决定是否创建多实例,如果匹配有该UIAbility实例的Key,则直接拉起与之绑定的UIAbility实例,否则创建一个新的UIAbility实例
  4. module.json5配置文件 的"launchType"字段配置为"specified"
UIAbility组件与UI的数据同步

基于HarmonyOS的应用模型,可以通过以下两种方式来实现UIAbility组件与UI之间的数据同步

  1. EventHub:基于发布订阅模式来实现,事件需要先订阅后发布,订阅者收到消息后进行处理。
  • 在使用EventHub之前,首先需要获取EventHub对象。基类Context 提供了EventHub对象
  1. globalThis:ArkTS引擎实例内部的一个全局对象,在ArkTS引擎实例内部都能访问
UIAbility组件间交互(设备内)
  1. UIAbility是系统调度的最小单元。在设备内的功能模块之间跳转时,会涉及到启动特定的UIAbility,该UIAbility可以是应用内的其他UIAbility,也可以是其他应用的UIAbility
  2. 通过调用startAbility并传递给它 want 参数启动其他UIAbility,如果期望其他Ability返回结果则可以使用startAbilityForResult
  • want中如果传入了abilityName则进行显示跳转,否则进行隐式跳转

ExtensionAbility组件

提供特定场景(如卡片、输入法)的扩展能力,满足更多的使用场景。详细介绍请参见 ExtensionAbility组件。

FormExtensionAbility :FORM类型的ExtensionAbility组件,用于提供服务卡片场景相关能力

ArkTS运行机制
鸿蒙应用开发-初见:入门知识、应用模型,第14张
鸿蒙应用开发-初见:入门知识、应用模型,第15张

进程模型

鸿蒙应用开发-初见:入门知识、应用模型,第16张

Stage模型有三类进程,是从系统总体资源占用考虑,希望由系统负责应用进程的创建和销毁。所以不支持应用自定义配置多进程,也不支持通过接口启动进程

主进程

开发者编写的UIAbility入口及其依赖的代码都在该进程中运行。它是由UIAbility组件的启动触发创建的。

ExtensionAbility进程

开发者编写的同一种类型的ExtensionAbility组件实例都会在同一个进程中运行。不同类型的ExtensionAbility组件实例则在不同的进程中运行。该类进程是由系统服务在特定场景下创建,并根据用户对特定场景的使用,决定其何时销毁。同时该类进程独立于主进程创建,并且不支持与主进程之间进行IPC通信

渲染进程

为了支持WebView的运行,每个应用只能创建一个Render进程用于运行WebView的渲染引擎。这个Render进程也是由系统负责创建和销毁

基于HarmonyOS的进程模型,系统提供了 公共事件机制 用于一对多的通信场景,公共事件发布者可能存在多个订阅者同时接收事件

线程模型

  1. ArkTS引擎实例的创建 一个进程可以运行多个应用组件实例,所有应用组件实例共享一个ArkTS引擎实例。
  2. 线程模型 ArkTS引擎实例在主线程上创建。
  3. 进程内支持对象共享

HarmonyOS应用中每个进程都会有一个主线程,主线程有如下职责:

  1. 执行UI绘制;
  2. 管理主线程的ArkTS引擎实例,使多个UIAbility组件能够运行在其之上;
  3. 管理其他线程(例如Worker线程)的ArkTS引擎实例,例如启动和终止其他线程;
  4. 分发交互事件;
  5. 处理应用代码的回调,包括事件处理和生命周期管理;
  6. 接收Worker线程发送的消息;

HarmonyOS可以使用Worker线程执行耗时操作,这些线程无法直接操作UI。Worker线程在主线程中创建,与主线程相互独立。最多可以创建8个Worker

线程间通信目前主要有Emitter和Worker两种方式,其中Emitter主要适用于线程间的事件同步, Worker主要用于新开一个线程执行耗时任务

Stage模型只提供了主线程和Worker线程,Emitter主要用于主线程内或者主线程和Worker线程的事件同步

应用配置文件

使用app.json5描述应用信息,module.json5描述HAP信息、应用组件信息


https://www.xamrdz.com/backend/3k51936606.html

相关文章: