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"
...
}
]
...
}
...
}
