嵌入式系统设计第三次作业

调研：Android系统的功耗管理

总述

在嵌入式领域，功耗与运算量几乎成正比。操作系统里所需要的功能越来越复杂、安全性需求越来越高，则会需要更强大的处理能力支持。虽然现在芯片技术不断提高生产工艺降低制程（就是芯片内部烧写逻辑时的门电路尺寸），几乎都已经接近了物理上的极限（40纳米、28纳米、22纳米），但是出于设计更复杂芯片为目的的，随着双核、四核、以及越来越高的工作频率，事实上，功耗问题不但没有降低，反而进一步被加剧了。

Android系统中应用程序的功耗管理

在Android的整体系统设计里，功耗控制会先从应用程序着手，通过多任务并行时减小不必要的开销开始；在整个系统构架里，唯一知道当前系统对功耗需求的是SystemServer，于是可以通过相应的安全接口，将功耗的控制提取出来，可由SystemServer来进行后续的处理。Android系统所面临的运行环境需求里，电源是极度有限的资源，于是功耗控制应该是暴力型的，尽可能有能力关闭不需要使用的电源输出。当然暴力关电，则可能引起某些外设芯片不正常工作，于是在芯片驱动里需要做小范围修改。与其他功能部分的设计不同，既然我们功耗控制是通过与驱动打交道来实现，可能无法避免地需要驱动，但要让修改尽可能小，以提供可移植性。

Android系统多任务管理

201301201122544815 Activity，它拥有6种不同状态。它的不同生命周期阶段，取决于这一Activity是否处于交互状态，是否处理可见状态。如果加入这两个限制条件，于是Activity的生命周期则是为这两种状态而设计的。onResume()与onResume()分别是进入交互与退出交互时的状态点，在onResume()执行完之后，这时系统进入了交互状态，也就是Activity的Running状态，而此时如果由于Activity发生调用或是另一个Activity主动执行，弹出一个小对话框，使原来处于Running状态的Activity被挡住，这时Activity就被视为不需要交互了，这时Activity进入不可见互状态，触发onPause()回调。onStart()与onStop()则是对应于是否可见，在onStart()回调之后，应用程序这里就可以被显示出来，但不会真正进入交互期，当Activity变得完全不可见之后，则会触发onStop()。而Android的多任务实现，还会造成进程会被杀死掉，于是也提供两个onCreate()与onDestroy()两种回调方法来提供进程被创建之后与进程被杀死之前的两种不同操作。 201301201122547733

这种设计的技巧在于，当Activity处于可交互状况时，这是系统里的全马力执行的周期。而再向外走一个状态期，只是处于可见但不可交互状态时，我们就可以开始通过技巧降功耗了，比如此时界面不再刷新、可以关闭一些所有与用户交互相关的硬件。当Activity再进一步退出可见状态时，可以进一步退出所有硬件设备的使用，这时就可以全关电了。编写应用程序时，当我们希望它有不一样的表现时，我们可以去通过IoC去灵活地覆盖并改进这些回调接口，而假如这种标准的模型满足我们的需求，我们就什么都不需要用，自动地被这种框架所管理起来。

遗留的问题以及解决方案

当然，这种模型也不符合所有的需求，比如对于很多应用程序来说，在后台不可见状态下，仍然需要做一些特定的操作。于是Android的应用程序模型里，又增加了一个Service。对于一些暴力派的开发者，比较喜欢使用后台线程来实现这种需求，但这种实现在Android并不科学，因为只通过Activity承载的后台线程，有可能会被杀死掉，在有状态更新需求时，后台线程需要通过Activity重绘界面，实际上这样也会破坏Android在功耗控制上的这种合理性设计。比较合适的做法，所有不带界面、需要在后台持续进行某些操作的实现，都需要使用Service来实现，而状态显示的改变应该是在onStart()里完成的，状态上的交互则需要放到onResume()方法里，这样的实现可以有效绕开进程被杀死的问题。并且在我们后面介绍AIDL的部分，还可以看到，这样实现还可以加强后台任务的可交互性，当我们进一步将Service通过AIDL转换成Remote Service之后，则我们的实现会具备强大的可复用性，多个进程都可以访问到。