推送通知：一个功能下的冰山

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

这只是路线图上的一个单行条目。“当 X 事件发生时发送推送通知。”预估工作量为两天，如果后端尚未配置 Firebase 云消息传递（FCM）凭证，则为三天。现成库可以处理此事。

库只是冰山一角。其余 90% 的工作涉及平台生命周期、注册状态机、与导航的竞争条件、载荷数据结构解析，以及 iOS 和 Android 上的各种细微差异。没人把这些写下来。你只有在产品发布后，随着错误报告纷至沓来，才会逐渐了解它们。

我构建这套技术栈时使用了自定义原生模块，直接在 iOS 上封装苹果推送通知服务（APNs），在 Android 上封装 FCM，而不是选用 Notifee、React Native Firebase 或 OneSignal。这种权衡显而易见。我放弃了库提供的抽象层，换来了对每个边界情况的完全控制。这一决定并非出于意识形态考量。我所关注的那些故障模式，在这些库的问题追踪系统中早已存在，却迟迟未获修复。

本文探讨的是表象之下的内容。不是你导入的那个库，而是库试图向你隐藏（或正在隐藏）的实际工作。

分水岭：注册是一个状态机，而非一次函数调用

教程中的版本只有一行代码：

const token = await messaging().getToken()
sendToBackend(token)

实际发生的情况是操作系统、你的应用程序和推送服务提供商之间进行了几轮往返通信。至少有三个地方可能导致其在静默中失效。

在 iOS 上，注册过程分散在多个代理方法中。令牌以 NSData 形式返回，而非字符串，你需要对其进行十六进制编码，然后才能让 AppDelegate 之外的任何部分访问它：

- (void)application:(UIApplication *)application
didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
  const unsigned char *bytes = deviceToken.bytes;
  NSMutableString *hex = [NSMutableString stringWithCapacity:(deviceToken.length * 2)];
  for (NSUInteger i = 0; i < deviceToken.length; ++i) {
    [hex appendFormat
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。