这个问题我在开发中碰到过好多次，本质上是系统省电策略对不同应用的差异化对待，再加上WhatsApp这类主流应用做了针对性的适配优化，具体原因可以拆成这几点：

• 系统省电模式的后台权限差异
  不管是安卓的Doze模式/App Standby还是iOS的低功耗模式，系统都会对后台应用做严格限制：暂停非必要的网络请求、推迟后台任务、甚至直接杀死后台进程。但像WhatsApp这种高频使用的通讯类应用，通常会被系统默认加入省电豁免白名单，或者它主动向系统申请了REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限（安卓），获得了不受省电策略限制的特权。而你的服务大概率没申请这个权限，也没被系统识别为“核心应用”，自然会被限制。

• 推送/后台连接的实现方式不同
  WhatsApp并没有自己维持一个长期的HTTP长连接，而是依赖系统级的推送服务：安卓用FCM（Firebase Cloud Messaging），iOS用APNs（Apple Push Notification service）。这些服务是系统统一管理的，会以极低功耗的方式保持全局连接，即使在省电模式下，系统也会优先保障这个通道的活跃。而你的服务如果是自己搭建的后台HTTP长连接，或者用普通的Service来维持任务，系统在省电模式下会直接掐断这类高功耗的自定义连接，导致服务失效。

• 后台任务调度的适配程度不同
  主流应用会严格遵循系统的后台调度规范：比如安卓用WorkManager或JobScheduler来调度延迟任务，iOS用BackgroundTasks框架。这些API会自动适配省电模式，在系统允许的时间窗口内执行任务。而如果你的服务用的是传统的后台线程或者未适配的Service，系统在省电模式下会直接禁止这类任务运行。

• 系统对应用的优先级判定
  系统会根据应用的使用频率、用户交互程度来判定优先级。WhatsApp作为日常必备的通讯工具，用户打开频率极高，系统会默认给它更高的后台优先级，即使在省电模式下也会保留必要的后台活动。而你的服务如果是小众应用或者后台运行的工具类服务，系统会把它归为低优先级，优先限制它的资源来节省电量。

内容的提问来源于stack exchange，提问作者Mauricio Ballesteros