我是消息应用APP《MeoW》的开发者方程。最初做这款应用，并不是想做一个复杂的信息聚合平台，而是想围绕 HarmonyOS 的一个核心系统能力，做一款足够轻、足够清晰，也足够有辨识度的小应用。这个能力，就是华为统一 Push 推送服务，也就是 Push Kit。

在 HarmonyOS NEXT 刚开始公测的时候，我注意到一个很重要的变化：统一推送是 HarmonyOS 能够和传统移动应用体验拉开差距的关键能力之一。过去在移动端，很多应用为了保证通知及时送达，需要后台保活、轮询或者长连接。但这些方式要么耗电，要么不够及时，要么会占用更多系统资源。统一推送则把这件事交给系统级通道完成，即使应用不在后台运行，用户也可以收到通知。当时应用市场里还没有一款应用专门把统一推送能力作为核心卖点来展示，于是就有了 MeoW 的最初想法：做一款能够让大家直观感受到 HarmonyOS Push Kit 能力的 App。

MeoW 的产品演进过程：从提醒自己，到提醒更多人

MeoW 的产品思路不是一开始就完整规划出来的，而是逐步演进出来的。

最早，它只是我自己的一个小工具。那时我需要训练大模型，希望模型训练完成后能及时收到提醒，于是做了一个通知自己的工具。后来，我把它用来通知一部分喜欢尝鲜的华为用户，比如应用更新、系统更新或者一些他们关心的内容。这个阶段，MeoW 的“被通知方”开始扩大。

MeoW生态动态页面示意图

再往后，我又想，既然被通知方可以扩大，通知方是否也可以扩大？于是，MeoW 有了“个人频道”的概念。其他用户也可以创建自己的频道，把消息推送给有相同兴趣的人。这样，MeoW 就从一个只服务我自己的提醒工具，逐渐变成了一个轻量的通知平台。

在我看来，“频道”不是简单的信息分类，而是一个志同道合的兴趣集合。用户只订阅自己真正关心的频道，就不会被无关通知频繁打扰。MeoW 从一开始设计频道概念时，就把“避免打扰用户”放在了很重要的位置。

MeoW个人频道界面示意图1

MeoW个人频道界面示意图2

Push Kit 统一推送开发接入经验与要点

MeoW 想解决的核心问题，可以用一句话概括：不用刷新，不用等待。来了，我就提醒你。

以往消息提醒类需求常见做法有三种：后台保活、定时轮询、长连接。但是后台保活的难点是一旦 App 被系统杀掉，通知就可能收不到；轮询方法存在耗电和及时性不稳定；长连接则更占系统资源。Push Kit 的系统级通道解决了这个问题，它更省电，也不用担心因为 App 不在后台而错过通知。

从技术链路上看，一条 MeoW 通知的流转过程很清晰：外部事件先到达 MeoW 服务器，再到达华为服务器，最后到达用户设备。MeoW 不需要让 App 长期占用后台资源，而是借助 HarmonyOS 的系统级推送能力，把通知送到用户面前。

MeoW应用更新通知示意图

MeoW系统更新通知示意图

除了普通用户订阅频道，MeoW 还有自定义 HTTP 接口。这个功能最初就是为开发者和程序员设计的，因为任何编程语言基本都可以调用 HTTP，所以它很适合接入各种自动化场景，比如任务完成提醒、服务器监控告警、脚本执行结果、CI/CD 状态通知等。例如我最早就是用 MeoW 来做提醒模型训练完成的提醒功能。另外，MeoW 后端在设计时，会同时考虑易用性和安全性，尽量让用户能够简单接入，同时降低安全风险。

MeoW自定义通知示意图

在开发过程中，Push Kit 的接入本身并没有特别复杂，尤其现在有了 AI 工具，很多代码层面的工作都可以被辅助完成。如果说有什么需要特别注意，我认为一个是证书配置，另一个是推送规范。开发者在接入 Push Kit 时，要注意消息内容和申请的自分类权益、分类规则保持一致，并遵守《华为推送服务使用协议》和相关规范。如果推送并发量比较高，也要注意不要超过当前账号允许的 QPS，必要时需要设计重试机制。

这就是我对 MeoW 的理解：它不是一个功能很重的平台，而是一款边界清晰的轻量通知工具。边界越清晰，别人越能记住你；同类应用想要进入并打破这种壁垒，也会越难。