我一直在读关于https://dontkillmyapp.com/.特别是，我担心制造商如何以"电池优化"的名义实施机制，通过在一段时间不活动后取消应用程序安排的所有警报，削弱本地通知API：AlarmManager在几个设备中不工作
由于作为开发人员，我们无法实现使本地通知可靠工作的修复程序，我想知道是否可以切换到推送通知。但我也不确定我是否可以依赖推送通知，因为似乎有相互冲突的信息：
Signal似乎表示，当电池优化工作时，他们的推送通知可能不可靠，但尚不清楚这是否仅适用于他们的自定义网络套接字推送通知系统，该系统显然在FCM不可用时使用：https://support.signal.org/hc/en-us/articles/360007318711-Troubleshooting-Notifications#android_notifications_troubleshooting_phone
似乎通过Firebase云消息(FCM(发送的推送通知实际上会被Google Play服务接收，所以即使你的应用程序经过了"电池优化"，它们也有可能被接收吗？
有人能解释一下吗？在处理非标准的应用程序杀熟时，通过FCM推送通知是否比本地通知更可靠？
推送通知可以工作，但仍会受到电池优化的影响。Doze模式会让你的应用程序投票率取决于用户对手机的使用情况；电池电量等
作为开发人员，有些事情是我们无法对抗的，如果底层操作系统决定你的应用程序不会唤醒，那么用户最好能得到一部更好的手机。。。
显然，使用FCM并不能保证收到通知——由于电池优化不标准，它们可能仍然无法显示。
以下文章对此进行了记录：
https://hackernoon.com/notifications-in-android-are-horribly-broken-b8dbec63f48a
声明：
谷歌GCM表示，已发送通知，但在应用程序的日志中没有通知的痕迹，就好像操作系统正在吞噬通知
禁用电池优化后，通知显然又起作用了。他们解决这个问题的方法是：
GCM交付收据本质上告诉您设备是否收到推送通知。我们将此与应用程序内部的重复通知送达收据相结合。因此，我们从GCM获得ack而不是从设备获得ack的任何设备都可能会错过推送。一旦识别出这些设备，我们就开始向他们发送机器人信息，告诉他们如何将羊群添加到设备的自动启动列表中。