绿色守护
我如今觉得它次要能对于那些要了后台却没有学会放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的感化，还有可能搞瘫掉应用法式甚至整个系统的风险。
无论若何，利用绿色守护如许超出系统本来才能的软件，需要利用者自行承担倒霉后果。