ExtensionAbility 入门：服务、卡片、分享与后台能力边界

原创 于 2026-07-03 00:01:53 发布 · 193 阅读 · 1 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
收录于
ArkTS Stage

当前文章被收录于：

ArkTS Stage
8 篇文章 0 人学习
订阅专栏 查看详情

ExtensionAbility 入门：服务、卡片、分享与后台能力边界

前两篇我们已经把 Stage 工程目录、首页加载、资源管理和页面跳转讲清楚了。从这一篇开始，重点放到 Stage 模型本身：哪些代码应该放在 AbilityStage，哪些代码应该放在 UIAbility，哪些场景应该使用 ExtensionAbility，后台任务又应该如何设计。

本文的目标很明确：让读者看完后能把概念落到工程里，而不是只记住几个类名。

在这里插入图片描述

1. 本章先解决什么问题

ExtensionAbility 面向非页面扩展场景。理解它的边界，才能避免把后台服务、卡片和分享入口都塞进 UIAbility。

如果你正在写 HarmonyOS 应用，可以先带着三个问题读本文：

  1. 这段代码应该放在入口、页面、服务层还是扩展能力中？
  2. 出问题时应该先检查配置、生命周期、页面路由还是后台任务？
  3. 这个能力是否真的需要后台运行，还是可以交给前台页面或系统调度？

补充流程图：

理解：本章先解决什么问题

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 本章先解决什么问题ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，读者不会只看到一段抽象描述。
  2. 示例代码给出了一个可以迁移到 Stage 工程中的最小实现。
  3. 这段代码把不同扩展入口先统一成请求对象，再按 type 分发。这样可以避免把服务、卡片、分享逻辑全部写在一个生命周期回调里。

2. ExtensionAbility 解决什么问题

应用不只有前台页面，还可能需要服务化能力、卡片能力、分享入口等能力。这些场景通常不是普通页面，而是系统的扩展入口。

补充流程图：

理解：ExtensionAbility 解决什么问题

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class ExtensionAbilityRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现、验证串联起来，使读者不会只看到一段抽象描述。
  2. 示例代码给出了一个可以迁移到 Stage 工程中的最小实现。
  3. 这段代码把不同扩展入口先统一成请求对象，再按 type 分发。这样可以避免把服务、卡片、分享逻辑全部写在一个生命周期回调里。

3. ServiceExtensionAbility 的定位

服务扩展适合处理与服务相关的交互，但不能将其视为无限的后台线程。其后台能力受系统策略和场景约束。

补充流程图：

理解：ServiceExtensionAbility 的定位

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class ServiceExtensionAbExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，使读者不会只看到一段抽象描述。
  2. 示例代码提供了一个可迁移到 Stage 工程中的最小化实现。
  3. 这段代码将不同的扩展入口统一为请求对象，再按 type 进行分发。这样可以避免把服务、卡片、分享逻辑全部写在一个生命周期回调里。

4. FormExtensionAbility 的定位

卡片能力面向桌面或系统卡片展示，重点是轻量展示和刷新，不适合承载复杂页面逻辑。

补充流程图：

理解：FormExtensionAbility 的定位

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class FormExtensionAbilityRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码说明：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，避免读者只看到一段抽象描述。
  2. 示例代码提供了一个可迁移到 Stage 模型工程中的最小化写法。
  3. 这段代码将不同的扩展入口统一为请求对象，再根据 type 进行分发。这样可以避免将服务、卡片、分享的逻辑全部写在一个生命周期回调中。

5. ShareExtensionAbility 的定位

分享扩展适用于接收外部分享内容，并将内容转交给应用内部处理流程。

补充流程图：

理解：ShareExtensionAbility 的定位

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class ShareExtensionAbilExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现、验证串联起来，使读者不会只看到一段抽象描述。
  2. 示例代码给出了一个可以迁移到 Stage 工程中的最小实现。
  3. 这段代码将不同扩展入口先统一为请求对象，再按 type 分发。这样可以避免将服务、卡片、分享逻辑全部写在一个生命周期回调里。

6. 先判断场景，再选择能力

如果用户正在浏览页面，使用 UIAbility；如果是系统扩展入口，则考虑使用对应的 ExtensionAbility。

补充流程图：

理解：先判断场景，再选择能力

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 先判断场景_再选择能力ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，使读者不会只看到一段抽象描述。
  2. 示例代码提供了一个可以迁移到 Stage 模型工程中的最小化写法。
  3. 这段代码将不同的扩展入口统一为请求对象，再根据 type 进行分发。这样可以避免将服务、卡片、分享等逻辑全部写在一个生命周期回调中。

7. 工程结构建议

建议把 Stage 相关代码按职责分层，不要把所有逻辑写在一个文件里。

entry/src/main/ets
├── entryability
├── entryabilitystage
├── extensionability
├── pages
├── components
├── services
├── models
└── utils

目录解释：

  1. entryability 放 UIAbility 入口。
  2. entryabilitystage 放模块级初始化。
  3. extensionability 放服务、卡片、分享等扩展能力。
  4. pages 放 ArkUI 页面。
  5. services 放可复用业务服务。

8. 从 Demo 到项目时怎么拆

官方示例通常为了让读者快速跑通，会把代码写得比较集中。真实项目不能一直停留在 Demo 写法，否则页面一多就会出现三个问题：入口文件越来越大、页面事件处理越来越重、后台和前台逻辑互相影响。

更推荐的拆法是：

  1. AbilityStage 只处理模块级初始化，例如日志、配置、轻量服务注册。
  2. UIAbility 只处理界面入口，例如生命周期、窗口创建、首页加载、Want 参数接收。
  3. ExtensionAbility 只处理系统扩展入口，例如服务、卡片、分享等非普通页面场景。
  4. pages 只写页面状态和交互，不直接堆复杂业务。
  5. services 承担可复用业务，例如任务调度、缓存、配置读取、数据请求。

一个实用的判断标准是：如果这段代码离开当前页面后仍然有价值，就不要写死在页面里；如果这段代码只和启动入口有关，就不要放进组件里；如果这段代码需要系统以扩展方式调用，就不要强行放进 UIAbility。

补充流程图：

理解：从 Demo 到项目时怎么拆

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 从_Demo_到项目时怎么拆ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，避免读者只看到一段抽象描述。
  2. 示例代码给出了一个可以迁移到 Stage 工程中的最小实现。
  3. 这段代码把不同扩展入口先统一成请求对象，再按 type 分发。这样可以避免把服务、卡片、分享逻辑全部写在一个生命周期回调里。

9. 实战代码

ServiceExtensionAbility 示例

import { ServiceExtensionAbility, Want } from '@kit.AbilityKit';
import { hilog } from '@kit.PerformanceAnalysisKit';

export default class DemoServiceExtension extends ServiceExtensionAbility {
  onCreate(want: Want): void {
    hilog.info(0x0000, 'DemoService', 'service extension create');
  }

  onRequest(want: Want, startId: number): void {
    const taskId = want.parameters?.taskId as string ?? '';
    hilog.info(0x0000, 'DemoService', 'taskId=%{public}s startId=%{public}d', taskId, startId);
  }

  onDestroy(): void {
    hilog.info(0x0000, 'DemoService', 'service extension destroy');
  }
}

代码解释：

  1. 这段代码对应本节的最小可运行示例。
  2. 重点不是复制粘贴，而是理解它放在 Stage 工程中的位置。
  3. 扩展能力需要关注生命周期和请求参数，不要假设它会一直运行。

module.json5 声明扩展能力

{
  "extensionAbilities": [
    {
      "name": "DemoServiceExtension",
      "srcEntry": "./ets/extensionability/DemoServiceExtension.ets",
      "type": "service",
      "exported": false
    }
  ]
}

代码解释：

  1. 这段代码对应本节的最小可运行示例。
  2. 重点不是复制粘贴，而是理解它放在 Stage 工程中的位置。
  3. 扩展能力需要在模块配置中声明，type 要和实际场景对应。

10. 实战案例：做一个学习任务入口

下面用一个小案例把本章主题落到工程实践中。假设应用首页有一个“开始学习”按钮，点击后进入某个学习任务。页面只负责触发动作，任务参数和状态由服务层维护。

export interface StudyTask {
  id: string;
  title: string;
  source: string;
  createdAt: number;
}

export class StudyTaskService {
  private static currentTask?: StudyTask;

  static create(title: string, source: string): StudyTask {
    const task: StudyTask = {
      id: `${Date.now()}`,
      title,
      source,
      createdAt: Date.now()
    };
    StudyTaskService.currentTask = task;
    return task;
  }

  static getCurrent(): StudyTask | undefined {
    return StudyTaskService.currentTask;
  }
}

代码解释：

  1. 页面不直接构造业务对象，而是调用服务层创建任务。
  2. StudyTask 明确了任务字段，后续传参、缓存和日志都会更清晰。
  3. 服务层可扩展为持久化版本，不影响页面结构。

页面使用方式如下：

@Entry
@Component
struct Index {
  @State latestTitle: string = '暂无任务';

  build() {
    Column({ space: 16 }) {
      Text('Stage 模型学习任务')
        .fontSize(28)
        .fontWeight(FontWeight.Bold)

      Text(this.latestTitle)
        .fontSize(16)
        .fontColor('#5A6B7B')

      Button('开始学习')
        .height(48)
        .onClick(() => {
          const task = StudyTaskService.create('Stage 模型实战', 'home');
          this.latestTitle = task.title;
        })
    }
    .width('100%')
    .height('100%')
    .justifyContent(FlexAlign.Center)
  }
}

这段页面代码只做三件事：显示标题、响应点击、更新 UI。真正的任务对象由服务层创建，这就是从 Demo 走向工程化的第一步。

11. 常见问题

11.1 代码写了但没有生效

先检查配置文件是否声明了对应入口，再检查路径大小写是否一致。Stage 工程里很多问题不是代码逻辑错误，而是配置没有把类和系统入口连接起来。

11.2 页面和 Ability 职责混在一起

页面负责展示和交互，Ability 负责入口和生命周期。业务逻辑如果多个页面都要使用，应该下沉到 services 层。

11.3 后台能力被系统限制

后台任务不能按照桌面端思路设计。要先判断任务是否必须立即执行、用户是否能感知、是否可以延迟，再选择对应方案。

11.4 生命周期日志看不懂

建议为每个入口统一设置 tag，例如 EntryAbility、AbilityStage、TaskService。调试时按 tag 过滤日志，先看入口是否执行，再看页面是否加载，最后看业务服务是否被调用。

11.5 页面能打开但状态不对

优先检查状态是否应该放在页面中。如果状态需要跨页面共享，就放进服务层或持久化存储；如果状态只影响当前页面，再使用 @State 管理。

补充流程图：

理解：常见问题

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 常见问题ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，避免读者只看到一段抽象描述。
  2. 示例代码提供了一个可以迁移到 Stage 工程中的最小实现。
  3. 这段代码将不同的扩展入口统一为请求对象，再按 type 进行分发。这样可以避免将服务、卡片、分享逻辑全部写在一个生命周期回调中。

12. 运行验证清单

  1. 修改 module.json5 后重新构建安装。
  2. 给关键生命周期加 hilog。
  3. 页面路径统一使用 pages/页面名，不要写 .ets 后缀。
  4. 新增页面后同步更新 main_pages.json。
  5. 后台任务应记录任务状态，避免中断后无法恢复。
  6. 将可复用逻辑放入 services，避免散落在页面事件中。

补充流程图：

理解：运行验证清单

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 运行验证清单ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，使读者不会只看到一段抽象描述。
  2. 示例代码提供了一个可迁移到 Stage 工程中的最小实现。
  3. 流程图将本小节从概念、代码位置、实现到验证串联起来，使读者不会只看到一段抽象描述。

13. 读者练习

建议你按下面步骤自己做一遍：

  1. 在现有 Stage 工程里新建一个 services 目录。
  2. 把页面里的任务创建逻辑移动到 StudyTaskService。
  3. 在 Ability 生命周期里加入日志记录。
  4. 新增一个页面，验证页面跳转和服务层状态是否正常。
  5. 把可复用文字移动到 string.json。
  6. 把可复用颜色移动到 color.json。
  7. 重新运行应用，确认入口、页面、服务层职责清晰。

如果这 7 步都能顺利完成，说明你已经不是只会修改默认模板，而是开始按照工程化的方式组织 Stage 应用了。

补充流程图：

理解：读者练习

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 读者练习ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码定位、实现到验证串联起来，使读者不会只看到一段抽象的描述。
  2. 示例代码给出了一个可以迁移到 Stage 工程中的最小实现示例。
  3. 这段代码将不同的扩展入口统一为请求对象，再根据类型进行分发。这样可以避免将服务、卡片、分享等逻辑全部写在一个生命周期回调函数中。

14. 本章总结

ExtensionAbility 面向非页面扩展场景。理解它的边界，才能避免把后台服务、卡片和分享入口都塞进 UIAbility。真正写项目时，不要先问“这个 API 怎么调”，而要先问“这个能力应该属于哪一层”。职责边界清晰，Stage 工程才会越写越稳。

参考资料

  1. 华为开发者文档：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/stage-model-development-overview
  2. 华为开发者文档：https://developer.huawei.com/consumer/cn/doc/harmonyos-faqs/faqs-background-tasks-1
  3. 华为开发者文档：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/start-with-ets-stage
    补充流程图：

理解：本章总结

确定代码位置

编写最小示例

运行验证

沉淀到工程结构

补充代码：

interface ExtensionRequest {
  type: 'service' | 'form' | 'share';
  payload: Record<string, string>;
}

export class 本章总结ExtensionRouter {
  static route(request: ExtensionRequest): string {
    if (request.type === 'service') {
      return 'handle service request';
    }
    if (request.type === 'form') {
      return 'update form content';
    }
    return 'handle share content';
  }
}

代码解释：

  1. 流程图将本小节从概念、代码位置、实现到验证串联起来，使读者不会只看到一段抽象描述。
  2. 示例代码给出了一个可以迁移到 Stage 工程中的最小实现。
  3. 这段代码将不同的扩展入口统一为请求对象，再按 type 进行分发。这样可以避免将服务、卡片、分享逻辑全部写在一个生命周期回调中。
标签
#harmonyos #开发语言 #深度学习 #华为
鸿蒙开发基础——ExtensionAbility组件
guangxishaoji的博客
02-14 1280
以InputMethodExtensionAbility组件为例进行说明，如下图所示，调用方应用发起对InputMethodExtensionAbility组件的调用，此时将先调用输入法管理服务，由输入法管理服务拉起InputMethodExtensionAbility组件，返回给调用方，同时开始管理其生命周期。所有类型的ExtensionAbility组件均不能被应用直接启动，而是由相应的系统管理服务拉起，以确保其生命周期受系统管控，使用时拉起，使用完销毁。
【鸿蒙基于API 13实战开发】—— ExtensionAbility组件
shangkangba的博客
11-19 1097
ExtensionAbility 组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。每一个具体场景对应一个 ExtensionAbilityType ，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如 InputMethodExtensionAbility 组件由输入法管理服务统一管理。当前系统已定义的ExtensionAbility类型如下表所示。
ExtensionAbility 入门：服务、卡片、分享和后台能力边界
最新发布
代码为迹，踩坑成书。
07-01 257
本文介绍了HarmonyOS中ExtensionAbility的四种主要类型：ServiceExtensionAbility、FormExtensionAbility、ShareExtensionAbility和后台能力的应用场景与实现方法。通过具体代码示例，展示了如何创建最小工程结构、声明配置、实现生命周期管理以及处理前后台切换等关键环节。文章强调ExtensionAbility的核心是"受控扩展"而非绕过系统限制，每种扩展类型都需按系统场景规范实现。提供了包含15个检查点的验收清单，帮助开发者在实现后台
鸿蒙Ability Kit（程序框架服务）【ExtensionAbility组件】
鸿蒙的技术博客
06-03 1438
ExtensionAbility组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。每一个具体场景对应一个[ExtensionAbilityType]，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如InputMethodExtensionAbility组件由输入法管理服务统一管理。当前系统已定义的ExtensionAbility类型如下表所示。点击或者复制转到。
HarmonyOS 应用开发之ExtensionAbility组件
2401_89213290的博客
12-20 948
ExtensionAbility组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。每一个具体场景对应一个 ExtensionAbilityType，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如InputMethodExtensionAbility组件由输入法管理服务统一管理。当前系统已定义的ExtensionAbility类型如下表所示。
HarmonyOS 5 Stage模型下ServiceExtensionAbility的使用：天气服务卡片开发
猫林老师 - 致力优质教程编写
09-21 2813
ServiceExtensionAbility是HarmonyOS Stage模型中扩展组件ExtensionAbility的派生类，专门用于提供。它允许应用在无界面的情况下长时间运行，处理后台任务，并为其他组件（如UIAbility或卡片）提供服务支持。在服务卡片场景中，ServiceExtensionAbility（或其特定子类如FormExtensionAbility）扮演着。
【中工开发者】深入理解鸿蒙应用级组件扩展能力（ExtensionAbility）
2301_76522218的博客
12-19 1325
各种扩展能力应用场景各不相同，差异比较大，不具有可比性，因此并不完全存在一个统一的扩展ExtensionAbility的开发模式 一些扩展能力不对普通开发者开放 进程间通信开销较大，使用扩展能力时要注意进程模型。以下是对各类扩展能力的概述。二. 在大多数系统中，扩展能力的调用不能由调用方直接进行，而是由相应的系统管理服务间接拉起的。：扩展能力的调用由系统管理服务间接进行，调用方通过系统提供的接口请求相应的扩展能力。渲染进程与应用的主进程和其他扩展能力进程分离，确保网页内容的独立性和安全性。
HarmonyOS Stage 模型、UIAbility 与 ExtensionAbility 到底怎么分工？
qq_68562226的博客
06-01 405
对于一个新闻、商城或设备控制类应用来说，把首页、详情、账号、后台服务、卡片能力放在同一个大入口里，后期会非常难维护；第一，某个 Ability 文件越来越长，既管页面加载，又管账号、网络、定位、数据库，说明边界已经失控；写鸿蒙应用时，先把模块、Ability、Extension、Navigation 和 Want 的边界画清楚，再写页面和业务代码，后期维护会轻松很多。还应覆盖从通知进入、从卡片进入、从分享面板进入、从外部 Want 拉起、旋转屏幕、切到后台再返回、清理后台后重新进入等路径。
OpenHarmony实战开发：ExtensionAbility组件
qq_39652397的博客
09-09 948
每一个具体场景对应一个ExtensionAbilityType，开发者只能使用（包括实现和访问）系统已定义的类型。
鸿蒙HarmonyOS应用开发 ExtensionAbility组件
sy7748的博客
06-16 966
摘要： ExtensionAbility是面向特定场景的组件，如服务卡片、输入法等，由系统服务统一管理。开发者只能使用系统预定义的类型，不同类型在实现、访问权限及沙箱隔离上有差异。例如，FormExtensionAbility允许三方实现但不允许访问，而InputMethodExtensionAbility允许三方实现和访问且独立沙箱运行。系统应用不受限制，可自由实现和访问所有类型。ExtensionAbility由系统服务管理生命周期，调用方无需关心组件销毁。同一应用内同类型ExtensionAbilit
鸿蒙5.0开发：Stage模型（ExtensionAbility组件）
AyomQAQ的博客
10-17 908
HarmonyOS中的ExtensionAbility组件是一种能够扩展系统功能的能力组件。
【鸿蒙初级知识点】ExtensionAbility组件
2501_90127602的博客
01-04 968
ExtensionAbility 组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。每一个具体场景对应一个 ExtensionAbilityType ，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如 InputMethodExtensionAbility 组件由输入法管理服务统一管理。当前系统已定义的ExtensionAbility类型如下表所示。
鸿蒙 ExtensionAbility摘要
a611510的博客
03-07 286
组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。每一个具体场景对应一个，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如组件由输入法管理服务统一管理。当前系统已定义的ExtensionAbility类型如下表所示。对于系统应用，不受下表约束，允许实现系统已定义的各类ExtensionAbility，也允许访问提供的各类对外服务。是否允许三方应用实现是否允许三方应用访问是否有独立。
华为鸿蒙 ExtensionAbility 组件：扩展应用功能的舞台
xinyuan82的博客
08-15 872
华为鸿蒙系统的阶段模型为开发者提供了一个强大的舞台，而 UIAbility 组件是舞台上的主角，而 ExtensionAbility 组件则是舞台上的配角，负责扩展应用的功能。是华为鸿蒙系统中用于扩展应用功能的组件，它面向特定场景，例如服务卡片、输入法等，为开发者提供丰富的扩展能力。ExtensionAbility 组件运行在独立的进程中，与其他组件的进程隔离，提高了系统的安全性。ExtensionAbility 组件拥有独立的权限配置，与其他组件的权限隔离，提高了系统的安全性。
鸿蒙 ExtensionAbility 组件：扩展应用功能的舞台
liuhaojiabin的博客
10-29 1005
鸿蒙系统的阶段模型为开发者提供了一个强大的舞台，而 UIAbility 组件是舞台上的主角，而 ExtensionAbility 组件则是舞台上的配角，负责扩展应用的功能。这意味着 ExtensionAbility 组件拥有独立的进程和内存空间，与其他组件隔离运行，提高了系统的安全性和稳定性。是华为鸿蒙系统中用于扩展应用功能的组件，它面向特定场景，例如服务卡片、输入法等，为开发者提供丰富的扩展能力。例如，输入法扩展组件由输入法管理服务拉起，服务卡片扩展组件由卡片管理服务拉起。
【中工开发者】HarmonyOS--ExtensionAbility和Worker
wtghost的博客
12-19 1041
Y”表示严格模式访问共享数据，即只能读取共享数据，“N”表示非严格模式访问共享数据，即可以读写共享数据。各种扩展能力应用场景各不相同，差异比较大，不具有可比性，因此并不完全存在一个统一的扩展ExtensionAbility的开发模式，一些扩展能力不对普通开发者开放，进程间通信开销较大，使用扩展能力时要注意进程模型。主线程和Worker线程之间通过消息机制进行通信，主线程创建Worker子线程后，持有Worker子线程线程的引用，子线程则对应一个所在的线程端口（WorkerPort）。
鸿蒙开发—HarmonyOS 应用开发之ExtensionAbility组件
duoduola888的博客
06-09 701
ExtensionAbility组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。每一个具体场景对应一个 ExtensionAbilityType，开发者只能使用（包括实现和访问）系统已定义的类型。各类型的ExtensionAbility组件均由相应的系统服务统一管理，例如InputMethodExtensionAbility组件由输入法管理服务统一管理。当前系统已定义的ExtensionAbility类型如下表所示。
HarmonyOS实战开发：ExtensionAbility组件概述
2401_84194030的博客
04-24 1158
ExtensionAbility组件是基于特定场景（例如服务卡片、输入法等）提供的应用组件，以便满足更多的使用场景。
HarmonyOS 5 鸿蒙ExtensionAbility组件开发实战指南
haolove527的专栏
10-21 7270
鸿蒙Stage模型中的ExtensionAbility组件解析 ExtensionAbility是鸿蒙系统中面向特定场景的应用组件，专注于后台服务、系统集成和特殊功能等非UI场景。其核心设计理念包括场景专业化、系统集成、后台服务和安全隔离。ExtensionAbility包含多种类型：FormExtensionAbility用于开发服务卡片，WorkSchedulerExtensionAbility支持后台任务调度，UIExtensionAbility实现跨进程UI嵌入，而ShareExtensionAbi
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值