安卓下令人震惊的 APP 关联启动方式

这些只是推送而已，对某某 app 的唤醒 or 关键启动一般只是启动一个后台同步的 service ，占用资源较少，因为 service 没有用户界面。
iOS 上也是如此，苹果的推送服务一直在后台不停地工作，只是苹果的推送消极一些， app 没有同步 service ，必须要点进 app 才会进行同步操作，代价是 iPhone 的推送总是毛病多一点。

@Khlieb 嗯...最直接的就是各运营商......gfw 不知道省了多少国际出口带宽......就为了省那些钱估计就会有人宁可被骂政治走狗也想继续做下去...

大多是 SDK 关联启动，不过现在国内的 ROM 基本也都有应对方案了，尤其是针对某些根本不需要推送的应用。

@yankebupt 不光是那么简单，有人宁愿自己做到很烂很龌龊也不希望看到自己奶酪被动了

这个就是 miui 说的葫芦链， miui 神隐模式可破！

@ssynhtn android 的毛病更多哇

@flynaj 表示并没有什么用, 平时倒不会乱推送消息,但是依然葫芦娃, 比如开淘宝时候高德地图支付宝的消息准时上屏

@honeycomb 真能推送用户需要的内容的话，长驻通知栏不就行了？用户需要你的推送通知，自然不会杀你的进程

@woyaojizhu8
没有必要常驻通知栏是不可以的，因为这个时候应用处于前台，不受到 doze 等一系列控制功耗设定的限制

@honeycomb 嗯嗯，所以我认为它如果能推送用户需要的内容的话（极少应用才需要），就有必要常驻通知栏。 GCM 也是我不喜的，应用向我推送内容，凭什么要通过 google 的服务器呢？我的原则是“尽量减少中间人”。

@woyaojizhu8
因为它是在一个围墙花园里运行，就要守围墙花园的规矩，这些规矩在事后（指的就是 iOS 的那套推送机制）证明是有利于生态系统的。

就推送的规矩来说，如果每个应用都使用“自己的“服务器，在电量消耗上是不可接受的。因此所有的应用都应该使用相同的推送基础架构。

至于经由（从应用看来的）第三方的 GCM ，如果应用不使用 GCM 的话它几乎也不会选择自有的服务器（除非是微信这样的通信类 app ），而目前的第三方推送商都在做 1 ，前述的电量消耗上不可接受的方法。 2 ，第三方推送服务是导致关联启动的问题的重要原因。

@woyaojizhu8
所以这个原则尽管是非常有道理的但通常不可能满足，既然这样（无法自建推送服务），那么就应当使用标准的，大家都在用的推送机制。

@honeycomb 可能我们看重的不同吧，我不怎么看重功耗

@woyaojizhu8

这里的功耗指的是和待机时间非常相关的，你不用手机时候的功耗。
就导致一个问题，你再是不看重功耗，这部分的耗电会明显地影响到你。

举个例子：
国内银行在 Android 上的客户端提供的云闪付功能的云闪付卡密钥的推送是通过 Giesecke & Devrient 搭建的平台完成的，这东西的 Android 推送非常耗电，跑一天可以消耗掉 300~500mhA 的电量。

这样还怎么和 Apple Pay 竞争？

@honeycomb 我的使用习惯是，不用时关闭数据连接。我不需要所有的后台推送消息（包括 qq 微信）。而我周边的小白用户，他们有些一直开着数据连接，但所需要的推送也只有 qq 和微信（他们装的应用远不止这些，但是需要推送的就这两个）。当然还有很多应用会推送一些他们不需要的无用信息。
还有一些比较会玩安卓的网友，他们也基本只需要 qq 和微信的推送（有些还会有支付宝），而且他们会用 my android tools 禁用其大部分服务，这样就很省电了。
所以说：
1.大部分人需要推送的应用真的很少；
2.即使是需要推送的应用，维持基本的推送功能所需要的电量也不是很多，耗电主要还是由于应用在后台做一些对用户无益的事。
因此没有必要为了省电而让所有推送通过 google 的服务器。
最好的方法当然还是规范化推送，建立一个本地的统一的推送框架，用户可以手动禁止应用除推送以外的后台服务。因为已经标准化了，所以不用再用 my android tools 这种靠猜测、尝试来禁用服务，也不会误杀。应用在后台只有最基本的推送消息功能，也不怎么耗电。
可以类比于 Imap Idle 协议（ http://blog.sina.com.cn/s/blog_5d2184eb0100py1t.html ），本地推送框架就好像一个邮件客户端，应用需要推送功能就好像添加了一个支持 imap idle 的邮箱帐号一样，应用本身后台被禁止，无法再做多余的事。
但是目前不存在这样一个框架，所以还是让需要推送的应用长驻通知栏为好。应用也应约束自己 ，不要开那么多对用户无益的服务。至于你提到的国内银行的云闪付卡密钥的推送，要么是它做了多余的事情，要么是为了更高的安全性需要这么复杂的功能因此需要耗这么多电。如果是为了安全性，那 GCM 也无法替代它吧。

@woyaojizhu8

“耗电主要还是由于应用在后台做一些对用户无益的事”
所以问题出在应用方，从 Android 6 开始出现的 Doze/App Standby 就是用来解决这件事的
它们的作用大致上是关闭屏幕后应用在某种程度上不能运行后台任务 /联网。

以上措施可以绕过，最简单的办法是把应用想时刻运行 service 的进程变更至前台，并利用漏洞(修复于 7.1)隐藏本应出现的持续通知。

"最好的方法当然还是规范化推送，建立一个本地的统一的推送框架"
已经有 GCM 了。 play 的政策也为必要时绕过 doze 等通过间断休眠达到的自动电量管理提供了许可。因此不需要第三方推送服务。苹果乃至小米的做法也证明了系统唯一推送服务是对所有人都有好处的。

“应用在后台只有最基本的推送消息功能”
这个特性依赖于系统的实现，国产 rom 做的比原生系统好，但是国产的做法是不通用的

关注中。