为何谷歌不学中国厂商所统一推送服务？

[NokiaForever]

谷歌的 FCM 推送和华为推送、小米推送等不一样，是设备和谷歌 fcm 服务器 mtalk.google.com 维持一个长链接，服务端发消息给设备，设备广播拉起对应应用，然后由应用接收消息，故应用需要有自启动权限，后台不能使用“限制”模式，而是要使用“优化”，使应用进缓存。安卓的 fcm 是需要 app 在后台的没想到吧.完全关闭的情况下是收不到消息的.国产推送是有一个统一的推送服务在后台保活。
谷歌这做法不是让应用能自启动驻留后台，耗费电量吗？苹果、小米这些推送服务是完全不让应用能够自启动（如果需要就手动开启），就防止了应用耗费额外电量。
所以在国际上 Android 不费电不废内存可能是一种误解？

[icoming]

不是广播唤醒吗？为什么限制自启？为什么需要 APP 在后台？

[fuzzsh]

/t/970505
又来水帖


Android 上的 PayPal telegram whatsapp Instagram 基本是“单一”功能
而“安卓”上的支付宝 微信 微博则是“单一”系统


一个功能耗电在多
比不过
在 kernel 上跑 container 耗电

[chapiom]

维持但是只维持了一个，这比每个 app 在后台各搞一个好多了吧，国产那些推送各自为政，没见到几个 app 用了。

[NokiaForever]

@icoming 不限制，某些 app 就会常驻后台，限制了就没推送。

[huage]

最近我们小区要成立业委会，不少业主都不积极主动去投票，不团结的思想是自上而下灌输的。

[codehz]

有一个问题是隐私相关的：不唤醒就直接推送内容的模式下，推送方案提供方将会获得推送内容的全部访问权限，在一些隐私高度敏感的应用里是不切实际的。
我觉得还是果子的方案好，允许应用专门注册一个扩展，那个扩展只能用来处理推送信息，信息是单向流通，即 app 可以将解密密钥传递给扩展，扩展无法通过其他方式通知 app （然后就不可以唤醒了）

[iseki]

FCM 不需要每条消息都拉起应用吧，只有携带附加数据的，需要应用自己处理 notification 的才需要拉起来，但也就是拉起来处理一下而已。

[iseki]

至于从系统 UI 上干掉程序的情况，这似乎是个例外，它和 pkill 掉应用的进程是不一样的

[iseki]

@codehz 稍微搜了一下，苹果这似乎是把这个 "extension" 放进一个独立 bundle 里去了，不过我猜为了保证运行时的隔离应该还是独立的进程吧，这样是不是成本也不低？

[finab]

@iseki
我估计成本最多就是某个或某几个系统进程上一条最高 30 秒运行时间的 Task 。
否则哐哐哐收几百上千条推时进程开销也太大了，没必要

[mxalbert1996]

你肯定没开发过接入 FCM 的应用吧。
https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages
FCM 支持两种类型的消息，其中 Notification message 是如果应用不在前台的话是直接由系统处理，系统会直接显示通知，不需要应用启动。文档里说的是 in the background ，但事实上应用被关闭/杀死时也一样，你只要试一试就知道了。
你说的那种是需要应用自己处理的 Data message 。

[wang93wei]

在说什么？你看过 FCM 的开发文档没？

[lns103]

国际上的大部分安卓 app 不会有后台运行，强制保活的骚操作，很多通知是不需要应用处理的，直接 fcm 广播过去发出来，只有例如带通知栏回复功能的通知，才需要应用本地处理，国内定制 ROM 为了控制后台，直接进行了强制停止，导致广播发不过去，fcmfix 这样的模块能解决

[jacksonj297]

@fuzzsh Instagram 也支持短视频购物带货私信 IM 功能发朋友圈微信状态 story24 小时消失。telegram WhatsApp 支持支付。

[iseki]

@mxalbert1996 从 Sys UI 里强杀应该是收不到的，这个应该是 by design ，就是不清楚具体怎么实现的

[iseki]

@finab 也不好说，毕竟天天用的 ls 命令它也启个进程，只要够轻，那就不叫事，而且平均下几秒钟一条推都了不得了似乎。蹲一个 iOS 聚聚（

[wangxiaodong]

@NokiaForever app 常驻后台天经地义吧，既然安装了就属于产生了互信，你所谓的性能功耗是满足业务需求之外的特殊情况；近几年 google 把 android 的权限收缩的太过分了，严重阻碍技术创新！

[SenLief]

@chapiom 除了微信，大多数 app 现在都集成推送的，尤其是华为 push

[SenLief]

安卓 14 有新的墓碑机制吧，不必在意那点内存占用了，都 16g 起步，我现在都是全后台，能后台的坚决不杀死。我现在手机上推送就是 fcm 推送 tg ，y2b ，outlook ，其余的由华为 push ，剩下的 oppo push ，基本能覆盖推送，覆盖不到的就后台不管。

[SenLief]

@mxalbert1996 貌似实际上没有系统通知，都会拉起 app 来通知。

[nothingistrue]

建议楼主先了解一下 Android 的后台机制。

另外楼主的标题应该翻译一下：为何谷歌不学苹果，或者中国的各种爹，强制接管应用的通知功能。

[evill]

@wangxiaodong 你是对这些流氓一点都不了解，互信？不可能的
不限制的话，啥都能干出来，比如 白噪音保活 [dog]

[clementewy]

转安卓后发现，我手机里安装的所有 app 只有微信是需要自启动的。

[mcluyu]

大清早就让我无了个大语。。。

[unco020511]

@mxalbert1996 并不,就算是 Notification message 也还需要应用在前台或者在后台,如果应用被杀死,是接收不到的,我们两亿的出海应用,之前特别治理过 FCM 的问题

[wangxiaodong]

@evill 让用户决定是否启闭，而不是收拢到一言堂的厂家手里，手机出钱者和开发者干瞪眼，只要是为了满足业务需求保活，自然是正当的，我反对的是厂商的一刀切，只给付钱或媾和的厂家白名单，而不是把设备控制权给到手机购买者。

最希望的模式是：厂商建议启闭、用户决定启闭。

[F7ionsy]

你在鬼扯什么？

[ShadowPower]

@mxalbert1996 我开发过 FCM 应用，之前负责公司 APP 里的推送这一块。
虽然文档是这么写，但实际上 FCM 的工作模式并不是简单的一句“直接由系统处理”就能概括的。

像是小米推送、苹果的 APNs ，都是系统自带的组件来负责从接收推送内容到呈现通知推送的全流程。
仅当你点击了通知，或者是国内推送平台所谓的“透传通知”时，系统才会真正唤醒相应的 APP 处理推送内容。

FCM 并不是这种设计。它的职责只有统一收取推送内容，然后转发给 APP 。系统只负责一件事情：统一各种 APP 与推送服务之间的网络连接。

在 FCM 接收到通知之后，其实没有“把通知显示出来”的能力。最终都由 APP 自己处理。

文档中提到的“FCM SDK”并不是一个系统组件（系统组件也不会叫做 SDK……），而是集成到 APP 内部的一个模块，封装了接收和处理通知的逻辑。如果 APP 不能启动，那么其中的 FCM SDK 也不能帮你把通知显示出来。

如果你把应用关闭/杀死了，此时系统会短暂唤醒 APP ，然后走 APP 里的逻辑。消息类型并不会改变这一点，只是 FCM SDK 简化了应用开发，不需要用户自己创建通知罢了。原文是：“此类消息由 FCM SDK 自动处理”。

在你发的连接里，其实下面还有几句话：
“当您的应用在后台运行时，如果您希望 FCM SDK 自动处理通知的显示，请使用通知消息”
“应用在后台运行时，通知消息将被传递至通知面板。应用在前台运行时，消息由回调函数处理”

里面总会提到“运行”这一点，其实挺准确的。只是没有提到应用被杀死时会被 FCM 唤醒……


完全禁止应用后台自启动的情况下（无论是国内 ROM 限制，还是用 Xposed 修改了系统框架限制），FCM 日志里都是“Failed to broadcast to stopped app *********”。

[ShadowPower]

其实 OP 的诉求是合理的，简单来说就是：

希望能像苹果一样，由系统组件统一呈现 APP 通知。
目的是为了能完全禁止自启动而不影响正常使用。


当然我能理解，不是所有人都了解 FCM 的工作原理。

论坛里有过一些帖子抱怨国内 ROM 收不到 FCM 推送，其实原因无非两种：
1. 谷歌服务的后台保不住（我只在老的华为手机上观察到这一点，其实大多数国产 ROM 还真给谷歌后台，只要打开谷歌服务开关，真的耗电）；
2. 收到了 FCM 推送，但 APP 唤醒被拦截了，显示不了通知内容（这才是主要原因）。

[ShadowPower]

@wangxiaodong 然而绝大多数应用都应该禁止自启动，因为这种能力对于 99%的应用来说，都不是正常运行所必须的。
否则 iPhone 根本就不能用，因为真的没有，有也是 30 秒存活……

你提到了保活，对于真正依赖这个能力的应用，Android 给了一条路：如果你想后台保活，那么你应该创建一个常驻通知。
这个设计其实是：必须醒目地告诉用户“我就是想要在后台运行”。

这比 iOS 上的根据有没有播放音频来限制后台还要高明得多。

你会发现音乐播放器必定有一条通知来给你控制播放，除了方便用户操作以外，其实“保活”才是这条通知的核心目的。
高德地图、百度地图等应用，导航的时候也会创建一条常驻通知。

如果用户知道应用的功能必须后台保活，用户自然会理解。假如一个看新闻的应用也要后台保活，用户马上就会察觉到这个应用可能有问题。

[evill]

@wangxiaodong 太高估用户素质(褒义词)了，90%的人不知道什么是保活，为何要保活。
高估了 app 厂商的素质，为了广告、用户信息等等，能保活决定保活，参考摇一摇进入广告（那段时间，走路都不敢开起 APP ，比跳转）

[evill]

决定-》绝对

[lugoyoung]

@unco020511 老哥可否留个联系方式, 我这边也是出海应用遇到了 FCM 的问题, 能否留个联系方式,有偿咨询下?

[adoal]

那么为啥国内都要做保活呢，为啥混战了这么多年才有好几路的统一推送呢？

[wy315700]

FCM 做的真的拉，频繁拉起 APP 。。
这还能洗

[wy315700]

@ShadowPower
然而这条规定在国产 UI 上可能也没用。

MIUI 上装 Apple Music ，也躲避不了被杀的命运。经常歌听着听着就没了。后台被杀了

[unco020511]

@lugoyoung 你留绿色软件,我加你

[unco020511]

其实楼主说的是对的,很多人没明白这其中的区别.

[ShadowPower]

@wy315700 其实这是 Apple Music 的 bug ，我用原生安卓的时候也会听着听着就没了，有一次抓了 logcat ，发现是 AM 自己崩溃了。
用其他播放器就没有这个问题。

[lugoyoung]

@unco020511 eWFuZ18yaHU=
谢谢大佬

[wy315700]

@ShadowPower
原来如此，，我当时搞了很久，后来加了内存锁就好了，唯独没想到是 AM 自己崩了。。。

[ShadowPower]

@wy315700 当时大概是 19 年还是 20 年那时候的事情了。现在 2024 年了，过去了好久，也不一定是这个原因……

[Mystery0]

应用 force stop 收不到推送是 feature 不是 bug ，然后国内 app 起来之后就占着后台不停了，所以说“耗电”
然后国产 ui 为了省电，划卡=force stop ，所以就不推送了

[e3c78a97e0f8]

看标题我以为是反串，仔细研读楼主的发帖和回复后终于明白楼主的意思了
我觉得楼主说得很对，然而这个问题在国外不严重，所以谷歌多半是不会改的

[V28a19cc]

https://github.com/kooritea/fcmfix

谷歌的实现确实不够优雅，上面这个 fcmfix 模块 （ Xposed 模块）能让无后台应用也能正常接收消息并被拉起，说明要改还是能改的，只是谷歌迟迟没做罢了。

[vcn8yjOogEL]

FCM 拉起后的存活时间是有限制的, 国外 App 优化也普遍更好, 所以没那么严重

这么设计是为了保证功能, Android 很早就支持互动和实时通知, 这些都需要 App 自身处理

不过也确实有改进空间, 例如可以让系统提供几种预设模板, 等到用户实际互动时再拉起 App

[Rainson]

@SenLief ad 推的也挺好。

[SenLief]

@Rainson 现在推送基本上你都可以选择推什么内容的。

[whathappen]

像 IOS 那种什么通知都经过 APPLE 的，是不是 APPLE 也可以知道、收集我什么时候收到了什么 APP 的通知？

[SenLief]

@V28a19cc 应该说是想法不同，谷歌的想法是 app 就应该在后台缓存，以防冷启动加载影响体验，正常 14 上的墓碑会让 app 使用 cpu 为 0 ，也就是占用一些内存，保留一个推送进程，等待 fcm 通知广播后拉起 app 推送通知，实际上这时候主进程还没有启动，要点进去才会启动。

fcmfix 模块主要是让 app 直接死掉，由 fcmfix 接收通知然后拉起 app ，不过这样冷启动更费电。

[jaycezhang7890]

看标题还以为来反串的 2333

[codehz]

@whathappen 确实，但是你可以让通知内容对 apple 保密，只能由应用指定的 extension 来处理，让 apple 服务器只可以知道有这么一个通知的存在，大概有多大，仅此而已

[Musong]

@lns103 fcm 通知都是发给应用，fcmfix 的作用就是允许 fcm 的 app 自启动

[Musong]

楼主说的流程没错啊，楼上都是开发啥的？

[Constantping]

如果該程式沒有被「強制停止」，那麼即使該程式的電池設定爲限制，開發人員選項設定爲不要保留活動、不執行背景處理程式，基本的通知該程式仍然可以收到。

[mxalbert1996]

@ShadowPower 我说过了，你只要试一试就知道了，你开发过 FCM 应用的话这不难吧。

[Musong]

你猜 fcm 经不经过 google

[Musong]

@mxalbert1996 #56 真犟啊哥，https://firebase.google.com/docs/cloud-messaging/concept-options 。前不久刚接完，不管哪种最终都是 app 里的 sdk 处理，前提都是在运行或可被拉起。并且试了下，应用不可被拉起的时候，通知消息在 FCM Diagnostics 里显示拉起失败，啥也不显示

[ShadowPower]

@mxalbert1996

[ShadowPower]

@mxalbert1996 顺便找了一些案例：
https://github.com/firebase/quickstart-android/issues/378#issuecomment-353725103
https://blog.csdn.net/Blog_Sun/article/details/108665699
https://gist.github.com/gdeglin/98aeda28035b45cef04bb6c2cb41a4aa

[mkoijnbhu]

fcm 推送过来可以拉起应用一段时间用来插入本地数据库并显示消息, 例如即时通信消息, 这样就不像国产推送进入应用后还要再加载此条信息

也可以不唤醒应用直接显示通知

这个东西看 app 怎么设计了, 用来显示消息的进程可以仅仅是显示消息的也可以是夹杂私货

[mxalbert1996]

@Musong @ShadowPower
所以你们说的都是应用被 force stop （强制关闭）的情况？那很正常啊，因为这种情况系统会特殊处理，在用户再次启动前禁止一切自启动和通知。
但这和我说的不矛盾，在应用被关闭（用户从最近应用里把应用划掉）和被系统杀死（因为内存或重启等原因）时 FCM 的 notification message 都是可以正常显示通知的。至于国产系统在应用被划掉时强制关闭应用，那又不是 AOSP 的标准行为，也不在 FCM 的考虑范围内。

[mxalbert1996]

@Musong @ShadowPower
我在 Pixel 上实测电池用量设为受限并且从最近应用划掉以后仍然能正常收到通知。

[mxalbert1996]

我研究了一下， @Musong 说的没错，FCM 确实是由应用里的 FirebaseMessagingService 接收 broadcast 来显示通知，但楼主的论据和结论都是错误的。首先「自启动权限」是国产系统特供的吧，AOSP 和 Pixel 里都没有这个东西。然后后台可以使用限制模式，不需要保活。结论，国际上 Android 不费电不费内存并不是误解。

[ShadowPower]

@mxalbert1996 这和你的第一条回复已经不一样了。
其中的“系统会直接显示通知”是不对的，要是真有这种功能，OP 的问题已经完美解决了。
同样还有后面的“不需要应用启动”、“但事实上应用被关闭/杀死时也一样”。

那一条回复还有 6 个感谢……

从最近任务划掉的话，其实只有 Activity 被关闭了，其他的东西都还在。例如各种 Service ，其中就有推送。当然各种国产 ROM 的默认行为就是 Force Kill 了。

当然，这个 Service 跑半分钟左右就在后台挂起了，但仍然会驻留内存，占用一点内存空间。要是应用数量超级多，可能就会很明显。


国产 ROM 很多权限管理功能其实走在 Google 前头，最早的时候，Android 完全不存在这个功能。
后来原生 Android 可管理的权限也是慢慢加上去的。早期的粒度还非常粗，分类也不合理。

并不是原生 Android 的设计都是合理的，有些地方 Google 还得从国产 ROM 里借鉴优秀设计。

至于耗电，如果世界真的像想象中那么美好，那么谷歌其实用不着推出“自适应电池”、“电池优化”这种功能。
这些功能并没有把指定应用的一切后台耗电/耗内存的东西彻底消灭掉。
其实，不是因为推送功能会导致显著耗电，而是因为应用本身的“可能是合理的功能”在后台耗电。而 OP 需要的，只是看看应用推送的通知罢了，平时不希望这些功能在后台运作。

按理来说，当你只需要应用的一部分功能时，在保证这些功能正常运行的前提下，给应用的权限应该越小越好。

杀掉应用，并切断所有唤醒途径的话，大多数时间里，这款应用后台的资源占用就像没安装它一样。
而这时候，你又能通过系统服务来查看来自这个应用的推送。

这难道不是更好吗？

如果你确实需要一些后台运行的功能，系统也可以给用户这样的选择：手动开启 APP 的唤醒/后台运行权限。

[01046]

受益匪浅，才知道 FMC 对停止的应用不起作用

[wangxiaodong]

“如果你确实需要一些后台运行的功能，系统也可以给用户这样的选择：手动开启 APP 的唤醒/后台运行权限。”


@ShadowPower 国内 android 的白名单制度可不允许。

[mxalbert1996]

@ShadowPower
「不需要应用启动」是没错的，应用并不需要在后台运行。如果你把它理解成是系统不会启动应用，其实也没差太多，因为只有 FirebaseMessagingService 被短暂地启动，最近的 Android 版本都会在短时间内杀死应用，应用并没有机会完全启动。
关于通知是由谁显示的，我已经在下面更正了。
强制停止应用并且禁止自启动当然不好，因为这是以牺牲应用功能为代价的。如果你不同意这一点的话，那我觉得我们也不用继续讨论了。

[ShadowPower]

@wangxiaodong 白名单只是给 APP 默认自启动/后台无限制而已……
至于怎么设置都不能让应用在后台存活（像类原生一样）的情况，我只在一个 ROM 上遇到过：ColorOS 。避开这个就好了，当初我用这玩意确实杀后台杀麻了（我在 2019~2020 年的时候用，当时 OPPO Reno ACE 性价比很高）。


@mxalbert1996 这么做并不会牺牲应用功能，只是在增加功能，因为改动只有一个：
把原本由 APP 显示通知内容，改为由系统服务负责显示。

除此以外，其他功能没有任何区别。
没什么功能是强制的，都是根据个人意愿自行设置启用和禁用。

至于要不要杀掉应用，是否允许应用被唤醒，是用户的“额外选择”。而上面的改动，只是为了在这种选择下，依然不牺牲“消息推送”功能。

目前的情况是，你只能在“无法及时收到推送，甚至收不到推送”和“允许应用本身的后台功能”之间二选一。

前面已经提到过了，并不是“推送”本身导致耗电，而是应用里与推送无关的后台 Service 导致耗电。如果现实情况不是如此，那么 Google 也不需要推出那些电池优化功能。

把电池优化开到受限的话，推送也会受影响，会被推迟。策略是攒一段时间一起唤醒来减少唤醒次数。还有“对齐唤醒”优化技术，会让多个 APP 的后台在同一时间点唤醒，以减少整个设备的唤醒时长。

给 tg 、discord 等应用开限制后台，体验就不好。

但如果由系统来显示通知内容的话，当你 [确实想要] 彻底禁止某个应用在后台活动，你就可以强制停止，禁止后台启动，同时依然正常接收消息推送。

如果你不需要推送，还可以把通知权限关了。

---

打个比方：
这就好比你去一个餐厅吃饭，这家餐厅一旦点了米饭，必须同时点面条，面条还要付钱（指应用本身的后台功能带来的内存和电量影响），否则什么都吃不到。
而 OP 觉得这样不好，希望做一个改动，可以只点米饭，不点面条。改动内容是“米饭可以单独供应”，理由是“我不想吃面条，强制我点面条是浪费我的钱”。

你反驳 OP 的理由是“这个改动会影响你吃面条”。

然而现状是：米饭一直都可点可不点（即：通知权限可以自由开关）。
想点米饭，就得顺带点一些面条，可以点得少一点（指：限制后台），但不能不点。
如果经常吃米饭，还希望第一时间吃上（指：及时的通知推送），这家店会多给你一些面条，而且要多付钱（指：自适应电池）。

所以，“在不要面条的情况下，希望可以单独供应米饭”的要求，我感觉十分合理。也不影响你吃面条。
对于本身就喜欢吃面条的人（不限制应用后台活动的人），一直都可以只点面条，还能顺便来点米饭。

[wangxiaodong]

@ShadowPower 自启动和后台存活其实是一个问题，我说的是必须保活的应用，比如 IM ； android 现在的行为是必须打开应用或者被已打开应用唤起，这不还是没收了 app 的保活能力嘛，就是说，没有自启动，你连启动的机会都没，就更别说后台进程了；不过，我用的国产手机似乎对 QQ 和微信就网开一面，为啥用户都不能决定某个 APP 的启动，而是厂商来决定。

我对 android 近年来的权限收紧是略有微词，但对国产 android 系统是坚决不认同。

[ShadowPower]

@wangxiaodong
关于“为啥用户都不能决定某个 APP 的启动，而是厂商来决定”这一点。

除了上文提到的 ColorOS 这种无论如何设置都会半小时钟后无脑杀后台的蛋疼 ROM 外，其他厂商的 ROM （例如 MIUI ）在用户自行决定要允许某个 APP 开机自启+驻留后台的时候，都可以做到。而且运行表现和类原生 ROM 基本一致。把自启动打开，省电策略改为“无限制”就好了。

唯一不能关闭的功能可能是划掉最近任务时强制终止。国产手机的海外版 ROM 默认行为和类原生一样，国内版 ROM 则和 iOS 一样。

[wangxiaodong]

@ShadowPower
对的，划掉终止保活的服务很武断，应该设置为第 2 层菜单来关闭，第一层只干掉普通通知，而不是直接 clear 掉所有项。

google 在 android 也有个私心，就是推广 FCM ，估计将来就靠 FCM 来赚钱了，苹果系统也有自家垄断的通知渠道。

综上：直接没收用户的权利，然后自建通道谋私，解决方式就是用脚投票；
国产 android 系统更是过分，跟 360 杀毒软件挟持用户电脑，收 HelloWorld.exe 程序的拦路财一样的伎俩。

@NokiaForever
耗电问题，永远在这些商人的最低排序，我们自作多情了。

[mxalbert1996]

@ShadowPower
你所谓的改动好像不止一个呀。

> 把原本由 APP 显示通知内容，改为由系统服务负责显示。
没问题呀，我不反对。

> 杀掉应用，并切断所有唤醒途径的话，大多数时间里，这款应用后台的资源占用就像没安装它一样。而这时候，你又能通过系统服务来查看来自这个应用的推送。这难道不是更好吗？
如果这个功能默认开启，那我坚决反对。如果默认关闭，那我并不反对，只是在因为有 FCM 加上 Android 越来越严的后台活动限制下已经相当好的国外应用环境下能有多大效果，又有多少用户会真正去用，都是疑问。

你不同意没关系，你也不用写长篇大论来说服我，我在国外用 Pixel 用得好得很，对我来说（可能也是对大部分用户来说）不用操心哪个应用需要后台哪个应用不需要才是更重要的。

[Seulgi]

其实有一个思维误区，为什么国内这么做，为什么海外那些厂商不这么做。国内=一个国家，一个语言，一个思维习惯，一个认知。海外=许多国家，不同语言，不同法规，不同认知，不同习惯。思维不一样。

[ShadowPower]

@mxalbert1996
> 杀掉应用，并切断所有唤醒途径的话，大多数时间里，这款应用后台的资源占用就像没安装它一样。而这时候，你又能通过系统服务来查看来自这个应用的推送。这难道不是更好吗？

这倒不是默认开启或者默认关闭的问题。目前的情况是，想要的人早已用上了，而不想要的人可以永远不用。它并不是一项需要“新增”的功能。
哪怕是类原生或者 Pixel ，也可以用 Thanox 这种插件，或者其他的东西来实现。我自己的类原生（ crDroid ）也整这玩意……

这里讨论的从来都不是“需要加切断唤醒禁止后台”的问题，相关的内容只是为了详细说明：
1. 为什么会有这样的需求；
2. 是不是真的耗电：当然，而且耗电的原因不是推送机制，只是解决耗电问题的做法都会影响推送；
3. 电池优化是不是能解决问题：能缓解，不能根治，而且依然影响推送机制。举个例子，微信虽然不接国内推送，但是接了 FCM 。然而开了“优化电池使用”之后，微信电话再也接不到了，因为收到推送的时候对方已经挂断好久了；

只是我看了帖子开头几个回复，要么觉得 OP 的需求是伪需求，要么可能真的觉得 FCM 的原理和苹果 APNs 完全一样……
所以我觉得，有必要把需求的来源和相关的技术细节都讲讲，希望能从“有这种需求的用户”的角度，去看待“修改 FCM 设计”这种想法。

而不应该一上来就否定整个帖子。


其实真的有不少用户有这种需求，甚至这就是一些人用 iOS 的理由。
但我觉得 iOS 走向了另一个极端……其实不是所有人都能接受。

[mxalbert1996]

@ShadowPower
我相信任何一个阅读理解不是 0 分的人都能从你之前的回复看出你是在提出「 Google 应该学习国产 ROM 的自启动权限管理」，然后你现在又来说「这倒不是默认开启或者默认关闭的问题。目前的情况是，想要的人早已用上了，而不想要的人可以永远不用。它并不是一项需要“新增”的功能。」，我就不太能理解你到底想说什么。
另外你也不用装理中客，很显然你不是（当然我也不是）。

[ShadowPower]

@mxalbert1996 这两者其实不冲突，前者是愿景，后者是现状。

进一步讲，从我的立场出发，我感觉现在的 Android 部分权限设计和 FCM 推送机制设计都不合理。
我当然会表明我认为权限设计不合理这一点，来回应上面的“AOSP 和 Pixel 里都没有这个东西”。因为前提不存在，则后面的诉求就失去了意义。

但现状是，其实 Google 不做的权限管控，甚至国内厂商也不做的（例如存储隔离），已经可以通过使用某些 ROM 或者安装特定的软件来达到目的了。

因此，Google 做不做，这一点不在诉求范围内，毕竟我已经用上了，但不妨碍我认为原生安卓的权限管理设计不如一些国内 ROM 完善。
但我觉得那是个好设计。用户的权限比 APP 开发商更高是一件好事，因此 Google 要是做了会更好。并非强制，而是留给有需要的用户。

当 Google 考虑到“有这样使用的用户”时，才能意识到 FCM 设计的问题在哪。实际上目前开着优化电池使用都已经觉得体验不太好了。

我现在就处于“既能用上 FCM ，又严格限制应用后台活动”的情况。哪怕我用的是类原生……

Android 本身是开放的，它就不应该“专为 Google 自己的手机设计”，尤其是非 Google 手机上面运行的 APP 其实都严重依赖 Google 的生态的情况下（接了 FCM ），那么 Google 就有必要考虑整个生态内的各种情况，使用一个让大家都满意的方案。


所以，真正需要 Google 做的，就只有改 FCM 推送设计。因为这玩意完全掌握在 Google 手里，需要推动应用开发者对升级后的 FCM 做一些兼容，不是 Google 亲自去做，那就没什么好办法。

[ShadowPower]

@mxalbert1996 快下班了，写得有点乱。不过，我在倒是没在装理中客，只是并不想像一些回复那样仅仅单纯地输出观点，而是希望写的东西能把事情都讲清楚。

[wangxiaodong]

“既能用上 FCM ，又严格限制应用后台活动”，我觉得这个需求很小，估计是一小撮儿极客而已，甚至很多人都不知道后台进程是什么。

我的想法是让 android 回归大众，不能因噎废食，一个恶意 app 违规推送了个通知，然后全部一刀切，让用户都没能力让喜欢的 app 加入白名单，况且这个白名单竟然需要给设备商付费或者必须是嫡系。

iOS 我都懒得提，标榜安全，按这个标准，iOS 早年复制粘贴都没做的时候，是不是更不会泄露，残缺宣传成安全，全球我看就苹果独此一家！
@ShadowPower

[ShadowPower]

@wangxiaodong 你举的例子都不恰当，诉求只不过是想让 FCM 通知改为合理且可靠的设计，而不是想剥夺 Android 现有的功能。回想一下，你是不是一开始也觉得 FCM 就是系统框架负责显示通知的。

在我接触过的例子中，几乎所有对 FCM 了解不多的人，一开始都会这么想。我在几年前一些探讨如何让微信走 FCM 推送的帖子里（酷安上面），还发现有人觉得微信没了后台就收不到 FCM 推送，是因为微信自己没适配好。

当然，那时我也不知道，直到我真的去做了相关的开发才知道这些细节。原来 FCM 设计成了这样。


另外你的回复总是想讲阉割系统功能，增加更多限制之类的东西。我还是得说一下，和它有关的都不是“诉求”本身，而是“我对这些功能的看法”和为了说明“为什么会有这种需求”。

你说的阅读理解的问题，跳出这个问题，考虑这段对话：

A：你觉得他这次考试考得怎样？
B：他还得再加把劲。

这段对话里 B 可不一定希望他努力，也许只是委婉地表达“考得不怎么样”而已。是人物 B 对“他”的评价。虽然评价是消极的，但又不想直接说出来。

如果一直都在想着“诉求就是阉割系统功能”，那么理解就会有偏差了。

我还是得强调一下，关于禁止自启动、后台限制等，现在已经有了选择（无论是国产 ROM ，还是借助第三方工具），是“已经解决”的需求。因此，尽管我会提到，我对谷歌现在的设计有些看法，但这件事就不是“需要 Google 去做的事情”。

只是为了回复你之前提到的 AOSP 和 Pixel 都是这种设计，所以 FCM 这样设计没什么影响这个观点。
如果 FCM 只能在谷歌自己的设备上使用，其他手机上运行的 APP 都只能接入其他推送平台。那么确实没什么影响。

可是谷歌掌控着大多数海外 APP 推送……无论你用什么 ROM ，使用习惯是怎样的，想收这些应用推送，你都逃不过它们。

我的态度则是，两者在我的评价里都是不太好的设计，只是恰好正常使用的情况下互相兼容罢了。
为什么我觉得“让系统直接显示通知内容”更好，在前面都讲过了。

[wangxiaodong]

@ShadowPower 我的诉求是：别把 FCM 或国内手机商渠道作为 android 系统独有的通知渠道，即使是变相的缩权方式我也不认同。

“自启动和后台保持”是可以自建渠道的基本权利，如果只有 FCM 被系统列为白名单，那 android 危矣，就是第二个微信小程序。

[ShadowPower]

@wangxiaodong 我支持你的诉求。但是你的想法其实在 Android 上还比较麻烦：
如果用户只是单纯地安装了应用而不做任何配置，在 Pixel 上，电池优化和自适应电池的设计对这种自建推送渠道并不友好，因为会被识别为滥用，然后开始加大限制。
这已经是 AOSP 的“默认行为”了。FCM 实际上有特权，包括 APP 里的 FCM SDK 里接收推送消息的 Service 也有电池优化的特权。

要想实现你的各种诉求，Google 也得改。但显然不会让 Android 回到那个 APP 一天 24 小时在后台偷偷做事情的时代。
现实总是会充满妥协的，完全理想的世界并不存在。

无论如何，今天的各种海外安卓 APP 几乎只接入 FCM 推送。
减少电池优化功能（无论是温和的还是激进的）对推送的影响，这一点已经很现实，很合理了。

至于你的诉求，如果谷歌不想让“电池优化”功能形同虚设，只能针对这种需求专门设计一套机制。就类似无障碍服务一样，单独授权，给一些特别的权限，也给一些防止滥用该功能的限制。


我追求的一直都很简单，用户的权力应该高于 APP 的权力。想用的功能都应该正常使用，不想用的功能都可以不允许 APP 去做。
如果 APP 在后台做我不知道的事情，而我不需要它，我应该能彻底关闭它。
但我还需要收取这个 APP 的推送通知，目前 iOS 和国产 ROM 的推送都可以做到这一点，可惜 FCM 做不到。

只要能做到，就可以了。

我追求的不是苹果那种“苹果觉得你不需要”，然后全都不让做，用户没有选择权。
而是用户可以根据自己的意愿，来掌控自己的设备而已。