大家好，我是[晚风依旧似温柔]，新人一枚，欢迎大家关注~

前言

老实讲，只靠一个 UIAbility 把所有事儿干完的鸿蒙应用，说好听点叫“极简”，说难听点吧……多少有点“体面归体面，但不太耐用”。
  你总不能指望一个前台页面，既一直在线接收消息、又默默上传日志、还定时同步数据、偶尔再整点定时任务，这也太打工人了。

这时候，本地服务（Service ExtensionAbility） 就像是你 App 的“后台工具人”：安静、持久、抗造、不抢界面风头，但业务一刻不停。

这一章我们就围绕你给的大纲，把这些问题聊透：

• ExtensionAbility 都有哪些类型？Service 究竟负责啥？
• 后台服务到底适合干哪些“脏活累活”？
• 定时任务在鸿蒙里怎么优雅搞？
• UIAbility 怎么和 Service Extension 通信？
• 哪些真实业务场景必须上 Service，不上吃大亏？

中途还会穿插一套可落地的代码示例，你拎走就能改着用，不整那些花里胡哨的空话。

---

一、ExtensionAbility 类型：先搞清“职业分工”，再谈用谁干活

鸿蒙里有个很容易搞混的点：ExtensionAbility 不止 Service 一种。如果你没搞清谁是谁，很容易用错工具，最后把项目写成了“拆迁现场”。

1️⃣ ExtensionAbility 大家族速览

常见几种（不同版本命名略有变动，这里按典型场景来区分）：

• ServiceExtensionAbility

  • 主打：本地/后台服务逻辑
  • 特点：可在后台长期运行，可被 UIAbility / 其他应用连接或启动

• FormExtensionAbility

  • 主打：卡片（桌面小组件）
  • 用于提供卡片数据、更新卡片内容

• DataShareExtensionAbility / DataShare Extension

  • 主打：数据共享（类似 ContentProvider）
  • 用于跨应用数据访问

• AccessibilityExtensionAbility

  • 主打：无障碍辅助（如读屏、辅助操作）

• WorkSchedulerExtensionAbility / Job 类能力

  • 主打：系统级调度任务（低电量、充电中、网络可用时再执行等）

而我们这章主角就是：

ServiceExtensionAbility：
负责在“无界面/后台”持续跑业务逻辑的本地服务。

它不用展示 UI，也不抢首屏资源，就是负责——一直在。

---

二、后台服务场景：哪些事儿该丢给 Service 来干？

一句大实话：只要是“用户不在前台看，但你还得继续干”的事儿，基本都该 Service 出场。

常见的后台服务场景包括：

• ✅ 长连接 / IM 心跳维护

  • WebSocket / TCP 长连
  • 心跳、重连、消息分发

• ✅ 后台文件上传 / 下载

  • 大文件断点续传
  • 多任务并行下载

• ✅ 音乐 / 音频播放服务

  • 前台页面关了，歌还得播
  • 通知栏控制、锁屏控制

• ✅ 后台数据同步

  • 与服务器定期同步配置、缓存、离线数据

• ✅ 传感器 / 位置上报

  • 运动记录、轨迹上报（在合规前提下）

• ✅ 本地任务队列 / 消息中心

  • 收集前台上报任务，在后台排队处理

一句归纳：

UIAbility 负责“眼前看到的事儿”；
ServiceExtension 负责“看不见但必须做的事儿”。

---

三、先上代码：一个最小可跑的 ServiceExtensionAbility

纸上谈兵没意思，先上一个“能跑”的最小例子。下面用典型 Stage 模型风格的伪代码示意（接口名你根据实际 SDK 略微调整就行，结构逻辑是一致的）。

1️⃣ 声明一个 Service Extension（module.json5 / config.json）

{
  "module": {
    "extensionAbilities": [
      {
        "name": "DownloadServiceExt",
        "srcEntrance": "./ets/extension/DownloadServiceExt.ets",
        "type": "service",
        "exported": true,                // 是否允许其他应用连接
        "process": ":download_process",  // 独立进程（推荐）
        "permissions": [
          "ohos.permission.INTERNET"
        ]
      }
    ]
  }
}

2️⃣ 实现 ServiceExtensionAbility

// ets/extension/DownloadServiceExt.ets
import rpc from '@ohos.rpc';
import serviceExtension from '@ohos.app.ability.ServiceExtensionAbility';

class DownloadRemote extends rpc.RemoteObject {
  constructor(descriptor: string) {
    super(descriptor);
  }

  // 简单示例：通过 code 区分调用
  onRemoteRequest(code: number, data: rpc.MessageParcel, reply: rpc.MessageParcel, option: rpc.MessageOption) {
    console.info(`DownloadRemote onRemoteRequest, code = ${code}`);
    switch (code) {
      case 1: // 开始下载
        const url = data.readString();
        this.startDownload(url);
        reply.writeString('start ok');
        return true;
      case 2: // 查询进度
        const progress = 42; // demo: 假装 42%
        reply.writeInt(progress);
        return true;
      default:
        return false;
    }
  }

  startDownload(url: string) {
    console.info(`开始后台下载：${url}`);
    // 这里写真实下载逻辑，比如使用 Http 请求分片下载
  }
}

export default class DownloadServiceExt extends serviceExtension {
  private remote: DownloadRemote | null = null;

  onCreate(want: any) {
    console.info('DownloadServiceExt onCreate');
    this.remote = new DownloadRemote('DownloadRemote');
  }

  onRequest(want: any, startId: number) {
    console.info('DownloadServiceExt onRequest, startId = ' + startId);
    // 可在这里基于 want 触发某些任务
  }

  onConnect(want: any) {
    console.info('DownloadServiceExt onConnect');
    return this.remote;
  }

  onDisconnect(want: any) {
    console.info('DownloadServiceExt onDisconnect');
  }

  onDestroy() {
    console.info('DownloadServiceExt onDestroy');
  }
}

这段代码里的关键点：

• ServiceExtensionAbility 负责提供一个 RemoteObject
• UIAbility 或其他客户端通过 connect 方式拿到 remote
• 通过 onRemoteRequest 做 IPC 调用

有了这个基础模版，你基本可以把任意“后台任务”塞进去。

---

四、定时任务：后台服务怎么“按点干活”？

光有后台不够，有些任务得“按时间点来”：

• 每隔 10 分钟同步一次配置
• 每天凌晨清理缓存
• 每隔 N 分钟上报一次状态

在鸿蒙里，有两种常见方式：

1. Service 自己用定时器轮询（简单粗暴）
2. 配合系统调度能力（WorkScheduler / Alarm 等）

下面搞一个“定时同步配置”的简化示例。

1️⃣ 在 Service 里用定时器轮询（适合短周期定时）

// 在 DownloadServiceExt 或类似 Service 中
import worker from '@ohos.worker';

let timer: number | undefined;

function startPeriodicSync() {
  if (timer !== undefined) {
    globalThis.clearInterval(timer);
  }
  timer = globalThis.setInterval(() => {
    console.info('开始执行周期任务：同步配置...');
    // TODO: 发起 http 请求，同步配置
  }, 5 * 60 * 1000); // 每 5 分钟
}

export default class SyncServiceExt extends serviceExtension {
  onCreate() {
    console.info('SyncServiceExt onCreate');
    startPeriodicSync();
  }

  onDestroy() {
    console.info('SyncServiceExt onDestroy');
    if (timer !== undefined) {
      globalThis.clearInterval(timer);
    }
  }
}

优点：

• 写起来极其简单
• 对开发心智负担小

缺点：

• 对系统电量、性能不够友好
• 周期太短、太多服务会被系统“关照”

2️⃣ 用系统调度（比如 WorkScheduler 思路）

如果你要的是：

• “手机充电时再跑”
• “有 Wi-Fi 时再同步”
• “系统觉得现在资源宽裕时再执行”

那就要走系统调度型 Extension / 任务调度能力，这里就不展开写完整代码了，只提醒一句：

高频小任务可用 Service 自己定时；
低频大任务尽量交给系统调度。

---

五、与 UIAbility 通信：前台发号施令，后台踏实干活

说白了，Service 就是后台干活的，UIAbility 是前台“老板”。那问题来了：

老板怎么把指令发给后台？
后台干活后，怎么把进度/结果再告诉老板？

典型方式就是：

• UIAbility 连接 ServiceExtensionAbility
• 拿到 RemoteObject，基于 RPC 调用传参
• 或者：通过事件总线、数据对象、中转仓等方式通知

1️⃣ UIAbility 连接 ServiceExtension

// ets/entryability/EntryAbility.ets
import UIAbility from '@ohos.app.ability.UIAbility';
import rpc from '@ohos.rpc';

class DownloadProxy {
  constructor(private remote: rpc.IRemoteObject) {}

  start(url: string): Promise<string> {
    return new Promise((resolve, reject) => {
      let data = rpc.MessageParcel.create();
      let reply = rpc.MessageParcel.create();
      let option = new rpc.MessageOption();

      data.writeString(url);
      this.remote.sendRequest(1, data, reply, option).then(() => {
        const result = reply.readString();
        resolve(result);
      }).catch(reject);
    });
  }

  getProgress(): Promise<number> {
    return new Promise((resolve, reject) => {
      let data = rpc.MessageParcel.create();
      let reply = rpc.MessageParcel.create();
      let option = new rpc.MessageOption();
      this.remote.sendRequest(2, data, reply, option).then(() => {
        const progress = reply.readInt();
        resolve(progress);
      }).catch(reject);
    });
  }
}

export default class EntryAbility extends UIAbility {
  private downloadProxy: DownloadProxy | null = null;

  onWindowStageCreate(windowStage: any) {
    // 省略 UI 初始化...
    this.connectDownloadService();
  }

  connectDownloadService() {
    let want = {
      bundleName: 'com.example.demo',
      abilityName: 'DownloadServiceExt'
    };
    this.context.connectServiceExtensionAbility(want, {
      onConnect: (elementName, remote) => {
        console.info('连接 DownloadService 成功');
        this.downloadProxy = new DownloadProxy(remote);
      },
      onDisconnect: () => {
        console.info('Service 断开连接');
        this.downloadProxy = null;
      },
      onFailed: (err) => {
        console.error('连接 Service 失败：', JSON.stringify(err));
      }
    });
  }

  async onClickStartDownload() {
    if (!this.downloadProxy) {
      console.warn('Service 未连接');
      return;
    }
    const res = await this.downloadProxy.start('https://example.com/file.zip');
    console.info('启动下载结果：' + res);
  }
}

这一套下来，一个完整链路就打通了：

1. UIAbility 启动时连接 Service
2. Service 返回 RemoteObject（onConnect）
3. UIAbility 包装一个 DownloadProxy，方便用 Promise 调用
4. 点击按钮 → 调 start(url) → Service 后台下载

要是再加上进度轮询/回调，就能搞一个前台进度条 + 后台真下载的完整体验。

---

六、典型后台服务场景：不举例你可能真想不到有多实用

讲到这儿，如果你还在纠结“我到底要不要用 Service？”，下面这几个真实场景，你随便选一个，都值得你搞个 Service：

✅ 场景 1：音乐 / 音频播放服务

• 播放逻辑、播放队列、解码缓冲都在 Service 中
• UIAbility 只是一个“控制面板”和“展示层”
• 页面关了、应用切后台，音乐照样播放
• 可以配合通知、控制中心控件

Service 主要干：

• 音频引擎初始化
• 播放、暂停、上一首、下一首
• 媒体状态广播（当前进度、当前曲目）

✅ 场景 2：后台下载中心

• 大文件下载（视频、补丁包、离线地图等）
• 多任务并行 / 队列下载
• 断点续传、失败重试
• 通知下载完成

UIAbility 只展示：

• 当前下载任务列表
• 进度条、暂停/继续按钮

Service 负责：

• 管理任务队列
• 保持 HTTP 连接
• 写入本地文件
• 状态持久化（防崩溃）

✅ 场景 3：IM / 长连接服务

• WebSocket / TCP 连接需要长时间维持
• 心跳定时、重连策略
• 消息到达及时分发给前台页面

Service 做：

• 维护一个稳定长链接
• 消息路由（转给对应会话 ）
• 离线缓存、消息落盘

UIAbility 做：

• 会话列表、聊天窗口
• 从 Service 取消息、发送消息

✅ 场景 4：日志上报 / 统计服务

• 不想在用户关键交互时阻塞体验
• 上报批量日志、埋点数据
• 在合适的时间（比如连上 Wi-Fi）上传

Service 负责：

• 本地日志队列
• 批量上报（失败重试）
• 清理过期数据

---

七、写给真正在做项目的你：几条容易被忽略但很关键的建议

到这儿你大概已经知道 “什么是 Service Extension”、“它能干啥”、“怎么和 UIAbility 搭配”，但真到项目里，还有几点经验血泪教训想顺手给你说说：

1️⃣ 别什么都丢给 Service

后台能力很香，但滥用就会变成“电量杀手”。一些完全和后台无关的短操作，不用故意弄个 Service，UIAbility 里发个普通 http 请求就完事。

👉 经验：“长期 & 可复用 & 和界面解耦”的任务才值得入住 Service。

2️⃣ 能用一次性任务就不要长驻

如果只是“启动一次任务，做完就拉倒”，可以：

• UIAbility 调用 startServiceExtensionAbility →
• Service 做完任务 → stopSelf() / 让系统销毁

而不是永远跑着一个 Service 占资源。

3️⃣ 通信层封装成 Proxy / Manager

千万别在 UI 界面的每个页面里直接用 sendRequest。

推荐做法：

• 封装一个 XXXServiceProxy 类，里边封装所有 code / parcel 逻辑
• UI 只拿这个 Proxy 调方法，就像本地方法调用
• 将来 RPC 协议变了，只改 Proxy 即可

4️⃣ 注意权限和进程

• 提前在 module 配好 process，把重任务丢后台进程
• 网络权限、存储权限、位置权限等不要忘
• 如果 Service 要访问某些敏感能力，得搞清楚是否需要用户授权

---

尾声：没有后台服务的应用，真的撑得住未来吗？

说句稍微有点重的话：

未来的应用，越来越少是“页面驱动型”，
而越来越多是“服务驱动型”。

UIAbility 只是负责把体验摆到用户面前，真正的业务长期生命力，很大一部分恰恰来自这些看不见、却一直在运转的本地服务。

如果觉得有帮助，别忘了点个赞+关注支持一下~
喜欢记得关注，别让好内容被埋没～