按：本文作者@Tiger_张虎， 云巴 (yunba.io) 创始人，yunba.io 云端动态消息服务。JPush 创始人，原CTO。

Oracle VM 创立团队成员。(公众号：)已获得许可。

国内第三方启动时的起源2010 年左右，Android 手机在国内很快发展，Google 的原生启动时（C2DM，现在的 GCM）由于种种原因无法长时间用于，当时的 Android 开发者用于各种办法来解决问题这个问题，其中就还包括 Android 手机厂商研发出有自己的启动时方案。对于大部分开发者来说，除了做到一个 App，还要独立国家研发一套启动时系统是件出现异常艰难的事情。哪怕是用户数量相当大的 App ，这也不是一件更容易的事情。于是在 2011 年底，我产生了做到独立国家第三方启动时服务的点子，也就有了后来的极光启动时。

启动时消息能递送的关键这几年常常有业内的朋友探究启动时能否递送的关键因素。只不过最重要的是 SDK 能否保活。具体地说，有以下两方面：1. SDK 如果无法及时地发动跳动，运营商网络的长相连不会被插入。

2. SDK 的任务如果被杀死了，无法被冲向，消息就几乎没机会印发。参照之前的文章：《启动时技术原理：移动无线网络宽相连》如果 SDK 末端无法有效地保活，那么无论服务器端怎么优化，都无法确保消息及时地递送。

对 Android 手机厂商来说，这里有一个对立的问题。对于各个 App 的启动时超过的效果来说是好事，但这样做到一定程度上毁坏了Android系统的生态，减少了功耗，也违反了系统清扫后台设计的想法。

手机厂商都期望自己出产的手机能有尽可能宽的待机时间，但是 App 定点在后台启动、保持跳动的不道德，不会很大地影响手机待机时间。因此，最近几年，手机厂商为了掌控后台服务，持续地发售各种容许手段。比如之前的跳动偏移，也就是不容许 App 给定用于 RTC 后台苏醒手机。还有更加严苛的手段，就是定点清扫所有后台服务，并且不容许服务通过监听广播自动纳起。

第三方启动时已杀正如前文所提及的，最近主流的 Android 手机都会清扫后台服务，禁令服务自动纳起，以前第三方启动时服务商的各种 SDK 保活手段陆续过热，这个问题彻底挽回了 Android 第三方启动时服务的基础，造成完全所有的 Android 第三方启动时服务都无法确保递送。面临这样的问题，App 开发者该如何应付？更加合理的方案因为启动时服务的特点，它最应当以系统原生服务的形态不存在。在 iOS/Android 系统发售的早期，都考虑到了这个问题，iOS 有 APNs，Android 有 C2DM（GCM）。

惜的是，Android 的 GCM 在国内早就无法被有效地用于，而 Android 方面没企图解决问题这个问题，而把问题留下了手机厂商和 App 开发者。考虑到启动时服务的特点，我们自然而然就想起了通过厂商的启动时地下通道来解决问题这个问题，就像在 iOS 上用于 APNs 一样。用于 App 内的消息地下通道发消息给 App，再行通过厂商的启动时地下通道苏醒 App，App 被关上后，拒绝接受消息地下通道的离线消息。

从目前的实践中情况来看，这是解决问题后台进程被清扫的最有效地办法。国内 Android 厂商启动时地下通道现状目前国内几个主要的 Android 厂商中，小米、华为 都有获取官方的启动时服务。经过我们团队的检验，他们的启动时服务在自己品牌的手机上，有比较平稳的递送亲率。

目前展现出最差的是小米，华为的启动时延后有时较为大，也不过于平稳。而另外的几家 OPPO、VIVO、金立 都没官方的启动时服务。

云巴近期发售了一键构建 小米、华为 启动时的功能，便利开发者较慢构建厂商的启动时服务。但是对于没获取启动时服务的厂商，目前还没尤其好的办法。我们期望各主流手机厂商为了 App 有更佳的体验，都能获取解决问题这个问题的方案。

原创文章，予以许可禁令刊登。下文闻刊登须知。

本文来源：中欧体育-www.zgjzc.com