1、config.json配置
鸿蒙中的config.json应该类似于Android开发中Manifest.xml,可以进行页面的配置。根据顺序,会识别启动应用的时候,要打开哪个界面。
2、 Ability详解,以及与Android的Activity对比。
他人的学习文章连接,请点击
一个 HarmonyOS 应用可以包含多个 Ability,Ability 可以分为:
-
Feature Ability(简称 FA),有界面,也被称为元程序
-
Particle Ability(简称 PA),无界面,也被称为元服务
FA 类似于 Android 的 Activity ;PA 类似于 Android 的 Services。
FA 支持 Page Ability,代表了 UI 的能力:Page 模板是 FA 唯一支持的模板,用于提供与用户交互的能力。一个Page实例可以包含一组相关页面,每个页面用一个 AbilitySlice 实例表示。
PA 支持 Service Ability 和 Data Ability:
-
Service 模板:用于提供后台运行任务的能力,提供应用服务,例如播放音乐等。
-
Data 模板:用于对外部提供统一的数据访问抽象,提供了统一的数据访问接口,方便 FA 的统一调用,例如对本地文件的读取。
(那么FA与PA如何交互呢?我也不太清楚,继续学习。 -- 在下加的。)
使用 Ability 时必须在配置文件 config.json 中注册该 Ability ,设置相应的属性,该文件存储在每个应用程序的 Java 代码的根目录中。
在 Java 中,Ability 是一个类。事实上,鸿蒙应用程序的开发就是对 Ability 进行继承并进行应用扩展。所有的应用程序的功能最终必须要体现在开发者所创建的 Ability 的子类中。
①Page Ability
Page Ability 是 Feature Ability 唯一支持的模板。用于提供与用户的交互能力,其实就是页面的父级。
一个 Page 可以由一个或多个 AbilitySlice 构成,AbilitySlice 是指应用的单个页面及其控制逻辑的总和。
官方认为当一个 Page 由多个 AbilitySlice 共同构成时,这些 AbilitySlice 页面提供的业务能力应具有高度相关性。
在配置文件(config.json)中注册 Ability 时,可以通过配置 Ability 元素中的 “type” 属性来指定 Ability 模板类型,示例如下:
(下边这张图,在下不是非常明白吧。感觉就像是类似于Android的activity栈?)
②Page Ability 的生命周期
Ability 生命周期介绍(Ability Life Cycle)是 Ability 被调度到 INACTIVE、ACTIVE、BACKGROUND 等各个状态的统称(主要涉及 PageAbility 类型和 ServiceAbility 类型的 Ability)。
PageAbility 类型的 Ability 生命周期流转如下图所示:
主要生命周期如下:
-
首先初始化 Ability,初始化完毕后状态是 INITIAL 状态
-
初始化完成后, 会调用 onStart() 方法,初始化 UI 界面中使用到的控件和变量, 执行完毕后状态变为 INACTIVE 状态
-
快要显示时,会调用 onActive() 方法,状态变为 ACTIVE 状态
-
如果由于某些原因,该 Page Ability 失去焦点,进入后台,如弹出对话框,另一个 Page Ability 前台显示,会回调 onInactive() 方法,状态变为 INACTIVE 状态
-
窗口彻底不显示,但是还处于后台状态,会回调 onBackground() 方法,状态变 BACKGROUND 状态
有几种特殊情况:
-
如果当前处于 INACTIVE 状态,用户返回 Page Ability,则回调 onActive() 方法,进入 ACTIVE 状态
-
如果当前的 Page Ability 处于 BACKGROUND 状态,当用户从后台返回前台时, 会回调 onForeground() 方法,状态变为 INACTIVE 状态
-
如果当前的 Page Ability 处于 BACKGROUND 状态,当该 Ability 彻底销毁,正在结束,因内存不足终止,用户重新进入该界面时,会回调 onStop() 方法,状态变为 INITIAL 状态
生命周期图如下:
③Service Ability
--- 应该是对应着Android的Service。---
Service Ability 是 Particle Ability 支持的模板之一。用于后台运行任务(如执行音乐播放、文件下载等),但不提供用户交互界面。
Service 可由其他应用或 Ability 启动,即使用户切换到其他应用,Service 仍将在后台继续运行。
Service 是单实例的。在一个设备上,相同的Service 只会存在一个实例。如果多个 Ability 共用这个实例,只有当与 Service 绑定的所有 Ability 都退出后,Service 才能够退出。
由于 Service 是在主线程里执行的,因此,如果在 Service 里面的操作时间过长,开发者必须在 Service 里创建新的线程来处理,防止造成主线程阻塞,应用程序无响应。
④sevice ability 生命周期
与 Page 类似,Service 也拥有生命周期,如图所示:
根据调用方法的不同,其生命周期有以下两种路径:
-
启动 Service:该 Service 在其他 Ability 调用startAbility()时创建,然后保持运行。其他 Ability 通过调用stopAbility()来停止 Service,Service 停止后,系统会将其销毁。
-
连接 Service:该 Service 在其他 Ability 调用 connectAbility() 时创建,客户端可通过调用 disconnectAbility() 断开连接。多个客户端可以绑定到相同 Service,而且当所有绑定全部取消后,系统即会销毁该 Service。
connectAbility() 也可以连接通过 startAbility() 创建的 Service 。在配置文件中,“module > abilities”字段下对当前 Service 做如下配置:
{"module": {..."abilities": [{..."name": ".ServiceAbility","type": "service","visible": true,...}]...}...
}
⑤Data Ability
Data Ability 是 Particle Ability 支持的模板之一。用于应用管理其自身和其他应用存储数据的访问,并提供与其他应用共享数据的方法。
Data 既可用于同设备不同应用的数据共享,也支持跨设备不同应用的数据共享。
数据的存放形式多样,可以是数据库,也可以是磁盘上的文件。Data 对外提供对数据的增、删、改、查,以及打开文件等接口,这些接口的具体实现由开发者提供。
⑥URI 介绍
Data 的提供方和使用方都通过 URI(Uniform Resource Identifier)来标识一个具体的数据,例如数据库中的某个表或磁盘上的某个文件。
URI 的组成图如下:
HarmonyOS 的 URI 仍基于 URI 通用标准,格式如下:
-
scheme:协议方案名,固定为“dataability”,代表 Data Ability 所使用的协议类型。
-
authority:设备 ID。如果为跨设备场景,则为目标设备的 ID;如果为本地设备场景,则不需要填写。
-
path:资源的路径信息,代表特定资源的位置信息。
-
query:查询参数。
-
fragment:可以用于指示要访问的子资源。
URI 示例:
跨设备场景:
dataability://device_id/com.domainname.dataability.persondata/person/10本地设备:
dataability:///com.domainname.dataability.persondata/person/10
在配置文件中,“module > abilities”字段下对当前 Data 做如下配置:
{"module": {..."abilities": [{..."type": "data"...}]...}...
}