第41篇｜推送通知库适配 HarmonyOS：Token 管理、通知权限和消息去重

第41篇｜推送通知库适配 HarmonyOS：Token 管理、通知权限和消息去重

图 1：推送通知库适配封面图，用来概括本文主题、适配对象和工程边界。

实际项目里，推送通知库适配经常不是“引入依赖就能用”的问题。真正麻烦的是输入来源、平台能力、生命周期、异常处理和发布说明没有被写清楚。前期省掉这些边界，后面一升级库版本或换设备，就会变成全链路排查。

本文围绕推送消息和消息去重展开，目标是把三方库从“能跑一次”整理成“能被业务稳定接入”。读者可以按文中的源码地图、配置入口、封装层、示例页和验收清单，把自己的工程逐项替换进去。

图 2：推送通知库适配流程图，用来说明从选型、接入、封装到验收的主要步骤。

图 3：推送通知库适配结构图，用来说明页面、服务、Native 或三方库之间的职责边界。

1. 推送通知库适配先从真实失败场景切入

推送通知库适配的适配风险通常出现在运行阶段，而不是写依赖声明时。比如输入为空、资源路径变化、页面销毁后仍有回调、Native 层返回错误码但 ArkTS 层没有转换，这些问题在 Demo 阶段不处理，上线后会被放大。

本文的处理原则是：页面只管理状态，服务层只暴露业务语义，三方库细节收敛在 Adapter 或 Native 包装层。这样后续替换库、升级版本或调整实现时，不需要让整个页面跟着改。

2. 推送通知库适配的源码地图和职责边界

先把文件位置列出来，能减少一半无效排查。读者不需要完全照搬目录，但应该保留同样的边界：配置入口、封装层、页面示例和验收逻辑分开。

3. 推送通知库适配的版本和环境边界

三方库适配不能只写“当前能运行”。更稳的写法是把验证环境写清楚，让读者知道失败时先比较哪一层。

4. 推送通知库适配的工程入口配置

配置入口要尽量少而清楚。ArkTS 类库优先固定包版本；Native 类库要固定源码路径、include 目录和链接顺序；涉及权限或资源的库，还要在模块配置里写明依赖的系统能力。

{ "name": "push-notice-demo", "version": "1.0.0", "dependencies": { "@demo/push-notice": "1.0.0" }, "devDependencies": {} }

这段配置表达的是依赖入口，不承担业务逻辑。真实工程里可以换成 ohpm 包、源码模块或 Native 产物，但不要让页面直接维护版本和路径。

5. 推送通知库适配的适配层代码

适配层要先处理输入，再调用三方能力。这里用PushNoticeAdapter表达边界：它接收推送消息，执行消息去重，最后返回业务层能理解的结果。

exportinterfacePushNoticeServiceResult{ok:boolean;message:string;messageId:number;}exportclassPushNoticeAdapter{normalize(raw:string):string{constvalue=raw.trim();if(value.length===0){thrownewError('推送消息不能为空');}returnvalue;}run(raw:string):PushNoticeServiceResult{constvalue=this.normalize(raw);return{ok:true,message:'消息去重完成: '+value,messageId:value.length};}}

这段代码不追求复杂，而是把边界写清楚：输入必须先归一化，异常必须在适配层变成明确错误，返回值必须是业务结构，不能把三方库原始对象直接透给页面。

6. 推送通知库适配的服务层封装

服务层负责把适配结果转成业务可用的状态。它可以追加缓存、重试、权限判断或日志脱敏，但不应该重新理解三方库内部细节。

import{PushNoticeAdapter,PushNoticeServiceResult}from'../adapter/PushNoticeAdapter';exportclassPushNoticeService{privateadapter=newPushNoticeAdapter();execute(raw:string):PushNoticeServiceResult{try{returnthis.adapter.run(raw);}catch(err){return{ok:false,message:(errasError).message,messageId:0};}}}

服务层的价值是稳定接口。以后底层从 ArkTS 包换成 Native 模块，或者从一个开源库换成另一个库，只要服务层方法不变，业务页面就不用感知替换过程。

7. 推送通知库适配的页面验收入口

示例页不只是展示效果，它也是升级三方库后的回归入口。每次调整版本、改构建参数或换设备，都可以先跑这个页面。

import{PushNoticeService}from'../service/PushNoticeService';@Entry@Componentstruct PushNoticeServicePage{@Stateinput:string='push-notice-sample';@Stateoutput:string='等待运行';privateservice:PushNoticeService=newPushNoticeService();build(){Column({space:12}){TextInput({text:this.input,placeholder:'输入推送消息'}).onChange((value:string)=>this.input=value)Button('运行消息去重').onClick(()=>{constresult=this.service.execute(this.input);this.output=`${result.ok}/${result.message}`;})Text(this.output).fontSize(14)}.padding(20)}}

页面只关心三件事：输入、触发、展示。底层的权限、构建、二进制产物、异常码都不应该泄露到这里，否则页面会越来越难维护。

8. Native 或底层能力怎么接

如果这类库涉及 Native 能力，可以在 C++ 层做一次更薄的包装。包装层不要塞业务规则，只处理参数、调用registerToken、转换返回值和释放资源。

#include<string>structNativeRunResult{boolok;intvalue;std::string message;};NativeRunResultRunNativePushNoticeService(conststd::string&input){if(input.empty()){return{false,0,"empty input"};}intnativeValue=static_cast<int>(input.size());return{true,nativeValue,"registerToken finished"};}

这段 Native 示例强调的是包装边界。真实接入时要把三方库头文件、错误码、内存释放规则补进去，但 ArkTS 侧仍然只接收结构化结果。

9. 推送通知库适配的命令行验证

命令行验证要服务于排查。包管理类库看依赖树，Native 类库看产物架构和符号，媒体或设备能力类库还要看真机日志和权限结果。

ohpm list--allhvigorw--modemodule-pmodule=entry assembleHap hdc hilog|findstr push_notice

这些命令不保证替读者解决所有问题，但能把排查入口固定下来。先确认依赖和构建，再看运行日志，最后回到代码层处理输入和状态。

10. 推送通知库适配的常见问题排查

排查时不要一上来改页面。先看依赖入口是否稳定，再看适配层是否把错误收敛成可读结果，最后再判断是不是 UI 状态刷新问题。

11. 推送通知库适配的验收断言

验收断言可以放在 smoke 逻辑、单元用例或示例页按钮后面。它的作用是把“看起来能用”变成“结果结构满足预期”。

exportfunctionassertPushNoticeServiceResult(result:PushNoticeServiceResult):void{if(!result.ok){thrownewError(`推送通知库适配执行失败:${result.message}`);}if(result.messageId<=0){thrownewError(`messageId 不符合预期:${result.messageId}`);}}

这一层验收不替代完整测试，但能覆盖最核心的返回结构。文章发布或团队交接前，至少要保留一段这样的断言，方便读者确认自己迁移后的结果是否一致。

12. 推送通知库适配接入前的验收清单

• 依赖来源、版本和许可证已经记录。
• 配置入口集中，没有让页面直接维护三方库细节。
• 适配层已经处理空输入、异常输入和错误信息。
• 服务层返回业务结构，不透传三方库原始对象。
• 示例页可以在真机或模拟器上触发核心能力。
• 构建命令、日志入口和常见问题已经写清楚。
• 图片、流程和结构说明能帮助读者复现接入链路。

这份清单建议在每次升级三方库之后重新跑一遍。尤其是涉及 推送消息、消息去重、资源释放和页面状态的场景，不能只看构建是否成功，还要确认示例页、服务层返回结构、异常路径和日志信息都保持一致。只有这些条件同时满足，三方库才算真正进入可维护状态。

13. 小结

推送通知库适配的适配重点不是把某个库“搬进来”，而是把输入、配置、封装、运行和验收都写成可维护的链路。只要这条链路清楚，后续换库、升级版本、迁移设备能力或补充业务场景，都能有明确的修改位置。

参考资料

• OpenHarmony 三方库中心仓
• HarmonyOS 开发文档
• 推送通知库适配相关资料

参考资料用于核对版本、API 和平台能力，不建议只复制本文代码后直接进入业务分支。实际落地时，应先打开官方文档确认当前 SDK 行为，再结合三方库自己的 README、Issue 和 Release 记录判断是否存在已知限制。