基础知识
Stage模型应用程序包结构
开发并打包完成后的App的程序包结构如图
- 开发者通过DevEco Studio把应用程序编译为一个或者多个.hap后缀的文件,即HAP
- 一个应用中的.hap文件合在一起称为一个Bundle,bundleName是应用的唯一标识
需要特别说明的是:在应用上架到应用市场时,需要把应用包含的所有.hap文件(即Bundle)打包为一个.app后缀的文件用于上架,这个.app文件称为App Pack(Application Package),其中同时包含了描述App Pack属性的pack.info文件;在云端(服务器)分发和终端设备安装时,都是以HAP为单位进行分发和安装的。
- 所有的HAP最终会编译到一个App Pack中(以.app为后缀的包文件),用于发布到应用市场
HAP
- HAP是HarmonyOS应用安装的基本单位,包含了编译后的代码、资源、三方库及配置文件
- 打包后的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中必不可少的文件。
Entry类型的HAP
- 应用的主模块,在 module.json5配置文件中的type标签配置为“entry”类型。
- 在同一个应用中,同一设备类型只支持一个Entry类型的HAP,通常用于实现应用的入口界面、入口图标、主特性功能等。
Feature类型的HAP
- 应用的动态特性模块,在 module.json5配置文件 中的type标签配置为“feature”类型。
- 一个应用程序包可以包含一个或多个Feature类型的HAP,也可以不包含;
- Feature类型的HAP通常用于实现应用的特性功能,可以配置成按需下载安装,也可以配置成随Entry类型的HAP一起下载安装
Module
- 一个开发态的Module编译后生成一个部署态的HAP,Module和HAP一一对应
- Module是HarmonyOS应用/服务的基本功能单元,包含了源代码、资源文件、第三方库及应用/服务配置文件,每一个Module都可以独立进行编译和运行。一个DevEco Studio工程可以包含多个Module
- Module分为“Ability”和“Library”两种类型
- “Ability”类型的Module对应于编译后的HAP(Harmony Ability Package);
- “Library”类型的Module对应于 HAR 静态共享包(Harmony Archive),或者 HSP 动态共享包(Harmony Shared Package)
4. 一个Module可以包含一个或多个 UIAbility 组件
- Ability组件是一种包含用户界面的应用组件,用于与用户交互
- Ability组件是系统调度的基本单元,为应用提供绘制界面的窗口
- 一个Ability组件中可以通过多个页面来实现一个模块功能
建议将不同模块功能拆解为不同的Ability组件单独实现,即将一个独立的功能模块放到一个Ability组件中,以多页面的形式呈现。每一个Ability组件实例,都对应于一个任务,可以在最近任务列表中呈现
鸿蒙支持快速修复包
快速修复包结构
appqf(Application Quick Fix)
- appqf与应用的app pack包是一一对应关系
- appqf包是HarmonyOS应用用于发布到应用市场的单元,不能够直接安装到设备上
- 由一个或多个hqf组成,这些hqf包在应用市场会从appqf包中拆分出来,再被分发到具体的设备上
hqf(Harmony Ability Package Quick Fix)
- hqf包是修复HAP中问题的快速修复包,用于安装到设备上的快速修复单元
- 一个hqf可以包含.abc的快速修复文件,.so的快速修复文件和描述该包的配置文件
- .abc文件:应用中修改后的ts代码,编译后生成的字节码文件
- libs目录:存放.so库文件的差分文件,以.so.diff为后缀。区分的不同的系统cpu架构,例如arm平台、x86平台
- patch.json:用于描述hqf包版本信息的配置文件,由开发者填写
快速修复包的发布部署流程
Stage模型
应用组件
AbilityStage组件容器
- AbilityStage是一个 Module 级别的组件容器,应用的HAP在首次加载时会创建一个AbilityStage实例,可以对该Module进行初始化等操作
- AbilityStage与Module一一对应,即一个Module拥有一个AbilityStage
- AbilityStage 拥有 onCreate()] 生命周期回调和 onAcceptWant() 、onConfigurationUpdated()、onMemoryLevel() 事件回调
onCreate() 生命周期回调
- 在开始加载对应Module的第一个UIAbility实例之前会先创建AbilityStage,并在AbilityStage创建完成之后执行其onCreate()生命周期回调
- AbilityStage模块提供在Module加载的时候,通知开发者,可以在此进行该Module的初始化(如资源预加载,线程创建等)能力
onAcceptWant()事件回调
UIAbility 指定实例模式(specified)启动时候触发的事件回调
onConfigurationUpdated()事件回调
当系统全局配置发生变更时触发的事件,系统语言、深浅色等,配置项目前均定义在 Configuration 类中
onMemoryLevel() 事件回调
当系统调整内存时触发的事件
应用上下文Context
- Context 是应用中对象的上下文,其提供了应用的一些基础信息
- UIAbility组件和各种ExtensionAbility派生类组件都有各自不同的Context类。分别有基类Context、ApplicationContext、AbilityStageContext、UIAbilityContext、ExtensionContext、ServiceExtensionContext等Context
UIAbility组件
- 包含UI界面,提供展示UI的能力,主要用于和用户交互。详细介绍请参见 UIAbility组件概述。
UIAbility组件生命周期
UIAbility组件启动模式
- singleton(单实例模式)
- 每次调用startAbility()方法时,如果应用进程中该类型的UIAbility实例已经存在,则复用系统中的UIAbility实例。
- 系统中只存在唯一一个该UIAbility实例,即在最近任务列表中只存在一个该类型的UIAbility实例
- 在 module.json5配置文件 中的"launchType"字段配置为"singleton"
- standard(标准实例模式)
- 每次调用startAbility()方法时,都会在应用进程中创建一个新的该类型UIAbility实例
- 即在最近任务列表中可以看到有多个该类型的UIAbility实例
- 在 module.json5配置文件 中的"launchType"字段配置为"standard"
- specified(指定实例模式)
- 在UIAbility实例创建之前,允许开发者为该实例创建一个唯一的字符串Key
- 创建的UIAbility实例绑定Key之后,后续每次调用startAbility()方法时,都会询问应用使用哪个Key对应的UIAbility实例来响应startAbility()请求。通过AbilityStage的onAcceptWant实现
- 运行时由UIAbility内部业务决定是否创建多实例,如果匹配有该UIAbility实例的Key,则直接拉起与之绑定的UIAbility实例,否则创建一个新的UIAbility实例
- module.json5配置文件 的"launchType"字段配置为"specified"
UIAbility组件与UI的数据同步
基于HarmonyOS的应用模型,可以通过以下两种方式来实现UIAbility组件与UI之间的数据同步
- EventHub:基于发布订阅模式来实现,事件需要先订阅后发布,订阅者收到消息后进行处理。
- 在使用EventHub之前,首先需要获取EventHub对象。基类Context 提供了EventHub对象
- globalThis:ArkTS引擎实例内部的一个全局对象,在ArkTS引擎实例内部都能访问
UIAbility组件间交互(设备内)
- UIAbility是系统调度的最小单元。在设备内的功能模块之间跳转时,会涉及到启动特定的UIAbility,该UIAbility可以是应用内的其他UIAbility,也可以是其他应用的UIAbility
- 通过调用
startAbility
并传递给它 want 参数启动其他UIAbility,如果期望其他Ability返回结果则可以使用startAbilityForResult
- want中如果传入了abilityName则进行显示跳转,否则进行隐式跳转
ExtensionAbility组件
提供特定场景(如卡片、输入法)的扩展能力,满足更多的使用场景。详细介绍请参见 ExtensionAbility组件。
FormExtensionAbility :FORM类型的ExtensionAbility组件,用于提供服务卡片场景相关能力
ArkTS运行机制
进程模型
Stage模型有三类进程,是从系统总体资源占用考虑,希望由系统负责应用进程的创建和销毁。所以不支持应用自定义配置多进程,也不支持通过接口启动进程
主进程
开发者编写的UIAbility入口及其依赖的代码都在该进程中运行。它是由UIAbility组件的启动触发创建的。
ExtensionAbility进程
开发者编写的同一种类型的ExtensionAbility组件实例都会在同一个进程中运行。不同类型的ExtensionAbility组件实例则在不同的进程中运行。该类进程是由系统服务在特定场景下创建,并根据用户对特定场景的使用,决定其何时销毁。同时该类进程独立于主进程创建,并且不支持与主进程之间进行IPC通信
渲染进程
为了支持WebView的运行,每个应用只能创建一个Render进程用于运行WebView的渲染引擎。这个Render进程也是由系统负责创建和销毁
基于HarmonyOS的进程模型,系统提供了 公共事件机制 用于一对多的通信场景,公共事件发布者可能存在多个订阅者同时接收事件
线程模型
- ArkTS引擎实例的创建 一个进程可以运行多个应用组件实例,所有应用组件实例共享一个ArkTS引擎实例。
- 线程模型 ArkTS引擎实例在主线程上创建。
- 进程内支持对象共享
HarmonyOS应用中每个进程都会有一个主线程,主线程有如下职责:
- 执行UI绘制;
- 管理主线程的ArkTS引擎实例,使多个UIAbility组件能够运行在其之上;
- 管理其他线程(例如Worker线程)的ArkTS引擎实例,例如启动和终止其他线程;
- 分发交互事件;
- 处理应用代码的回调,包括事件处理和生命周期管理;
- 接收Worker线程发送的消息;
HarmonyOS可以使用Worker线程执行耗时操作,这些线程无法直接操作UI。Worker线程在主线程中创建,与主线程相互独立。最多可以创建8个Worker
线程间通信目前主要有Emitter和Worker两种方式,其中Emitter主要适用于线程间的事件同步, Worker主要用于新开一个线程执行耗时任务
Stage模型只提供了主线程和Worker线程,Emitter主要用于主线程内或者主线程和Worker线程的事件同步
应用配置文件
使用app.json5描述应用信息,module.json5描述HAP信息、应用组件信息
为了能让大家更好的学习鸿蒙 (Harmony OS) 开发技术,这边特意整理了《鸿蒙 (Harmony OS)开发学习手册》(共计890页),希望对大家有所帮助:https://qr21.cn/FV7h05
《鸿蒙 (Harmony OS)开发学习手册》
入门必看:https://qr21.cn/FV7h05
- 应用开发导读(ArkTS)
- 应用开发导读(Java)
HarmonyOS 概念:https://qr21.cn/FV7h05
- 系统定义
- 技术架构
- 技术特性
- 系统安全
如何快速入门:https://qr21.cn/FV7h05
- 基本概念
- 构建第一个ArkTS应用
- 构建第一个JS应用
- ……
开发基础知识:https://qr21.cn/FV7h05
- 应用基础知识
- 配置文件
- 应用数据管理
- 应用安全管理
- 应用隐私保护
- 三方应用调用管控机制
- 资源分类与访问
- 学习ArkTS语言
- ……
基于ArkTS 开发:https://qr21.cn/FV7h05
- Ability开发
- UI开发
- 公共事件与通知
- 窗口管理
- 媒体
- 安全
- 网络与链接
- 电话服务
- 数据管理
- 后台任务(Background Task)管理
- 设备管理
- 设备使用信息统计
- DFX
- 国际化开发
- 折叠屏系列
- ……