欲开发鸿蒙应用，须先搞懂 Ability。
Ability是什么
官方定义Ability 是应用所具备能力的抽象，也是应用程序的重要组成部分。
它是可见的，承载一个业务可视化界面；亦可为隐藏的，在背后默默为你干脏活；又能在多应用间架起数据访问的桥梁，方便数据沟通。
鸿蒙应用是以 Ability 为单位进行部署，开发者通过继承 Ability 类来实现应用所需能力。
如果从安卓 API 能力角度上看，鸿蒙OS的 Ability 提供的能力囊括了 Activity、Service、ContentProvider。
Ability 根据是否可交互划分为 Feature和Particle两种类型。
不同类型会根据其支持模板可再细分：
- Feature 目前仅支持Page模板，用于提供与用户交互的能力，包括写视图组件等。
- Particle 支持Service模板和Data模板，前者用于提供后台运行任务的能力，后者对外提供数据访问的能力。
怎么使用 Ability
只能直接继承来实现不同模板能力，而不同模板实现的子类需要主动选择覆盖对应方法。
比如可视化的 Page 模板关注的是页面生命周期变化，所以重载的方法主要是生命周期变化的回调方法。
而 Service 模板更关注的是服务的连接与断开，重载的方法则与 Page 模板不一样。
说实话这样的设计并不好，针对模板分类封装 Ability 显然更友好。
我们以可视化 Page 模板作为例子展开。
编写一个闪屏页面
public class SplashScreenAbility extends Ability {
@Override
public void onStart(Intent intent) {
super.onStart(intent);
//视图片，后面会有讲到
super.setMainRoute(SplashScreenAbilitySlice.class.getName());
}
}可以看到我们重载的 onStart 方法。
onStart只是系统首次创建 Page 时的回调，对于页面的生命周期的状态转化及对应回调可见下图。
下面针对核心方法做简单阐述：
- onStart，当系统首次创建 Page 实例时触发该回调。对于一个 Page 实例，该回调在其生命周期过程中仅触发一次， 此后进入 INACTIVE 状态。开发者必须重写该方法，并在此配置默认展示的 AbilitySlice。
- onActive，Page 会在进入 INACTIVE 状态后来到前台，然后系统调用此回调。在此之后进入 ACTIVE 状态，该状态是应用与用户交互的状态。
- onInactive，Page 失去焦点时系统将调用此回调，此后 Page 进入 INACTIVE 状态。
- onBackground，如果 Page 不再对用户可见，系统将调用此回调通知开发者用户进行相应的资源释放，此后 Page 进入 BACKGROUND 状态。
- onForeground，处于 BACKGROUND 状态的 Page 仍然驻留在内存中，当重新回到前台时（比如用户重新导航到此 Page ），系统将先调用 onForeground() 回调通知开发者，而后 Page 的生命周期状态回到 INACTIVE 状态。开发者应当在此回调中重新申请在 onBackground() 中释放的资源，最后 Page 的生命周期状态进一步回到 ACTIVE 状态，系统将通过 onActive() 回调通知开发者用户。
- onStop，系统将要销毁 Page 时，将会触发此回调函数，通知用户进行系统资源的释放。
对比安卓 Activity 生命周期回调（左鸿蒙右安卓）
onStart() --> onCreate()
onActive() --> onResume()
onInactive() --> onPause()
onBackground() --> onStop()
onForeground() --> onRestart()
onStop() --> onDestroy()生命周期变化规律的回调看起来确实很像 Activity场景，但在视图编写流程上却有些差异。
例子代码中出现的 SplashScreenAbilitySlice 实际上才是真正承载视图逻辑的类。
其继承的是 AbilitySlice 类，通过 supe#setMainRoute 的方法来导航到真正视图界面。
那么 AbilitySlice 是什么呢？
官方定义为AbilitySlice 作为 Page 的组成单元，其生命周期是依托于其所属 Page 生命周期。
AbilitySlice 和 Page 具有相同的生命周期状态和同名的回调，当 Page 生命周期发生变化时，它的 AbilitySlice 也会发生相同的生命周期变化。
|---AbilityContext
| |---Ability
| |---AbilitySlice //Page组成元素都继承自 AbilityContext，实现的方法大致相同。
只是 AbilitySlice 比 Page 多了一些生命周期变化，这些变化发生在同一 Page 中的多个 AbilitySlice 之间导航时，但此时 Page 的生命周期状态并不会改变。
AbilitySlice 跟 Fragment 有点像，只是 Page 必须通过设置 AbilitySlice 展示页面视图。
以下是 SplashScreenAbilitySlice 简单实现。
public class SplashScreenAbilitySlice extends AbilitySlice {
@Override
public void onStart(Intent intent) {
super.onStart(intent);
super.setUIContent(ResourceTable.Layout_splash_screen_layout);
}
}上述代码通过调用 setUIContent 设置布局。
Demo 实现一个完整的闪屏逻辑，效果如下，感兴趣可到 Github 查看实现。
对于 Service 模板及 Data 模板，则直接覆盖对应方法即可，这部分暂不过多描述，细节可到 HarmonyOS Developer 开发文档 中查阅。
既然 Ability 划分多种模板，那么应用如何区分这些模板呢？
区分 Ability 模板
在之前《Harmony系列之 工程结构与应用配置的理解》一文中我们有讲过在每个模块都会有一个 config.json 配置文件。
而这个文件的 module 节点中需要申明应用所需要用到的 Ability。
"abilities": [
{
"orientation": "portrait",
"name": "com.effective.harmony.study.ability.page.SplashScreenAbility",
"type": "page",
},
{
"name": "com.effective.harmony.study.ability.service.ServiceAbility",
"type": "service",
}
]如上图，申明了 SplashScreenAbility 为 Page模板，ServiceAbility 为 Service模板。
这一点和安卓应用中 AndroidManifest.xml 需要申明四大组件逻辑是一致的。
虽然目前官方 SDK 源码并没有开源，但在 Framework 层应该是对应类型进行分类，并在各自模板场景下做方法映射调用。
初探Ability至此，但我更好奇的是 Framework 层的实现。
遗憾的是，目前 SDK 目前还没有开源，API 也没有注释呐。