最好的 Android 省电软件是什么？

绿色守护

我现在觉得它主要能对付那些要了后台却没有学会放wakelock(比如bug，不合理的配置)的应用程序

只有它的原理是与众不同的，它不会变成传感器的开关，也不是tasker。

---------------------------

为了帮助理解，需要一些前置知识：

你能看的到的界面叫做Activity

Activity有一套自己的生命周期：

我们能见到的android应用程序的界面的代码是放在Activity对象里的。

从当前的Activity 1跳转到另一个Activity 2时，

Activity 1被调用onPause()
Activity 2按照onCreate()-->onStart()-->onResume()的顺序启动
Activity 1被调用onStop()
如果Activity 1通过finish()结束(按返回键也可能产生同样的效果，具体由开发者决定如何重载onBackPressed())，就会进一步被调用onDestroy()，然后被回收

开发者可以在这些onXXX()方法里里加入相关逻辑，以确保该应用的状态能保存。

最外一层的onDestroy()--->onCreate()流程的作用在某种程度上，相当于WP，iOS的墓碑机制。但是按返回键离开应用时，也会触发onDestroy()乃至销毁Activity的流程。

如果是跨应用的跳转，比如从应用回到了启动器(桌面)，实际上就是从应用的某个Activity跳转到启动器的某个Activity。这个时候应用的这个进程已经没有处于前台的Activity，此时它的所有代码都至少都被叫过onStop()，这个时候进程不会消耗CPU资源，意味着不消耗能源。处于这个状态的应用程序(的进程)被归类为『缓存的后台进程』。

Android采用了Low Memory Killer的方式来管理进程，它按照优先级来为进程分配内存，『缓存的后台进程』的优先级最低，只要空闲的内存不足，系统就会优先试图杀掉『缓存的后台进程』来获取空间。

有前台Activity的进程优先级(FOREGROUND，也包括那些使用前台service的进程，前台service还会在通知栏显示一个不能直接关掉的图标)非常高，仅次于Android的核心组件。System也会被强制设定为FOREGROUND。当然还有优先级更高的zygote/init等进程，它们更重要。

为了让应用程序在后台时也能执行代码，便有了Service对象，封装在Service内的代码可以在后台运行，它的优先级比FOREGROUND，VISIBLE低。所以当系统杀光了『缓存的后台进程』后，还是缺内存的话，便会向带有Service的进程开刀。

如果进程包含启动的Service与前台Activity，则被归类为FOREGROUND

2，有一种叫Receiver的对象，它用来接收Intent(Android里的一种信息)，并发送启动Service/Activity的Intent。Receiver的处罚机制可以用来帮助调度Service/Activity，以实现自启动。

这里我们会遇到问题：

后台的Activity无法执行(这里先不扯『不可见 Activity』/『AsyncTask』/『Thread』等内容，它们与避免阻塞UI线程有关，把它们也算上便太复杂了)。
因此出于种种原因，应用程序转入后台时，开发者可能会启用Servicce来完成必要的任务。

问题是，这些Service对于用户而言不一定是必须的。
对用户非必要的Service可以包括获取广告信息，提供推送服务等内容。
同时，用户通常不能控制这样的Service：
a，应用程序本身压根不提供关闭后台Service的选项
b，应用程序允许关闭诸如『推送信息』的功能，但不会禁用对应Service

这样的非必要Service会占用内存(注意保有它们的进程的优先级比较高)，会耗电，特别是那些因自身有bug而处理不好wakelock的，会导致手机完全无法休眠(意味着即便什么也不做，它还是可以在10个小时内耗干充满的电池)。

所以我们要打的老虎是这样的Service以及使它们运行的机制。

相比而言，设备待机本身并不是很显著的问题，因为设备/芯片制造商，系统开发者，运营商远远比你更关心如何在这些方面节电。

------------------------

最理想的办法自然是让不必要的Service在不必要的场合不运行，且不影响别的组件。可惜这需要开发者妥协他的利益，很多时候并不现实。

我们常见到的自动杀进程工具呢，只会杀进程，但做不到阻止它们再次被自动激活。在这种条件下，我们会遇到更多的耗电，以及杀不光的进程。

因为不能阻止自启动，被杀死的进程会通过『系统事件Intent---->预设Receiver--->发送Intent启动』而自动重新运行。
而杀进程这回事有开销。频繁的杀进程--->进程自启动的循环会消耗更多的电能。

绿色守护介于以上两者之间，它能杀进程，并确保进程不会诈尸：

应用程序运行时，不受到干预。

但是应用程序一旦关闭(以前面提到的Activity被切换到后台)一段时间(似乎是180秒)后，绿色守护开始介入。

绿色守护用"am force-stop"杀掉这个应用程序的所有相关进程，该进程也不会被再次唤醒(关键)

等到要再次开启的时候，应用程序又会被恢复以前的状态，不受干预。

这么一来，这些应用程序确实地不能运行于后台，也就没有相应的CPU消耗。接下来只要绿色守护自己的电力开销足够小，问题就能比较好地解决了。

这样的代价是，那些被『绿色化』的应用程序享受不到『缓存的后台进程』所带来的快速切换的好处。当你再次进入这些应用时，系统需要完整地重新载入它们。

最好的情况应该是应用程序依然能保留那些『缓存着但不运行的部分』。然而，一旦干预Service的运行就要和『缓存着但不运行的部分』打交道。

绿色守护有数个可选功能，它们依赖一个叫做XPosed的工具。可以更快地『杀进程』(也许是用某种办法替代am force-stop？)，更好地做到『进程不会被再次唤醒』(不清楚其中的做法)。

Xposed实际上是一个修改过Zygote(所有的Dalvik虚拟机实例，也就是Android应用程序的进程都是靠Zygote“分裂”(fork自身进程)出来的)，因此第三方开发者可以通过Xposed提供的接口，便捷地对系统动手脚。

-------------------------

目前，绿色守护(2.1)运行在三种不同的级别：

1，无root(2.1加入的新功能，似乎是在无root的情况下达成『绿色化』)

2，获得root权限，无Xposed

3，获得root权限，有Xposed

正文仅针对2/3两种情况，我还没有第一种情况下用过绿色守护，因此不清楚它能不能/如何做到防止诈尸。(更新，原来它利用了辅助功能模拟屏幕点击来杀进程，看样子不像是能防诈尸的样子)

我目前使用绿色守护+手动反注册应用的某些Receiver/Service，从而更接近『让不必要的Service在不必要的场合不运行，且不影响别的组件』的目标。

问题是，这么做不仅需要了解具体的Receiver/Service的作用，还有可能搞瘫掉应用程序乃至整个系统的风险。

无论如何，使用绿色守护这样超出系统原本能力的软件，需要使用者自行承担不利后果。