苹果和谷歌正在对推送通知做些什么？

推送作为电池问题

推送最初是一个电池问题。2009年6月，Scott Forstall在WWDC上提出，iPhone无法让每个已安装的应用都维持自己的后台轮询。经过延迟（原定2008年9月宣布，但苹果决定重构底层基础设施以扩展规模），苹果推送通知服务（APNs）诞生了——每个设备到苹果的一条持久TLS连接，任何注册的第三方都可以通过它发送提醒。APNs于2009年6月17日随iPhone OS 3一起发布。谷歌在2010年推出了Cloud to Device Messaging，然后是2012年的Google Cloud Messaging，再到2016年的Firebase Cloud Messaging。

这个通道从一开始就是中介化的。你发送给iPhone的每条通知都经过苹果的服务器；发送给Android手机的每条通知都经过谷歌的服务器。平台一直能够限流、丢弃、记录、降低优先级或拒绝。在通道历史的大部分时间里，它们很少明显这样做。架构允许干预，但它们选择不干预太多。这种克制已经结束了。

十五年的平台干预

2009年至2017年的早期消费者推送时代相对平静。APNs和各种谷歌服务将通知传递给用户已安装的应用，平台级过滤有限，用户控制仅限于每个应用的简单开关。Android的第一次重大设备端干预是Android 8 Oreo（2017年8月）中的通知渠道。在Android 8之前，单个通知携带发送者决定的优先级。Android 8之后，这个控制权首先传递给开发者（在渠道层面），然后传递给用户（在渠道层面）。开发者为每个应用声明少量渠道（如下载、消息、推广等），每个渠道有一个重要性值（从IMPORTANCE_NONE到IMPORTANCE_HIGH）；用户随后可以独立地静音、降级、禁用角标或完全阻止任何渠道，而不影响其他渠道。一旦开发者设置了渠道的重要性，以后就不能再提高。任何针对Android 8的应用都必须声明渠道，否则通知根本不会显示。

苹果在2021年9月的iOS 15中引入了自己的版本，使用了不同的术语。专注模式、定时摘要和新的四级中断分类（被动、主动、时效敏感、关键）重构了iOS处理每次推送的方式。时效敏感是你唯一能够有意义地使用的等级，而且苹果当时和现在都明确表示，你不应该将其用于营销。

Android在2022年8月将权限本身作为杠杆，当时Android 13将POST_NOTIFICATIONS变成了运行时权限，需要用户明确授予，而不是自平台发布以来一直使用的隐式选择加入。选择加入率可预见地下降了：Pushwoosh的1600万设备样本显示，游戏应用失去了近三分之一的选择加入用户，新闻应用下降了19%。Batch的2025年基准测试基于10000个应用的8000亿条消息，报告称Android选择加入率在一年内从85%下降到67%，跨平台平均稳定在61%。

每一步都减少了发送者的控制程度。其中一部分转移给了用户，这是一件好事：一个人决定允许什么打断自己，这才是通道应有的工作方式。其余部分转移给了平台，这才是发送者应该担心的部分，因为平台的判断是不透明的、不可上诉的，并且越来越多地由模型而非用户选择的设置做出。十五年来，这个通道已经围绕一个假设重建：接收者的注意力是一种稀缺资源，平台有义务保护它。平台既为了用户也为了自身原因保护这一资源。一个干净、低疲劳的通知表面保护了平台的留存率和生态系统，降低了卸载率，并展示了其AI能力，因此编辑是平台在保护其拥有的资产，而非纯粹的用户倡导。作为发送者，无论控制权如何转移，你都站在了这个假设的错误一边。

邮件率先做到的事

邮件的进程更远，我已经完整讲述过那个故事。同样的中介化一直在推送领域并行发展，只是晚了几年，这使得邮件成为推送未来走向的可靠预演。不过推送的情况更难：邮件至少给发送者提供了一些工具来查看其运作（如Postmaster工具和投递仪表板），而推送几乎没有提供任何工具。也没有与收件箱等同的推送概念：邮件会持续存在于一个收件人可以回滚浏览、搜索和返回的地方，而通知只存在于通知中心，它会清除、丢弃和摘要经过的内容，并且不可靠地保留任何东西。

机器学习自20世纪90年代末就开始决定收件箱位置，当时贝叶斯垃圾邮件过滤使提供商从基于规则的过滤器转向权衡内容、发送者声誉和接收者参与度的分类器；身份验证标准（SPF、DKIM、DMARC）后来作为信号层叠在这些模型之上，而非替代它们。营销人员慢慢学会将邮件视为一个请求，而非发布行为，这个请求由隐藏的分类器批准或拒绝。2013年Gmail的标签式收件箱使用相同的分类器将合法邮件分为主要、推广、社交和更新。推广标签不是垃圾邮件文件夹，而是用户同意接收但模型判断为推广的商业邮件的单独类别；苹果邮件在2024年添加了自己的分类。

每项举措都将发送者意图和用户体验之间的界线向远离发送者的方向推了一步。2021年9月在iOS 15中推出的邮件隐私保护是可见性打击。苹果邮件开始通过苹果控制的代理预取远程内容，无论用户是否打开邮件，都会屏蔽IP地址并破坏营销人员依赖了十年的打开像素机制。供应商Omeda观察到，仅因这些预取而非实际阅读，苹果驱动的打开率在六个月内从22.6%攀升至40.5%。旧的打开率形式变得不可恢复，点击率和后续转化成为参与度信号。

然后雅虎和谷歌让投递本身变成了门槛。从2024年初开始，任何向个人收件箱推送较大体量的发送者都必须使用SPF和DKIM进行身份验证、对齐DMARC、提供一键退订并将垃圾投诉率保持在低水平，否则根本抵达不了收件箱；谷歌在2025年11月从延迟转向直接拒绝，微软也发布了等效规则。苹果智能摘要于2024年10月到达邮件，Gmail的Gemini摘要也随之而来。

推送现在大致达到了邮件十年前达到的中介化成熟度，但在机制上有一些对你不利的差异。邮件运行在开放、联邦的协议（SMTP、IMAP以及DKIM和DMARC标准）上，任何人都可以实现；读取客户端与提供商解耦，因此收件人可以在任何应用中打开同一个邮箱；订阅只是你（发送者）持有的列表中的一个地址。推送完全没有这些。用户的权限存在于特定设备的特定安装中（原生应用，或自iOS 16.4起的主屏幕Web应用），与苹果或谷歌可以随意失效的令牌（APNs或FCM）绑定，你不持有任何可以带到别处的列表。Web推送扩大了谁可以发送的范围，无需App Store下载，但通知仍然落在同一个托盘、接受相同的设备端编辑，因此它拓宽了通道，但没有逃脱编辑器。

邮件有DKIM签名，接收邮箱可以检查；推送没有类似物，因为每条通知都已经由苹果或谷歌的基础设施签名，作为被投递的条件。邮件通过HTML提供布局控制；推送只提供一个小型结构化负载，对于折叠的锁屏视图几乎没有超出平台模板的控制。你可以为展开视图提供更丰富的自定义布局（iOS上的内容扩展，Android上的自定义布局），但它只在用户下拉通知时渲染，而摘要器处理的折叠文本仍然受模板约束。邮件存在于用户主动打开的队列中；推送则是打断。

在邮件中，打开率的死亡本应教会营销人员打开一直意味着什么：最好也只是投递的代理，从来不是参与度的指标。许多人从未学会，至今仍将打开视为参与度。推送正朝着同样的方向发展。你正在失去判断自己的通知是否被摘要、隐藏在专注模式后面、被设备端模型降低优先级或放入安静文件夹的能力。

设备端编辑器

邮件的编辑主要发生在传输过程中。Gmail的推广分类器、垃圾邮件过滤器、发送者声誉系统和批量发送者策略执行都在提供商的服务器上运行，在负载通过时读取它。推送的编辑则发生在所有这些之后。传输是接力，在Web推送的情况下是端到端加密的，而关于通知是否显示、摘要、降低优先级或分组的决定是由设备在显示层做出的。设备端模型是关键，而非网络，其权重和信号不公开。

苹果智能运行在一个30亿参数的设备端基础语言模型和一个通过私有云计算可用的更大的并行追踪混合专家服务器模型上。设备端模型使用KV缓存共享和2位量化感知训练以适应苹果的芯片；2025年7月发布的技术报告详细描述了架构。2024年7月的一份早期报告阐述了摘要适配器本身的训练方式：在邮件、消息和通知负载的数据混合上训练，目标摘要由更大的服务器模型合成生成，然后过滤。该模型并非直接用于每个苹果智能功能。小的LoRA风格适配器（通常几十兆字节）由操作系统动态加载，将基础模型专门用于特定任务：摘要、实体提取、润色、通知优先级排序等。苹果在2024年末和2025年初的新闻摘要问题可以逐个功能解决，因为基础模型无需更换；某个表面的适配器可以重新训练或关闭。在BBC抱怨摘要生成虚假标题后，苹果在iOS 18.3中禁用了新闻和娱乐的摘要，开始以斜体显示AI摘要，在锁屏上添加了每个应用的开关，并开始警告摘要可能包含错误。

编辑既不在于网络，也不在于用户设置，而在于一个持续演变的、不透明的设备端模型。