如何看待谷歌最新发布的Android O?（转）

这篇文章转自于知乎，文章作者是大名鼎鼎的绿色守护还有黑域APP的开发者！！希望这篇文章不会被删了！
这篇文章说的是关于Android O的后台控制策略！
在文章的最后，我会贴上原文的网页链接，有兴趣的可以点击进去查看！

之前我在微博上简略评价过，Android O的后台控制策略显然还是防君子不防小人的西式思维。

对后台服务和自启动广播的限制仅针对面向O（targetSdkVersion>=26）开发的应用。
这是什么概念呢？打一个不严谨的比方，这就好比国家出台房产限购政策，但只对主动申请被限的购房者实施。你可以想象，一众Push SDK团队看到这个消息时的心情，那简直是如释重负啊，然后通知客户『为了确保推送的可靠性，请开发者不要升级target sdk版本到26』。
对交叉唤醒基本没有施加有效的约束（原因参见上一条）。即便是target O的app，startService()这个接口在后台被废了，但是bindService()没有被限制，它将很快取而代之，成为毒瘤的主流唤醒方式。连环唤醒将继续施虐……
总而言之，『交叉连环唤醒』是没有进入中国市场的Google完全无法能理解的东西……
Foreground service（典型特征是通知栏有一条划不掉的通知）完全免于所有后台限制。可以想象，以后你的通知栏可能真的没法直视了……
----- 题外话 -----

Google在处理target SDK version（一个用户基本不可见的App开发内部设定）的方式是典型的技术型思维，而缺乏经济学手段的运用。每一次的target升级带来的都是更多的束缚，却没有与之匹配的『诱惑』。怎么指望开发者会升级到更高的target SDK version呢……

----- 2017.4.3 更新：还是说点积极的吧 -----

即便是应用没有target O，其实在Android O上也还是会受到一些限制。其中最显著的一个限制就是后台wake-lock。Android M 和 N 上，息屏并保持静止一个小时后，doze启动，wake-lock才会释放；从Android O开始，应用的进程一旦空闲（通常也就是后台服务结束）或终止，wake-lock就会立即释放。但只要还有后台服务还在运行，wake-lock就仍然要等到doze启动后才会释放。

次要一些的限制还有对后台请求定位的响应频次限制，Android O下所有应用都只能得到大约每小时数次的位置更新。

以上对全部应用的限制，也算是聊胜于无吧。

----- 2017.5.18 更新：DP2 带来的希望 ----

从Android O DP2开始，即便应用没有target O，用户现在也可以在系统设置中主动激活针对任何应用的后台限制（仅就原生Android O而言）。这也算是Google的一个曲线策略了，就如同当年Android 4.3时的AppOps隐藏设置。但是否会导致应用功能异常，以及限制程度与target O有否差别，就需要进一步观察了。

补充：验证发现DP2的后台限制对MiPush SDK的后台进程无效，依然可以长期存活。

----- 2017.7.26 更新：DP4 的大逆转 ----

在 DP2 和 DP3 中验证后台限制对大部分国内应用无效后，我向 Google 提交了一个 issue 反馈这个缺陷。在跟进过程中，发现了另一个去年他人提交的 issue，其中指出了一个从 Android N 开始就存在的低级代码bug，正是这个 bug 导致 Android N 的 OPS 限制 RUN_IN_BACKGROUND 和 Android O 的后台服务限制都只能停掉应用的第一个后台服务。如果应用有超过一个后台服务，则仍会继续在后台运行。（PS，向 Google 提交 issue 务必要严格按照模板附上所有必要的信息，否则很可能就会被对方直接忽略，造成像那一位同学去年就提交的 issue，还遗留到 Android O 差点酿成悲剧）

好消息是，DP4 终于修复了这个 bug，现在后台控制已经全面按照其设计预期生效。只要应用面向 Android O 开发或是用户主动开启了应用的后台限制，那么这个应用进入后台的1分钟后，其全部服务就会直接停止。之后只要它还处于后台状态，就无法再启动任何服务了，无论是通过自身的定时任务还是由其他应用主动启动。

不过事情也不是就此圆满了，这里还是得泼点冷水：

服务的启动（startService）在后台被屏蔽，但服务的调用（bindService）不受限制。也就是说大家所熟知的交叉唤醒还会继续肆虐，那些过去使用启动服务方式的交叉唤醒估计很快会转向调用服务方式。
服务的启动虽然在后台期间被屏蔽了，但应用中被设计为定期保活服务的周期任务还是会继续的周期运行，尽管它们并不明白自己已经无法启动服务了。也就是说 CPU 依然会被它们频繁唤醒，待机耗电并不能得到有效改善。
原文链接：

兄弟们，来看看 @散闲游人   @AlexVictor   @漫长花   

说来说去，就是软件后台运作耗电问题。。。
谷歌是建立在自己有推送，有通知的安卓体系，而国内恰恰木有，导致了消息通知你必须要挂后台的前提条件之一，故能不耗电吗？
完善国内安卓体系，就是国家层面的推送早日实现，真正实行无后台运作，也可以收到消息，向水果看齐。
华为也有自己的的推送，但明星软件（特别腾讯），无加入就等于零。

结束国内安卓软件开发商的免费APP，是今后的话提，而免费的代价就是软件开发商拼命在运存车上占据后台，占据率是决定投资商钱多少愿意投入。

技术上的归范，有时远不如法律条文的归范。。国内安卓软件生态圈必须有所改变才是正经。

我们为什么运存（RAM
），越做越大，也永远满足不了软件商也把软件越做越大，不变的运存百分比，变的是绝对值，如此，电池就根本耗不起。

看安卓8如何了。。。但根本性的木有改变，就难有飞跃。。

把外链去掉！