ExtensionAbility组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。

每一个具体场景对应一个 ExtensionAbilityType，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如InputMethodExtensionAbility组件由输入法管理服务统一管理。

当前系统已定义的ExtensionAbility类型如下表所示。

说明：

• “是否允许三方应用实现”是指：对于一类ExtensionAbility，三方应用能否继承该ExtensionAbility父类实现自己的业务逻辑。

• “是否允许三方应用访问”是指：有些ExtensionAbility会对外提供一些服务，这些ExtensionAbility可能允许三方访问，也可能不允许。“Y”表示允许，“N”表示不允许，“NA”表示不涉及对外服务。

对于系统应用，不受下表约束，允许实现系统已定义的各类ExtensionAbility，也允许访问提供的各类对外服务。

DD一下：在探索鸿蒙系统的学习过程中，不少人都曾遇到过各种棘手问题。小编结合自身学习与实践经历，将容易踩坑的环节和对应的解决思路整理成攻略，希望这些经验分享能为同样在学习鸿蒙的伙伴们提供一些参考和帮助：鸿 蒙 全 栈 开 发 全 新 学 习 指 南

鸿蒙全栈开发学习路线
2.OpenHarmony开发基础
3.OpenHarmony北向开发环境搭建
4.鸿蒙南向开发环境的搭建
5.鸿蒙生态应用开发白皮书V2.0 & V3.0
6.鸿蒙开发面试真题（含参考答案） 
7.TypeScript入门学习手册
8.OpenHarmony 经典面试题(含参考答案)
9.OpenHarmony设备开发入门【最新版】
10.沉浸式剖析OpenHarmony源代码
11.系统定制指南
12.【OpenHarmony】Uboot 驱动加载流程
13.OpenHarmony构建系统--GN与子系统、部件、模块详解
14.ohos开机init启动流程
15.鸿蒙版性能优化指南
.......

鸿蒙全栈开发技术栈：

访问指定类型的ExtensionAbility组件

所有类型的ExtensionAbility组件均不能被应用直接启动，而是由相应的系统管理服务拉起，以确保其生命周期受系统管控，使用时拉起，使用完销毁。ExtensionAbility组件的调用方无需关心目标ExtensionAbility组件的生命周期。

以 InputMethodExtensionAbility 组件为例进行说明，如下图所示，调用方应用发起对InputMethodExtensionAbility组件的调用，此时将先调用输入法管理服务，由输入法管理服务拉起 InputMethodExtensionAbility 组件，返回给调用方，同时开始管理其生命周期。

图1 使用InputMethodExtensionAbility组件

实现指定类型的ExtensionAbility组件

以实现卡片 FormExtensionAbility 为例进行说明。卡片框架提供了 FormExtensionAbility 基类，开发者通过派生此基类（如MyFormExtensionAbility），实现回调（如创建卡片的onCreate()回调、更新卡片的onUpdateForm()回调等）来实现具体卡片功能，具体见开发指导见 服务卡片 。

卡片FormExtensionAbility实现方不用关心使用方何时去请求添加、删除卡片，FormExtensionAbility实例及其所在的ExtensionAbility进程的整个生命周期，都是由卡片管理系统服务FormManagerService进行调度管理。

说明： 同一应用内的所有同类型的ExtensionAbility运行在同一独立进程（除ServiceExtensionAbility、DataShareExtensionAbility外），跟UIAbility组件不在同一进程，Stage模型的进程模型请参见 进程模型 。