ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

App 明明没打开,为什么还能收到消息?

App 明明没打开,为什么还能收到消息? 第四生产力 · 程序员眼里的世界App 明明没打开消息却照样弹出来。很多人的第一反应是它是不是一直在后台偷偷运行有这种可能但仅凭一条通知还不能下这个判断。因为接收消息的未必是这个 App 自己。要解释这件事先得分清App 的页面、手机系统和远端服务器各自负责什么。页面关了哪一部分还在工作以外卖配送提醒为例。下面只用它说明机制不代表某款产品的具体实现。你下单时订单交给了远端的业务系统。以后商家接单、配送状态变化都可以先记录在那里。你回到桌面关闭的是眼前的页面并没有顺便关掉处理订单的服务器。但这只解释了一半服务器知道订单变了手机又是怎么知道的一种办法是让 App 在后台维持连接随时等消息。这种做法确实存在。所以“没看见页面”也不能直接证明应用的所有代码都停止了。不过收到提醒并不一定依赖这款 App 一直运行。手机可以把接收推送的工作交给系统或平台服务等消息到了再按规则处理。苹果的通知权限文档就明确说明通知可以在应用未运行或处于后台时通过提示、声音、图标角标吸引用户注意。于是判断要更谨慎一点看到一条通知不能单凭这一点认定 App 的主程序一直在后台忙。谁替 App 接到了那条消息手机操作系统本身就要管理联网、通知和应用状态。平台提供的推送通道可以接收来自云端的消息再把它交到适当的位置。苹果设备使用苹果的推送服务叫 APNs。具有相应 Google 服务的 Android 设备可以使用 Google 的消息服务 FCM。国内也有厂商提供自己的推送通道。例如华为对推送服务的机制说明中提到利用系统持续的连接在应用进程不运行时推送消息。这是相应平台的能力不能据此保证每台手机、每款 App 都走同一条路。把常见的可见通知简化一下业务服务器把“订单状态有更新”交给推送平台平台把通知送到手机手机根据权限和展示规则把提示放到通知栏或锁屏上。显示一句提醒不要求订单页面此刻也打开。Google 的Android 接收文档也把这两件事分开应用在后台时通知型消息可以进入系统通知区另外一些消息则需要应用代码处理。这不是说应用绝不参与。不同消息可能触发不同处理通知扩展也可能参与加工。这里只需要记住显示通知与把整个 App 持续打开是两种不同的工作。这么多手机怎么知道该发给你推送平台当然不能把你的配送提醒广播给所有人。应用要先完成登记取得一个用于投递的标识再把它交给自己的业务服务器。之后服务器发送通知时带上这个标识平台才知道投递给哪个设备上的哪个应用。可以把它大致理解成一份“投递地址”。但它不是你的手机号也不是永远不变的身份证。苹果的APNs 注册说明明确区分了设备与应用同一台手机上的不同 App不能直接共用同一个设备令牌这个令牌也可能变化。所以“我今天没打开它”与“它从来没有登记过”是两回事。你之前使用 App 时相关登记就可能已经完成。这个地址也不等于通知权限。地址解决“送给谁”权限解决“允许怎样提醒你”。平台还要求发送方具备相应认证和配置并不是知道一个地址就能随便投递。顺着图看配送变化先发生在业务端提醒沿推送通道来到手机系统在规则允许时展示。你点击之后App 才可能打开订单页并向业务服务器获取详情。这张图画的是一种常见路径不是所有通知的完整实现。提示里可以带一部分信息但订单详情未必都装在那一条提醒里。为什么不让每个 App 都自己等消息假如每款 App 都独自保持连接、检查新消息手机就需要反复为这些后台工作使用网络和计算资源。集中接收的价值是把一部分重复的等待工作合起来。Android 官方的省电机制说明写得很直接FCM 提供共享的持久连接需要实时消息的应用可以共用减少各自维持单独连接的需要。这里的“持久连接”就是不必为每条消息都从头建立联系通道在适当条件下保持可用。手机仍然要联网也仍然要消耗资源共享通道并不意味着推送完全不耗电。我觉得值得记住的是这个取舍每款 App 都希望自己的消息及时到达系统则要兼顾整台手机的电量、网络和你的注意力。推送服务是在协调这些需求。它也没有给每款 App 一张“随时随地运行”的通行证。有通道为什么有时还是迟到因为一条消息“发出去了”可以指不同的事情。业务服务器提交了请求推送平台接受了请求消息送到手机系统显示了提醒你注意到并读完——这些步骤不能合成一个状态。FCM 的消息有效期说明就明确提醒拿到消息编号表示平台接受了投递请求不表示手机已经收到。手机没有连上通道时消息可能暂存等恢复连接再投递也可能因为过期而被丢弃。部分提醒可以合并成更新的一条不保证原样补发全部历史消息。手机能联网也不代表每条后台消息都立即处理。省电机制可能延后一些工作应用代码需要更新内容时还会受到后台执行规则约束。苹果也明确说明用于后台更新的通知不保证送达。还有一种情况消息已经到设备但系统按你的设置没有响铃、没有在锁屏显示或延后提醒。所以我更愿意把三个问题分开查消息有没有送到通知有没有展示人有没有看到。只盯着“服务器说成功了”很难知道问题卡在哪里。那我把它划掉为什么还不安静返回桌面、划掉最近任务中的卡片、在设置里强制停止、关闭通知权限并不是同一个操作。返回桌面主要改变你正在看的页面。划掉卡片会怎样影响应用取决于系统和厂商策略不能统一理解成“从此拒收它的提醒”。设置里的强制停止则是更强的状态变化。以 Google 的FCM 接收说明为例Android 用户在设备设置中强制停止应用后需要重新打开应用消息接收才会恢复。同一文档对 iOS 也有退出后的限制但限定的是后台消息不能扩大成“所有可见通知都会停止”。讨论“关掉 App”时把具体操作和消息类型说清楚答案才不会互相矛盾。如果你的目的只是减少打扰更直接的入口通常是通知设置。Android 13 及以上对普通非豁免通知设置了权限控制。iPhone 也可以调整通知位置、声音、锁屏预览和提醒时间。具体入口和名称随系统、机型而异。你可能想保留配送更新却不想收促销如果 App 提供分类订阅可以在应用内区分。没有这样的选项就需要在保留业务提醒与减少整体打扰之间做取舍。如果担心旁人看到锁屏上的内容可以限制预览。通知仍可能到达但敏感文字不必直接展示出来。不过关闭通知并不等于让服务器停止处理订单也不等于让应用从此断网。反过来能收到通知也不足以证明它在监听你。要判断数据访问还要查相关权限和实际行为。本文讲的是从服务器送来的远程通知。日历等工具还可以提前登记本地提醒不需要每次等服务器来发消息不能把手机上的所有提醒都套进同一条链。下次别只盯着“它开没开”回到那份外卖页面退出了业务服务器还在处理订单手机的接收通道也可能仍然可用。配送提醒到来时系统可以先把消息展示给你不必等你一直守着订单页面。手机里的一款 App看上去只是一个图标背后却可能有几个分别运行的参与者。把它们分开很多现象就容易理解了页面没开仍能提醒提醒出现后详情还要加载清掉卡片也未必能阻止下一条通知。下次有一款 App 总让你分心可以先打开它的通知设置决定哪些消息值得保留、哪些内容不该出现在锁屏上。与其反复猜它有没有“偷偷开着”先控制你真正想改变的那一环。——第四生产力 · 程序员眼里的世界—— 第四生产力 ——专注企业级 AI 工程实践RAGAgent推理优化集群调优从模型能力到业务价值的最后一公里。
返回列表