为甚麽主流的国产Android推送服务商不仿照APNS或GCM做成独立统一的模式

简单地说:没有这个 POWER。第三方推送服务提供的 SDK,是嵌入在 App 里边的,它能做的事情其实是很有限的,比如会被各种安全判定为不正常,会被厂商 ROM 限制。即使某一家搞定了大部分的推送服务份额(70% 以上 App 集成其 SDK),也离你说的目标距离远得很。相对可能说有 POWER 的是 Android 设备厂商,比如小米,也推出了自己的推送服务。但是,小米能够强制所有的 App 都集成它家的推送服务么?不能。你不能说,我买个小米手机,安装个 App 在小米手机上运行会有功能缺陷,否则谁敢买小米手机啊。是的,iOS, Android 这种平台的拥有者才有这个 POWER。厂商也不要想,除非你另外弄个平台,不兼容 iOS, Android 应用。这里顺便科普一下,其实第三方推送服务商即使不做长连接,其增值服务也同样是有价值的。国外做推送服务最早最完善的是 Urban Airship,之前 Android 上它也有自家的长连接,后来完全改为 GCM 了。第三方推送服务做 iOS 推送更是这样了,因为 iOS 设备上推送基础服务只能是 APNS,但不妨碍第三方推送服务提供附加价值:让App 运营推送更轻松。所以,推送服务方案,可以理解为有两层:底层是长连接部分(管道),这是推送的基础。上层是业务部分。APNS/GCM 只做了基础部分,第三方推送服务提供依赖于 APNS/GCM 提供推送的增值服务,他们不必去做长连接这个管道部分。这个管道部分本来就是 Android/iOS 平台方直接提供最合适,因为这样才可以真正做到共享。国内特例,ZH特色。Anroid 的 GCM 在国内用不了。大家只好各显神通了。其实上面的『两层』说法有个启示,Android 设备厂商是可以与推送服务商合作好,从而改善生态的 - 厂商只提供基础服务,类似于 APNS/GCM的,公开开放让第三方推送服务商对接。这样做,就有些类似于题主期待的目标了。只是,国内的厂商貌似还没有这个魄力。我们期待着。
■网友
谢邀这得从几个方面来说明这个问题。第一点,目前国内Android应用市场很混乱,大部分应用都拿了很多权限,因此也根本没考虑过多加一个环节让用户选择是否接受推送(部分应用在应用设置相关页面可以选择关闭),让用户选择反而可能导致安装后开通推送的比例降低;第二点,第三方推送SDK的进程并不是Android的系统进程。如果把手机上多个应用推送合并为一个进程,如果一旦被安全卫士或是有ROM控制权的友商干掉了,所有应用的推送都收不到了。分布在每个应用各自的进程中各自为政反而不会导致鸡蛋放一个篮子里碎掉的危险。第三点,其实现在推送SDK已经做了大量的优化,保证长连接心跳的合理频率,降低电量的消耗,同时采用共享链路的方法降低流量的消耗。只是目前Android市场上推送还未有垄断地位的存在,同一台手机上多家推送服务进程同时存在是很有可能的,虽然比每个应用自己搞一个长连接要省电多了,但还是不如GCM省电省流量。另外,耗电量的大头在于推送没有对齐唤醒,导致用户手机不间断的亮屏并持续几秒+呼吸灯闪烁+震动+声音,推送进程本身是耗不了多少电和流量的。PS:支付宝目前不采用libraryAPK,是因为已经开发了支付宝支付的SDK,淘宝等相关应用集成就可以调用,也不需要支付宝常驻后台。利益相关:个推SDK产品经理
■网友
小米华为联想都有系统级推送服务,用了他们开放平台的推送服务的应用在有对应的系统级推送服务存在时会优先使用系统服务。另外用了百度BCM的应用貌似会共享长连接?(未验证)所以会互相唤醒不过这些服务框架不会预装在别的品牌的手机上,也不能指望应用开发者去做,毕竟要部署两个apk挺麻烦的。
■网友
只要前几大厂商一致行动就可以了。然,没有。难道要山寨厂联合逼宫?
■网友
需要国内各手机厂商、大软件厂商、应用商店共同占股组建这么一个公司股份就按照市场占比来吧


    推荐阅读