ServiceExtensionAbility 这个组件我在几个 HarmonyOS 项目里都深度用过从早期的 API 9 到现在的 API 12踩过的坑能写满一页纸。它本质上是一个没有界面的、运行在后台的扩展能力组件专门用来处理那些不需要用户直接交互、但又必须长期或按需驻留的逻辑——比如后台数据同步、设备状态监听、长时任务托管、跨应用的服务调用等。和 UIAbility 最大的区别在于它没有窗口、没有页面栈生命周期完全由系统调度开发者能干预的余地比想象中要小得多。这篇文章适合两类人看一类是刚接触 HarmonyOS 应用开发、对 ExtensionAbility 体系还没建立完整认知的新手另一类是已经用过但总在进程保活、跨进程通信、权限申请上反复翻车的同行。我会把 ServiceExtensionAbility 的注册方式、生命周期、通信模型、权限约束、调试手段和几个真实场景下的实现方案拆开讲透所有代码和配置都可以直接抄去改。1. 先搞清楚它到底解决什么问题1.1 从 UIAbility 的局限说起大部分 HarmonyOS 应用起步都是从 UIAbility 开始的有页面、有交互、有明确的用户操作路径。但一旦业务里出现用户切到后台了数据还得继续传、设备传感器状态变了应用得被动响应、别的应用想调用我这边的一个能力但我不想拉起界面这类需求UIAbility 就力不从心了。UIAbility 的生命周期和窗口绑定得太紧切后台之后系统对它的资源管控会迅速收紧长时间跑后台逻辑很容易被挂起甚至回收。ServiceExtensionAbility 就是在这个缝隙里补位的。它继承自 ExtensionAbility运行在独立于 UI 的进程模型里可以被其他应用通过 Want 拉起也可以随宿主应用一起被系统调度。它没有页面所以不存在切后台这个概念上的界面状态变化系统对它的管控逻辑主要围绕任务类型、权限等级和资源占用来走。换句话说它更像是一个服务端组件而不是界面组件的后台版本。这里有个认知误区要先纠正很多人以为 ServiceExtensionAbility 就等于 Android 的 Service可以随便常驻。实际上 HarmonyOS 对后台任务的管控比 Android 严格得多ServiceExtensionAbility 能不能长期存活取决于你声明的任务类型和系统当前的资源策略不是你想跑就能跑。这一点在后面讲生命周期和权限时会展开。1.2 三类典型适用场景我把实际项目里用到 ServiceExtensionAbility 的场景归了三类基本覆盖了绝大多数需求。第一类是跨应用能力开放。比如你做了一个设备管理类的应用想把查询设备电量这个能力开放给其他应用调用但又不想让对方拉起你的界面。这时候就可以用 ServiceExtensionAbility 暴露一个可被外部 Want 拉起的服务对方通过 startAbility 或 connectAbility 的方式调用你在 onConnect 里返回一个 RemoteObject 供对方跨进程通信。这种模式下服务是被动拉起的调用方用完就释放资源模型很干净。第二类是长时任务托管。比如后台定位上报、后台音视频处理、后台文件传输。这类任务的特点是耗时长、不能中断需要向系统申请对应的长时任务类型backgroundTaskType否则进程会被快速冻结。ServiceExtensionAbility 在这里承担的是任务容器的角色真正的业务逻辑跑在它拉起的线程或 Worker 里。第三类是系统事件响应。比如监听网络状态变化、监听设备连接状态、监听某些系统广播。这类场景下 ServiceExtensionAbility 更像一个事件处理器被系统在特定时机拉起处理完就退出不需要常驻。这种用法对资源最友好也是系统最鼓励的模式。1.3 和 ExtensionAbility 家族其他成员的分工ExtensionAbility 是一个大家族除了 ServiceExtensionAbility还有 FormExtensionAbility卡片、DataShareExtensionAbility数据共享、InputMethodExtensionAbility输入法等等。它们的共同点是都没有独立界面、都由系统按特定规则调度区别在于触发时机和能力边界。ServiceExtensionAbility 的定位是通用后台服务它不像 FormExtensionAbility 那样绑定卡片生命周期也不像 DataShareExtensionAbility 那样绑定数据提供者模型。它的通用性最强但也意味着很多事情要自己兜底——比如连接管理、线程调度、异常恢复系统不会帮你做太多。选型的时候我的经验是能用更专用的 ExtensionAbility 就别用 ServiceExtensionAbility因为专用组件的系统约束更明确、调试路径更短只有当需求确实跨了多个专用模型的边界才落到 ServiceExtensionAbility 上。2. 注册与声明配置文件里的每一个字段都有讲究2.1 module.json5 中的 extensionAbilities 配置ServiceExtensionAbility 必须在 module.json5 的 extensionAbilities 数组里声明否则系统根本不知道它的存在。一个最小可用的配置长这样{ module: { extensionAbilities: [ { name: DeviceSyncService, srcEntry: ./ets/serviceextability/DeviceSyncService.ets, description: $string:device_sync_desc, icon: $media:icon, type: service, exported: true, skills: [ { actions: [action.device.sync], entities: [entity.system.default] } ] } ] } }这里每个字段都不是随便填的。type必须是service这是区分它和 FormExtensionAbility 等组件的关键标识填错了系统会按错误的模型调度行为完全不可预期。exported决定这个服务能不能被其他应用拉起设为 true 的时候要格外谨慎因为这意味着你的服务暴露在了整个设备的能力调用面上后面讲权限时会说怎么收窄。skills里的actions是外部应用拉起你时匹配的标识相当于一个约定好的服务名。我习惯用带命名空间前缀的字符串比如action.设备类型.功能避免和其他应用撞车。entities一般填entity.system.default就行除非你有特殊的实体匹配需求。2.2 srcEntry 路径与文件结构约定srcEntry指向的是 ServiceExtensionAbility 的实现文件路径是相对于 module 根目录的。这里有个容易翻车的点文件扩展名在 API 9 早期版本里要求是.ts后来统一成.ets如果你照着老文档写.ts在新版本上会编译报错。我现在的习惯是一律用.ets并且把 ServiceExtensionAbility 的实现文件单独放在ets/serviceextability/目录下和 UIAbility 的ets/entryability/分开目录结构清晰后期维护时一眼就能看出哪些是后台服务、哪些是界面入口。文件内部的类名要和配置里的name保持一致并且必须继承ServiceExtensionAbility。类名不一致的话系统在拉起时会找不到对应的实现报错信息往往很隐晦只告诉你extension not found排查起来很费时间。我踩过一次这个坑原因是重命名了类但忘了同步改配置查了快一个小时才发现。2.3 exported 与权限的联动控制exported: true只是第一步真正决定谁能调用你的是权限声明。HarmonyOS 的权限模型里你可以在 extensionAbilities 的配置里加permissions字段限制只有持有特定权限的应用才能拉起你的服务{ name: DeviceSyncService, srcEntry: ./ets/serviceextability/DeviceSyncService.ets, type: service, exported: true, permissions: [com.example.permission.ACCESS_DEVICE_SYNC], skills: [...] }这个permissions字段的语义是调用方必须持有这些权限。权限本身要在应用的权限列表里定义并且是自定义权限custom permission的范畴。自定义权限的声明在 module.json5 的requestPermissions或者更上层的权限配置里需要指定权限名、授权方式system_grant 或 user_grant和可被哪些应用申请。我的经验是只要exported设为 true就一定要配permissions哪怕是个很宽松的自定义权限也比裸奔强。裸奔的服务等于把能力完全敞开任何应用都能拉起这在安全审计里是硬伤。如果服务只给自己应用内部用那exported直接设 false省去权限配置的麻烦这是最省心的做法。3. 生命周期系统说了算你只能配合3.1 onCreate 到 onDestroy 的完整链路ServiceExtensionAbility 的生命周期回调比 UIAbility 少但每一个的触发时机都很关键。核心回调有这么几个onCreate(want, launchParam)服务被创建时调用只调一次。适合做初始化比如建立数据库连接、注册监听器。onRequest(want, startId)每次通过 startAbility 拉起服务时调用可能被调多次。适合处理一次性的请求逻辑。onConnect(want)通过 connectAbility 连接服务时调用返回一个 RemoteObject。可能被调多次每次连接都会触发。onDisconnect(want)连接断开时调用和 onConnect 配对。onDestroy()服务被销毁时调用适合做资源释放。这里有个很重要的细节onCreate和onRequest的调用顺序。第一次拉起时系统先调onCreate再调onRequest后续再拉起时如果服务还活着只调onRequest不再调onCreate。所以初始化逻辑必须放在onCreate里不能放在onRequest里否则重复拉起时会重复初始化轻则资源浪费重则状态错乱。onConnect和onRequest是两条独立的路径。用 startAbility 拉起走onRequest用 connectAbility 连接走onConnect。同一个服务可以同时被这两种方式触发你要在代码里区分清楚当前是哪种调用否则容易把连接型请求当成一次性请求处理导致 RemoteObject 没返回、调用方一直等。3.2 进程优先级与后台冻结机制ServiceExtensionAbility 所在的进程优先级不是固定的系统会根据服务当前的任务类型、是否有活跃连接、资源占用情况动态调整。没有声明长时任务类型的服务在应用切到后台一段时间后进程会被冻结freeze所有线程暂停执行直到有新的 Want 进来或者应用回到前台才解冻。这个冻结机制是很多人踩坑的重灾区。我见过有同行在 ServiceExtensionAbility 里起了个定时器做数据上报测试的时候一切正常因为测试时应用一直在前台一上线用户切后台定时器就停了数据断了。根本原因就是没申请长时任务类型进程被冻结了。要突破冻结必须在配置里声明backgroundTaskType并且向系统申请对应的长时任务。长时任务类型有好几种比如dataTransfer数据传输、audioPlayback音频播放、location定位、audioRecording录音等。声明方式是在 extensionAbilities 配置里加backgroundTaskType字段同时在代码里调用backgroundTaskManager.startBackgroundRunning申请。申请成功后系统会给你一个持续的运行许可进程不会被冻结但会有一个常驻通知提示用户某应用正在后台运行这是系统对用户知情权的保障绕不过去。3.3 服务被回收的几种触发条件即使申请了长时任务服务也不是绝对安全的。以下几种情况会导致服务被系统回收第一种是资源超限。系统对单个应用的 CPU、内存、网络占用都有阈值超了会被强制回收。长时任务只是免于冻结不是免于资源管控。我遇到过一次后台传输大文件时内存峰值过高被回收后来改成流式读写、分片处理才稳住。第二种是用户主动清理。用户在最近任务列表里划掉应用或者在设置里强制停止服务会立即销毁。这个没法对抗也不应该对抗属于用户主权范畴。第三种是长时任务许可到期或被撤销。某些长时任务类型有最长运行时长限制到期后系统会撤销许可服务随之被冻结或回收。具体时长和任务类型有关文档里有说明但不同版本可能有调整实际开发时要以当前 SDK 版本的文档为准。第四种是系统资源紧张时的全局回收。设备内存吃紧时系统会按优先级回收后台服务长时任务的服务优先级较高但不是最高。这种回收不可预测所以服务的设计必须做到随时可被销毁、销毁后能恢复不能把关键状态只放在内存里。4. 跨进程通信RemoteObject 是核心4.1 onConnect 返回 RemoteObject 的标准写法跨应用调用 ServiceExtensionAbility 的主流方式是 connectAbility调用方拿到一个连接服务方在onConnect里返回一个 RemoteObject双方通过 IPC 通信。服务端的标准写法是这样的import { ServiceExtensionAbility, Want } from kit.AbilityKit; import { rpc } from kit.IPCKit; class DeviceSyncStub extends rpc.RemoteObject { constructor(descriptor: string) { super(descriptor); } onRemoteMessageRequest( code: number, data: rpc.MessageSequence, reply: rpc.MessageSequence, options: rpc.MessageOption ): boolean { if (code 1001) { const deviceId data.readString(); const result this.queryDeviceStatus(deviceId); reply.writeString(result); return true; } return false; } private queryDeviceStatus(deviceId: string): string { return status_of_${deviceId}; } } export default class DeviceSyncService extends ServiceExtensionAbility { private stub: DeviceSyncStub new DeviceSyncStub(device_sync_stub); onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void { console.info(DeviceSyncService onCreate); } onConnect(want: Want): rpc.RemoteObject { return this.stub; } onDisconnect(want: Want): void { console.info(DeviceSyncService onDisconnect); } onDestroy(): void { console.info(DeviceSyncService onDestroy); } }这段代码里有几个关键点。RemoteObject的构造函数参数是一个 descriptor 字符串调用方在连接成功后可以通过getDescriptor()拿到这个值做校验相当于一个轻量的身份标识。onRemoteMessageRequest是处理 IPC 请求的入口code是调用方约定的业务码data是请求数据reply是回复数据。返回 true 表示已处理false 表示未识别。业务码的设计我建议做成常量表服务端和调用方共用一份定义避免两边对不上。我见过有项目里业务码是硬编码的魔法数字服务端改了调用方没改结果请求全部静默失败排查了半天。4.2 调用方如何连接并发送请求调用方的写法相对简单核心是connectServiceExtensionAbility拿到连接然后在onConnect回调里拿到 RemoteObject再发请求import { common, Want } from kit.AbilityKit; import { rpc } from kit.IPCKit; const want: Want { bundleName: com.example.deviceprovider, abilityName: DeviceSyncService }; let connectionId: number -1; const connection: common.ConnectOptions { onConnect: (elementName, remoteProxy) { const data rpc.MessageSequence.create(); const reply rpc.MessageSequence.create(); data.writeString(device_001); remoteProxy.sendMessageRequest(1001, data, reply, new rpc.MessageOption()) .then(() { const status reply.readString(); console.info(device status: ${status}); }) .catch((err: Error) { console.error(request failed: ${err.message}); }); }, onDisconnect: (elementName) { console.info(disconnected); }, onFailed: (code) { console.error(connect failed: ${code}); } }; const context getContext(this) as common.UIAbilityContext; context.connectServiceExtensionAbility(want, connection).then((id) { connectionId id; });这里要注意MessageSequence的创建和释放。每次请求都要新建一对 data 和 reply用完要调用reclaim()释放否则会泄漏 IPC 缓冲区。我早期写的时候没注意这个跑压力测试时内存一路涨最后定位到就是 MessageSequence 没回收。另外sendMessageRequest是异步的返回 Promise调用方要处理好 then/catch。如果服务端onRemoteMessageRequest返回 false调用方这边会收到一个错误但错误信息不一定直观所以服务端对未识别的 code 最好也写个日志方便两边对账。4.3 同步与异步调用的取舍sendMessageRequest是异步的还有sendMessageRequestAsync等变体具体用哪个取决于业务对时延和阻塞的容忍度。我的原则是跨进程调用一律用异步哪怕业务逻辑本身很快。原因是 IPC 的时延不可控设备负载高的时候同步调用可能阻塞调用方线程几百毫秒如果调用方在主线程上直接就是卡顿。服务端这边onRemoteMessageRequest是在 IPC 线程池里执行的不是主线程所以服务端做耗时操作不会卡 UI但也不能无限耗时否则会占满 IPC 线程池影响其他请求。耗时逻辑应该丢到 Worker 或者 TaskPool 里异步执行onRemoteMessageRequest里只做参数解析和结果回写。5. 权限与安全exported 不是开关是责任5.1 自定义权限的完整声明链路前面提到permissions字段限制调用方但权限本身要先定义。自定义权限的声明分两步第一步在权限配置文件里定义权限第二步在需要申请该权限的应用里声明使用。定义权限一般在应用的module.json5里通过requestPermissions声明但自定义权限更规范的做法是单独维护一份权限定义。权限定义要包含name、grantMode、availableLevel等字段。grantMode选system_grant表示安装即授予选user_grant表示需要用户手动授权。对于服务调用类的权限我一般用system_grant因为这类权限不涉及用户隐私数据走用户授权反而增加摩擦。availableLevel决定权限的开放范围有normal、system_basic、system_core几档。普通应用自定义的权限只能是normal更高档位需要系统级签名普通开发者用不到。所以实际项目里自定义权限基本都是normal级别配合system_grant调用方在配置文件里声明后即可使用。5.2 调用方校验与服务端二次校验光靠配置文件的permissions字段做准入控制是不够的因为那只在拉起阶段生效连接建立之后的 IPC 请求并不再校验权限。所以服务端在onRemoteMessageRequest里必须做二次校验确认调用方的身份和权限。校验调用方身份可以用RemoteObject的getCallingPid()和getCallingUid()拿到调用方的进程和用户 ID再结合包管理接口查询对应的 bundleName和白名单比对。这套逻辑稍微有点绕但安全性提升明显。我一般会封装一个checkCallerPermission方法在每次处理敏感请求前调用不通过就直接返回错误码。二次校验的另一个作用是防重放和防越权。比如某个请求带了设备 ID 参数服务端要校验这个设备 ID 是否属于调用方有权访问的范围不能光看调用方有没有权限还要看它有没有权限访问这个具体资源。这层逻辑配置层面做不了只能在代码里写。5.3 敏感操作的审计日志设计只要服务对外开放就必须有审计日志。我习惯在onRemoteMessageRequest的入口和出口各打一条日志记录调用方 UID、业务码、请求参数摘要、处理结果、耗时。日志不要打完整参数尤其是可能含敏感信息的字段打摘要或者哈希就行。审计日志的落地方式看项目规模。小项目直接console.info输出到系统日志配合 hilog 过滤中大型项目建议写到本地文件或者上报到服务端方便事后追溯。日志的保留周期和合规要求有关这个要按项目所在的具体规范来定我不展开。6. 长时任务申请、维持与释放的完整闭环6.1 backgroundTaskType 的选择依据长时任务类型的选择直接决定了服务能跑多久、会不会被冻结。常见的类型和适用场景对应关系如下任务类型适用场景注意事项dataTransfer文件上传下载、数据同步传输结束要及时释放否则常驻通知一直挂着audioPlayback后台音频播放需要配合音频焦点管理避免和其他应用抢焦点audioRecording后台录音涉及隐私用户感知要明确location后台定位上报定位精度和频率影响功耗要按需降频bluetoothInteraction蓝牙设备交互设备断开后要及时释放选型的原则是用最窄的类型满足需求。比如你只是偶尔上报一次位置就不要申请 location 长时任务用一次性的定位请求就够了。长时任务的常驻通知对用户是打扰滥用会影响应用评分。6.2 startBackgroundRunning 的调用时机申请长时任务的 API 是backgroundTaskManager.startBackgroundRunning调用时机很关键。必须在服务真正开始执行长时逻辑之前调用不能等逻辑跑起来了再补申请因为补申请之前的这段时间进程可能已经被冻结了。调用时需要传入 context、任务类型和一个 WantAgent用于点击常驻通知时跳转回应用。WantAgent 的构造有点繁琐但必须传否则申请会失败。我一般封装一个工具方法把 WantAgent 的构造和 startBackgroundRunning 的调用包在一起业务代码里一行调用搞定。申请成功后要保存返回的 notificationId释放时要用。释放的 API 是stopBackgroundRunning传入 context 即可。释放时机是长时逻辑结束时比如传输完成、录音停止。忘记释放的后果是常驻通知一直挂着用户会以为应用在偷偷跑后台体验极差。6.3 常驻通知的合规要求常驻通知的内容有规范要求不能随便写。通知标题和内容要如实描述当前正在进行的任务不能含糊其辞或者误导用户。比如做数据传输的通知里要明确写正在传输数据不能写成正在优化体验这种模糊表述。通知的点击行为也要合理一般跳转到应用内对应的任务管理页面让用户能看到任务进度、能主动停止。如果用户点了停止应用要响应这个操作真正把长时任务停掉不能点了没反应。这是基本的诚信问题也是系统审核会关注的点。7. 调试与问题排查那些文档里不会写的事7.1 服务拉不起来的三层排查法服务拉不起来是最常见的问题我总结了一个三层排查法按顺序走基本能定位。第一层查配置。确认 module.json5 里 extensionAbilities 的配置项齐全type是servicesrcEntry路径正确类名和name一致。这一层的问题最容易被忽略因为编译不一定报错但运行时就是找不到。第二层查权限。如果exported是 true 且配了permissions确认调用方持有对应权限。权限没授予的话拉起会失败但错误码不一定直观。可以在调用方的onFailed回调里打日志看具体错误码再对照文档查含义。第三层查进程状态。如果服务之前被拉起过又被回收了再次拉起时可能因为残留状态导致失败。这种情况重启设备或者清理应用数据后重试如果能成功说明是状态残留问题要在onDestroy里做好清理。7.2 IPC 请求无响应的定位思路IPC 请求发出去没回应可能的原因有好几种。先确认服务端的onRemoteMessageRequest有没有被调用打日志看。如果没被调用说明请求没到达服务端检查连接是否还活着、业务码是否匹配。如果被调用了但调用方没收到回复检查reply有没有正确写入、有没有调用reclaim。还有一种隐蔽的情况是onRemoteMessageRequest里抛了异常但没被捕获导致整个请求处理中断调用方一直等。所以服务端的请求处理逻辑一定要包 try-catch异常时也要给调用方回一个错误码不能静默吞掉。7.3 后台被冻结的确认方法怀疑服务被冻结了最直接的确认方法是看日志时间戳。在服务里起一个周期性打日志的定时器应用切后台后观察日志是否还在按周期输出。如果日志停了基本就是被冻结了。这时候检查长时任务有没有申请成功startBackgroundRunning的返回值是不是成功常驻通知有没有出现。另一个方法是看系统的任务管理界面有些设备的管理界面能看到应用的后台任务状态。不同设备厂商的实现不一样这个只能作为辅助判断。8. 几个真实场景的实现要点8.1 后台数据同步服务的骨架后台数据同步是 ServiceExtensionAbility 最典型的用法。骨架大致是这样onCreate里初始化数据库和网络客户端onRequest里触发一次同步任务同步任务丢到 TaskPool 里执行执行前申请 dataTransfer 长时任务执行完释放。同步过程中通过 EventHub 或者本地广播通知 UI 层进度。这里的关键是同步任务的幂等性。因为服务可能被重复拉起onRequest可能被调多次同步逻辑必须能识别这次请求是不是已经在处理了避免重复同步。我一般用一个内存标志位加持久化的任务 ID 来做去重标志位在onCreate里重置任务 ID 落库。8.2 设备状态监听服务的连接管理设备状态监听服务通常用 connectAbility 模式因为调用方需要持续接收状态变化。服务端在onConnect里返回 RemoteObject同时把调用方的 RemoteObject 存下来状态变化时主动回调调用方。这里要注意连接的生命周期管理onDisconnect里要把对应的调用方从列表里移除避免向已断开的连接发消息。多调用方并发连接时服务端要维护一个连接列表每个连接对应一个调用方标识。状态变化时遍历列表逐个回调某个回调失败不影响其他回调。这个列表的并发访问要加锁因为onConnect、onDisconnect和状态变化回调可能在不同线程上执行。8.3 跨应用服务调用的版本兼容跨应用调用最头疼的是版本兼容。调用方和服务方可能不是同一个版本业务码、参数格式、返回格式都可能不一致。我的做法是在连接建立后先做一次握手交换双方的协议版本号版本不匹配时降级到兼容模式或者直接拒绝。握手协议的设计要简单一个版本号加一个能力位图就够了。能力位图表示服务端支持哪些业务码调用方根据位图决定发哪些请求。这样新版本服务端可以兼容老版本调用方老版本服务端也能让新调用方知道哪些能力不可用。9. 性能与资源别让后台服务变成电老虎9.1 线程模型的选择ServiceExtensionAbility 本身不提供线程所有回调都在系统分配的线程上执行。耗时逻辑必须自己开线程或者用 TaskPool。我的选择是短小的计算用 TaskPool长时的 IO 用独立的 Worker 或者线程。TaskPool 的好处是系统帮你管理线程池不用自己操心生命周期缺点是任务粒度要控制好太长的任务会占用线程池资源。IPC 请求处理里绝对不要做同步 IO哪怕是小文件读写。IPC 线程池的线程数有限同步 IO 会阻塞线程请求一多就排队。所有 IO 都异步化这是底线。9.2 内存占用的控制后台服务的内存占用要格外克制因为系统对后台进程的内存阈值比前台低。几个控制手段数据库查询分页不要一次 load 全表大文件流式处理不要整个读进内存缓存设上限LRU 淘汰及时释放不再使用的对象引用尤其是监听器和回调。我遇到过一次内存问题原因是服务里缓存了所有历史同步记录用于去重数据量大了之后内存暴涨。后来改成只缓存最近 N 条加一个布隆过滤器内存降了一个数量级去重效果基本没损失。9.3 功耗优化的实际手段后台服务的功耗主要来自网络请求、定位、传感器和定时器。优化手段对应着来网络请求合并批量发送减少唤醒次数定位按需降频精度够用就行传感器监听用完就注销定时器用系统的统一调度接口不要自己起 setInterval 硬轮询。定时器这块特别说一下。自己起 setInterval 做周期任务在后台被冻结时定时器会停解冻后可能一次性补发多个回调导致逻辑错乱。用系统的后台任务调度接口由系统统一管理触发时机行为可预期得多。10. 我踩过的几个坑和对应的解法第一个坑是onConnect返回的 RemoteObject 被重复创建。早期我在onConnect里每次都 new 一个 RemoteObject结果调用方拿到的 descriptor 不一致校验失败。后来改成在类成员里初始化一次onConnect里直接返回同一个实例问题解决。RemoteObject 应该是单例的一个服务对应一个 stub。第二个坑是长时任务申请了没释放常驻通知挂了两天。原因是释放逻辑写在了一个可能不执行的分支里异常路径没覆盖到。后来把释放逻辑放到onDestroy里兜底同时在业务结束的正常路径上也调一次双保险。第三个坑是 IPC 的 MessageSequence 泄漏。前面提过压力测试时内存涨定位到是 reply 没 reclaim。后来封装了一个工具方法用 try-finally 保证 reclaim 一定执行再没出过问题。第四个坑是服务被冻结后状态丢失。服务里维护了一个内存中的任务队列冻结再解冻后队列空了任务丢了。后来把队列持久化到数据库服务启动时从数据库恢复内存只做缓存问题解决。第五个坑是跨应用调用的权限校验漏了二次校验。配置里配了 permissions以为万事大吉结果安全测试时发现连接建立后可以发任意请求。补了onRemoteMessageRequest里的调用方身份校验才通过。这些坑的共同点是文档里不会明说但实际项目里几乎一定会遇到。我的建议是ServiceExtensionAbility 相关的代码初始化、释放、异常处理这三块要写得比业务逻辑还仔细因为后台服务的运行环境比前台复杂得多容错空间小。最后分享一个调试小技巧在服务的关键回调里统一打一条带时间戳和线程 ID 的日志用 hilog 的 domain 过滤。服务出问题时先看日志的时间戳分布能快速判断是没被拉起、被冻结还是逻辑卡住。这个习惯帮我省了大量排查时间比盲目加断点高效得多。
