7.3 元服务与原子化服务

7.3 元服务与原子化服务

本节摘要：元服务（早期称原子化服务）是免安装、以卡片为主要形态、大小受限的服务交付方式。本节开发一个可添加到桌面的备忘卡片，讲清 FormAbility 的生命周期、卡片与宿主应用的通信约束，以及元服务形态带来的产品与工程取舍。

免安装的服务卡片

先厘清名词：HarmonyOS 早期的"原子化服务"在后续版本统一改称"元服务"，指的是同一件事——一种免安装的服务形态：用户不必安装完整应用，通过卡片、扫码、搜索等入口直接使用某个服务单元。它的可见载体多半是"服务卡片"：桌面或服务中心里的一小块界面，显示关键信息并提供轻交互。

工程上的差异从模板选择就开始。在 DevEco Studio 新建元服务（或给现有工程添加 Service Widget 模板）后，你会得到一个 FormAbility 的派生类——第 2 章提过的 ExtensionAbility 家族成员，没有独立界面，由系统在需要卡片时拉起：

import { FormExtensionAbility } from '@kit.FormKit';
import { formBindingData, formProvider } from '@kit.ArkUI';

export default class MemoFormAbility extends FormExtensionAbility {
  onAddForm(want: Want): formBindingData.FormBindingData {
    const noteCount = MemoStore.countToday();
    return formBindingData.createFormBindingData({
      'count': noteCount.toString(),
      'latest': MemoStore.latestTitle()
    });
  }

  onUpdateForm(formId: string): void {
    const noteCount = MemoStore.countToday();
    formProvider.updateForm(formId,
      formBindingData.createFormBindingData({
        'count': noteCount.toString(),
        'latest': MemoStore.latestTitle()
      })
    ).catch(() => {});
  }
}
​

onAddForm 在用户把卡片添加到桌面时被调用，返回的绑定数据就是卡片的初始数据源；onUpdateForm 是系统觉得该刷新时（或你主动请求）的回调。卡片界面本身是一个 ArkTS 组件文件，写法与普通页面几乎一致，但只能用受限的组件集与样式（这是为了跨宿主渲染的一致性与安全）：

let storage = new LocalStorage();

@Entry(storage)
@Component
struct MemoCard {
  @LocalStorageProp('count') count: string = '0'
  @LocalStorageProp('latest') latest: string = '(暂无)'

  build() {
    Column({ space: 8 }) {
      Text('今日备忘')
        .fontSize(14).fontColor('#666666')
      Text(this.count)
        .fontSize(32).fontWeight(FontWeight.Bold)
      Text(this.latest)
        .fontSize(12)
        .maxLines(1)
        .textOverflow({ overflow: TextOverflow.Ellipsis })
    }
    .padding(16)
    .width('100%')
    .height('100%')
    .alignItems(HorizontalAlign.Start)
    .onClick(() => {
      postCardAction(this, {
        'action': 'router',
        'abilityName': 'EntryAbility'
      });
    })
  }
}
​

数据经 LocalStorage 注入（@LocalStorageProp 与第 4 章 AppStorage 家族是近亲，作用域换成卡片实例）；点击卡片用 postCardAction 拉起宿主应用的完整页面——"卡片给一眼信息，点击进完整应用"就是标准的分层触达。

元服务的约束与取舍

免安装不是免费的，约束集中在三处。大小限制：元服务包体有严格上限（兆级），逼你把"服务"切到最小可用——这反过来是个好的产品设计练习：如果只能留 2 兆，你的服务核心是什么？能力限制：部分需要完整应用上下文的 API 在元服务里不可用或受限，接口选型要提前核对。商业分发：元服务在服务中心、负一屏等场所有独立的分发逻辑与审核口径。

从架构视角看，元服务与应用不是二选一，而是同一服务的两种交付粒度。备忘录应用的合理形态是：完整应用承载编辑管理，元服务卡片承载"看一眼今日数量、快速进入"，两者共享业务数据（卡片刷新时读的就是第 5 章那个数据库，元服务与宿主应用的数据访问按部署形态确认沙箱关系，独立分发时则需要服务端数据源）。

⚠️ 常见坑：把卡片当小页面写，塞进复杂交互与网络请求。卡片的刷新频率由系统调度管制，高频请求既不环保也会被限流。卡片的本分是"展示与入口"，重交互留给点击后的完整应用。

💡 关键直觉：评估要不要做元服务，问两个问题——用户的高频动作是否"看一眼就够"（天气、日程、余额都是，视频剪辑不是）；获客路径是否值得免安装（扫码即用的服务场景，安装门槛砍掉就是转化率）。

演练：从添加到刷新的闭环

背景：备忘应用的桌面卡片显示"今日条数与最新标题"。操作分三段。其一，添加：长按应用图标进服务卡片，选 2x2 规格添加到桌面，验证初始数据正确。其二，刷新：宿主应用里新增一条备忘，回到桌面看卡片是否更新——若不更新，在应用的增删改处主动调 formProvider 的更新接口（需要管理卡片标识），对比系统自动刷新的节奏差异。其三，点击：点卡片进应用，验证 postCardAction 的路由落点。解读：三段实验分别对应 FormAbility 生命周期里"生、更、点"三类交互，每一段的系统行为都与普通应用不同——被系统按需拉起、刷新受调度管制、交互以拉起宿主为归宿。变式：给卡片加一个"快速记一条"的按钮（postCardAction 的 message 动作，由 FormAbility 的 onFormEvent 接收后落库），体验"卡片即轻入口"的完整闭环。

本节要点回顾：

• 概念沿革：原子化服务即元服务，免安装、卡片为主载体、包体受限。
• FormAbility：ExtensionAbility 家族成员，onAddForm 给初始数据、onUpdateForm 被动刷新、onFormEvent 接卡片动作。
• 卡片界面：受限组件集加 LocalStorage 数据注入，postCardAction 连接宿主。
• 约束三点：包体上限、能力受限、独立分发口径。
• 产品判据：看一眼就够的高频动作加值得砍掉的安装门槛。

分布式与多形态交付至此走完。最后一章处理出门前的三件事：把性能调上去、把质量测扎实、把应用签好名送上线。