Ability可以分为FA（Feature Ability）和PA（Particle Ability）两种类型。

PA支持Service Ability和Data Ability。

以上，需要再config.json 中进行type配置。

android 为activity、fragment，Activity需要在AndroidManifest.xml中进行注册。

harmonyOS 需要在config.json配置。

Ability休要在onStart(Intent intent) 初始化视图 setUIContent。activity在onCreate(@Nullable Bundle savedInstanceState)初始化 setContentView。

原因：

HarmonyOS Page调用onStart()后进入INACTIVE。Android中当 Activity 进入“已开始”状态时，系统会调用onStart() 。onStart() 调用使 Activity 对用户可见，此时只是可见，但不能与用户进行交互，应用通过此方法来初始化维护界面的代码。

HarmonyOS Page会在进入INACTIVE状态后来到前台，然后系统调用onActive()。Page在此之后进入ACTIVE状态，该状态是应用与用户交互的状态。Android Activity 会在进入“已恢复”状态时来到前台，然后系统调用 onResume() 回调。这时，生命周期组件可以启用在组件可见且位于前台时需要运行的任何功能。

对于HarmonyOS Ability Abilityslice中，继承如下：

Ability extends AbilityContext implements ILifecycle && class AbilitySlice extends AbilityContext implements ILifecycle。

对于android 中Activity，继承关系如下：

AppCompatActivity  五层级到ContextWrapper，再到Context，复杂功能链路。

Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner, ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner。

iOS os 中UIviewcontroller ：UIResponder 以及各种协议汇总，最终死nsobject类的UIresponderStandardEditactions。

从原理是，ios < harmonyos < android，层层关系递进，这需要编译软件耗时，运行时候更高效的是层级关系简单的链路。

在宣传会议后，有这么一张从使用场景、价值、战略上（来自知乎）：

 有人这么调侃：如果Apple把自家的watchOS、iPadOS、macOS、tvOS都改名叫AppleOS，就几乎占全了鸿蒙的特长。

我做过一些投屏软件，iosOS开发接触macOS后，痛苦不堪，很多兼容性api差异化很大，所以这个根本无法对等。

OpenHarmony不是HarmonyOS

华为把HarmonyOS中基础功能提取出来，打包成功一个项目叫做“Openharmony” ，把Openharmony捐献给了原子开源基金会。

HarmonyOS 2 并没有捐出，这个商业版本也是基于开源项目 OpenHarmony 2.0 开发的，兼容了 AOSP，增加了 HMS 。

个人认为，这需要国家层面出手或者更高维度的需求落地进行潜移默化的处理。不能一概去除android、ios好坏之分。借助android、ios竞争性进行harmony突破。

AbilitySlice

切片，是单个可视化界面及其交互逻辑的总和，是Feature Ability的组成单元。一个Feature Ability可以包含一组业务关系密切的可视化界面，每一个可视化界面对应一个AbilitySlice。

eg：

AbilitySlice targetSlice = new MyAbilitySlice();

Intent intent = new Intent(); intent.setParam("value", 10); present(targetSlice, intent);