关于Android电源管理

时间：2022-12-11 09:15:41 其他范文收藏本文下载本文

今天小编在这给大家整理了关于Android电源管理，本文共9篇，我们一起来看看吧！

关于Android电源管理

篇1：关于Android电源管理

使用Android电源管理widget 从Android 2.1系统开始内置了一个非常强大的带能源管理 widget通过这个widget你可以快速开启或者关闭Wi-Fi,蓝牙，GPS，同步这些手机耗电大户，还可以方便的设定手机屏幕亮度，长按手机屏幕，就可以在widgets目录选择启用，

关于Android电源管理

，

篇2：电源管理技术

专为笔记本降低功耗而研发的一系列技术，根据笔记本电脑的实际使用状况，动态调节硬件设备用电功耗状态的一项技术，

电源管理技术

，

一般可以分为处理器级电源管理技术、BIOS级电源管理技术以及操作系统级电源管理技术。

篇3：浅析Windows 的电源管理

windows 2000（包括Microsoft Windows 2000 Professional、Microsoft Windows 2000 Server、Microsoft Windows 2000 Advanced Server）是基于NT核心的新一代操作系统（operating system，OS），Win2000以其可靠、稳定的性能，强大的网络功能等优势受到大家的青睐。装Win2000的朋友也越来越多，我们很有必要深入了解了解Win2000。Win2000功能强大，对硬件的要求也较高，比较容易出现硬件兼容性方面的问题，其中我们遇到的兼容问题常常与电源管理有关：比如BOIS版本较早的机子无法安装Win2000、有些机子即使安装Win2000，但启动休眠时出现死机、莫名其妙的出现CPU风扇不转、不能自动关机，需要手动关机等等。下面就让我们揭开Win2000电源管理的秘密。

Windows 2000为了更稳定、更可靠采用了不少新技术，其中在电源管理方面同时支持高级电源管理Win2000 (Advanced Power Management, APM)、高级配置和电源接口(Advanced Configuration and Power Interface，ACPI) 两种电源管理方式。高级电源管理（APM）由支持在计算机中对可管理电源硬件进行电源管理的一个或多个软件层组成。 APM定义的是独立于硬件的软件接口，这个独立是指硬件特定的电源管理软件和操作系统电源管理策略驱动程序之间的独立。它不注重硬件的细节，使得高一级软件无须了解任何硬件接口，便可以使用APM。而高级配置和电源接口（ACPI）是开放式工业规范，它为主板定义了灵活、可扩充的硬件接口。软件设计人员使用此规范将电源管理功能集成在整个计算机系统中，包括硬件、操作系统和程序。这种集成使 Win2000可以确定哪个程序处于活动状态，并处理计算机子系统和外围设备的所有电源管理资源。因此安装、运行Win2000的计算机主板BIOS 版本应支持ACPI，或某些基于APM 和即插即用设计BOIS版本的计算机。

现在有些主板虽然支持ACPI功能，但支持并不怎么完善。如果在这样的机子上安装Win2000很可能回出现奇怪的问题，

比如前几天的一个朋友安装Win2000 Professional，安装很顺利，但启动时出现了莫名其妙的怪事，在开机未进Win2000时机子一切正常，一进Win2000CPU风扇立马停转，退出Win2000后CPU风扇又开转，我帮他把BOIS刷到最新、全部硬件拔下重装、关掉Win2000的休眠，重起多次，一进Win2000CPU风扇仍然停转。没办法只有委屈APCI了，将BOIS里的A Function设为Disable关闭ACPI，重起后又进不了Win2000。看来这位老兄的主板对ACPI支持不完善。正在一筹莫展的时候，我突然想起Win2000还支持高级电源管理（APM），那就不用ACPI，用APM。在BOIS里将ACPI关闭，用Win2000光盘重起机子，选择重新安装Win2000（不要选择修复安装）。等待了漫长的半小时，Win2000装完，重起后我一直盯着CPU风扇，呵呵……进Win2000后CPU风扇工作正常，我一阵狂喜。原来正是ACPI搞的鬼。 (编程入门网)

那么如何知道自己的主板到底支不支持ACPI呢？告诉你一个办法，把你机子主板的BIOS刷到最新，在www.microsoft.com/hwdev/acpihct.htm下载ACPI HCT v1.61.exe，在Win98下运行测试一些BIOS是不是支持ACPI，如果支持，安装Win2000可能不会出现ACPI方面的问题；如果不支持，也能安装Win2000，只不过麻烦一点，改一些设置：将BIOS里的“ACPI Function“设为”Disable“。安装完Win2000后再将“开始”→“设置”→“控制面板”→“电源选项”→“高级电源管理”的“启动高级电源管理支持”设为启动。不过Win2000在APM方式不支持休眠，在APM状态休眠可能就是等于是关机。

ACPI使计算机比较智能化，在微软的64位操作系统、Win2000的下一个版本Whistler将转向支持ACPI 2.0固定平台（ACPI 2.0 fixed tables），Whistler Beta 2其后Whistler的版本可能只支持ACPI 2.0，使用Whistler试用版的朋友如果出现启动休眠死机、不能关机等方面的问题，可能就是您的主板ACPI不完善，建议您关掉ACPI，如果还不行的话您可能还得回到温酒吧（Win98）！呵呵……

篇4：Linux电源管理详解

1.概述

虽然Linux可以在任何一台386以上的PC上运行，目前大多数人使用的都是新型的，带有各种外设的桌面PC或者笔记本电脑，这样，电源管理功能(PM)就逐渐变得越来越重要，在笔记本电脑上电源管理可以节能，延长电池寿命，而在桌面PC上它可以降低幅射，降温，延长外设使用寿命。现在的操作系统大都内置了电源管理支持，例如 Windows 和 Linux。

2.PC机实现电源管理的方法

要实现电源管理，最重要的有两点：第一是需要设备本身支持节电功能，比如硬盘，可以通过指令暂时关闭；第二是需要操作系统支持电源管理，这样就可以在空闲一段时间之后调用驱动的电源管理功能关闭设备。

两种电源管理标准：APM和ACPI

传统的APM(Advanced Power Management)是一种基于bios的电源管理标准，目前的最新版本是1.2，它提供了CPU和设备电源管理的功能，但是由于这种电源管理方式主要是由bios实现，所以有些缺陷，比如对bios的过度依赖，新老bios之间的不兼容性，以及无法判断电源管理命令是由用户发起的还是由bios发起的，对某些新硬件如USB和1394的不支持性。为了弥补APM的缺陷，新的电源管理ACPI应运而生，这就是ACPI(Advanced Configuration and Power Interface)，它主要是将电源管理的主要执行者由bios转换成为操作系统，这样可以提供更大的灵活性以及可扩展性。

目前的PC机主板一般同时支持APM和ACPI两种标准。

3.Linux对电源管理的支持

内核模块

针对APM和ACPI两种不同的标准，Linux内核提供了两个不同的模块来实现电源管理功能，这就是apm和acpi。需要注意，apm和acpi是互相冲突的两个模块，用户在同一时间内只能加载其中之一，如果当他们在加载的时候发现二者之一已经加载，就会自动退出。

在官方发布的内核中APM是较为成熟的电源管理方式，可以完成在Windows下ACPI所能完成的大部分功能。由于官方内核中ACPI的功能比较有限，目前还处于开发版状态。所以当前的大多数distribution，如红帽子默认就使用了apm作为电源管理方式。但是值得注意的是Linux中的ACPI实际上是由一个单独的项目小组模块进行维护的，当前内核ACPI的版本实际上已经远远落后于最新的版本。由于Linux稳定版中对任何新特性的加入都非常谨慎小心，所以我们也许只能等到2.6.x版本的Linux诞生后才能看到ACPI的稳定全功能版了。不过我们也可以自己对内核打最新的ACPI补丁来获得这些功能。

这里是ACPI的主页:sf.net/projects/acpi/

下面对电源管理的介绍以APM为主。

用户态Daemon

为了让Linux内核中的电源管理功能够更好的被利用，我们还需要用户态daemon程序的配合。针对APM和ACPI，分别有apmd和acpid两个不同软件。他们实现的功能比较类似，都是允许用户预先定义某些策略，然后跟踪电源状态，执行特定的操作。在apmd软件包中还有一个工具apm，用户可以用它使机器主动进入standby和suspend状态，还可以查询bios的apm版本号。在使用acpi时直接对proc文件系统进行操作即可完成同样的功能。

4.Linux下驱动的电源管理机制

在Linux下不必为驱动分别编写与APM和ACPI相对应的代码，Linux与Windows类似，为驱动提供了统一的电源管理接口。驱动只要实现了这些接口，就可以实现电源管理的功能。操作系统在它认为合适的时候就会通知驱动完成这些操作。

实现设备电源管理接口主要需要实现以下5点：

1.使用pm_register对设备的每个实例(instance)进行注册；

2.在对硬件进行操作之前调用pm_access(这样会保证设备已被唤醒并且处于ready状态)；

3.用户自己的pm_callback函数在系统进入suspend状态(ACPI D1-D3)，或者从suspend状态恢复(ACPI D0)的时候会被调用；

4.当设备不在被使用的时候调用pm_dev_idle函数，这个操作是可选的，可以增强设备idle状态的监测能力；

5.当被unload的时候，使用pm_unregister来取消设备的注册，

5.对APM进行编程

下面介绍在实模式中和在Linux下使用APM功能的编程方法：

由于APM是由bios提供的，我们可以直接在实模式(如DOS下)调用int 15软中断来进行电源管理操作。

在实模式下APM的standby、suspend和poweroff功能分别可以通过下面的汇编语言实现：

standby：mov ax, 5307Hmov bx, 1mov cx, 1int 15Hsuspend:改成 mov cx,2poweroff:改成 mov cx,3

需要注意的一件事是在Linux内核中没有使用和实模式的一样的方法来调用int 15H中断，而是直接调用了bios的保护模式接口。所以我们如果修改了bios中的apm相关代码并且没有处理好保护模式接口的问题，可以出现这样的情况：在实模式DOS下使用apm功能一切正常，但是在Linux下调用apm功能发生内核一般保护性错误。

在Linux下我们可以通过对apm_bios设备的操作来完成同样的功能。

下面的代码可以实现APM的suspend功能，等价于apm -s

#include #include #include #include #include #include #include ”apm.h“int main{ int fd, res; fd = open(”/dev/apm_bios“, O_RDWR); if (fd < 0) { printf(”open /dev/apm_bios error!\n“); exit(-1); } sync(); res = ioctl(fd, APM_IOC_SUSPEND, NULL); if (res != 0) { printf(”ioctl error!\n"); close(fd); exit(-1); } close(fd); return 0;}

如果我们把上面程序中的SUSPEND改成STANDBY，我们就同样实现了apm -S的功能。

在Linux下POWEROFF操作有其独特的流程，最后根据内核中apm或者acpi的存在情况来执行相应不同的流程来关闭电源。请参见Linux内核源码，我写的《linux关机重启流程分析》中也有一定的介绍。

6.常见问题(FAQ)

1)我的系统不能被suspend，这是怎么回事呢？

系统在suspend之前会向所有的驱动发消息，如果这个时候某个傲慢的驱动返回了一个-EBUSY，那么这次suspend的企图就被这个驱动否决了，你只有过一会再试，如果这个驱动总是否决(真是蛮横，不过它也许有自己的苦衷也说不定)，你就永远都无法suspend了。

2)我按下系统的POWEROFF开关，在ATX的主板上，系统就会自动关机了，这个处理流程是什么样子的呢？

在内核APM模块中建立了一个核心态线程不停的监测系统状态，用户的关机动作在这里被截获后处理。详细的流程可以参见本人的《linux关机重启流程分析》。

3)Linux中电源管理的文档在哪里？

在Linux/Documentation目录下的pm.txt中详细定义了Linux驱动电源管理接口实现方式，并且有详细的例子，apm和acpi的实现流程需要参见Linux源码的实现。

Linux中的电源管理是发展中的代码。从目前的趋势来看ACPI终将取代APM。现在使用APM则是较为成熟和稳妥的方案。我们如果现在编写驱动应该严格遵守文档中的pm.txt所规定的接口，这样可以使我们的驱动有较强电源管理的适应性和稳定性。

篇5：临时电源管理标准

XX第一热电厂企业标准

临时电源管理标准

1 主题内容与适用范围

本标准规定了XX第一热电厂临时电源的管理内容与要求、检查与考核，

本标准适用于XX第一热电厂临时电源的管理工作。

2 引用标准

《电业安全工作规程》

3 管理内容与要求

3.1 加强临时电源管理

3.1.1 临时电源管理以生产技术部下发的《设备管理划分规定》进行设备分工管理。

3.1.2 现场设立专用临时电源盘，必须挂牌、编号，明确专人管理。

3.1.3 现场临时电源安装，必须由分管车间主任签发工作票，经电气运行值班人员许可，才能安装临时电源箱和电缆等电气设备;其它非电气专业人员不得随意乱接临时电源。

3.2 临时电源的安全措施要求

3.2.1 使用临时电源设备和线路的绝缘必须良好，

裸露的带电导体应该安装于碰不着的开关箱内，否则必须设置安全遮栏和明显的警告标志。

3.2.2 使用临时电源设备必须有可熔保险器或者自动开关.

3.2.3 3.2.4 发生大量蒸汽、气体、粉尘的工作场所，要使用密闭型电气设备;在制氧、乙炔、油

泵房或者粉尘大的工作场所，要使用防爆型电气设备。

3.2.4 装设的临时电源至少一个月全面检修维护一次。

3.2.5 现场施工作业用临时电源线应使用软皮电缆线;如需使用花线时，应用木杆悬空架设，否则不准使用。

3.2.6 临时电源线不能用勾挂、缠绕等方法连接，严禁使用塑料线。

3.2.7 临时电源线必须远离电、火焊作业点的热体。

4 检查与考核

4.1 本制度由主管厂领导负责检查。

4.2 本制度按《XX第一热电厂安全奖惩考核办法》进行考核。

附加说明

本标准由标准化办公室负责提出

本标准由安全监察部负责制定

本标准主要起草人：

审核:

审定:

批准:

本标准由安全监察部负责解释

篇6：如何快捷管理Android通话记录

管理Android通话记录 Android通话记录非常方便，

长按任意一条播出或者接入电话记录就可以选择删除，非常easy，

如何快捷管理Android通话记录

，

篇7：Android中进程管理

在android中，进程这个概念被淡化了，我们知道Android的每一个应用都是运行在一个独立的DVM中，他们之间互不影响；应用退出之后，并没有立马杀死进程，进程依然停留在内存中，这么做的目的是为了提高下次启动时的速度，而在Android中管理进程的模块是AMS，主要有LRU weight,OOM adj,Low Memory Killer共同来完成进程的管理。

1 LRU weightLRU(最近最少使用)weight 主要用来衡量LRU的权重，在android进程启动之后，会以ProcessRecord类型的方式创建一个实例，保存到AMS的mLruProcesses变量中，mLurProcesses会以LRU的顺序来存储进程信息。当有一下情况时会更新mLruProcesses: 1.应用程序异常退出 2.调用AMS显式杀死进程 3.启动和调度四大组件这里以启动和调度四大组件为例，它最终会调用AMS的updateLruProcessLock方法:

final void updateLruProcessLocked(ProcessRecord app,boolean oomAdj, boolean updateActivityTime) { mLruSeq++;//lru序号加一 updateLruProcessInternalLocked(app, oomAdj, updateActivityTime, 0); }

先将LRU序号加一，用于标记一次更新LRU的操作，然后调用updateLruProcessInternalLocked:

private final void updateLruProcessInternalLocked(ProcessRecord app,boolean oomAdj, boolean updateActivityTime, int bestPos) { // put it on the LRU to keep track of when it should be exited. int lrui = mLruProcesses.indexOf(app); if (lrui >= 0) mLruProcesses.remove(lrui); int i = mLruProcesses.size-1; int skipTop = 0; app.lruSeq = mLruSeq; // compute the new weight for this process. if (updateActivityTime) {app.lastActivityTime = SystemClock.uptimeMillis(); } if (app.activities.size() >0) {// If this process has activities, we more strongly want to keep// it around.app.lruWeight = app.lastActivityTime; } else if (app.pubProviders.size() >0) {// If this process contains content providers, we want to keep// it a little more strongly.app.lruWeight = app.lastActivityTime - ProcessList.CONTENT_APP_IDLE_OFFSET;// Also don't let it kick out the first few real hidden processes.skipTop = ProcessList.MIN_HIDDEN_APPS; } else {// If this process doesn't have activities, we less strongly// want to keep it around, and generally want to avoid getting// in front of any very recently used activities.app.lruWeight = app.lastActivityTime - ProcessList.EMPTY_APP_IDLE_OFFSET;// Also don't let it kick out the first few real hidden processes.skipTop = ProcessList.MIN_HIDDEN_APPS; } while (i >= 0) {ProcessRecord p = mLruProcesses.get(i);// If this app shouldn't be in front of the first N background// apps, then skip over that many that are currently hidden.if (skipTop >0 && p.setAdj >= ProcessList.HIDDEN_APP_MIN_ADJ) { skipTop--;}if (p.lruWeight <= app.lruWeight || i < bestPos) { mLruProcesses.add(i+1, app);//添加到mLruProcesses合适的位置 break;}i--; } if (i < 0) {mLruProcesses.add(0, app); } // 如果这个进程之后总有cotent provider或者Service，重新计算 // If the app is currently using a content provider or service, // bump those processes as well. if (app.connections.size() >0) {for (ConnectionRecord cr : app.connections) { if (cr.binding != null && cr.binding.service != null&& cr.binding.service.app != null&& cr.binding.service.app.lruSeq != mLruSeq) { updateLruProcessInternalLocked(cr.binding.service.app, oomAdj,updateActivityTime, i+1); }} } if (app.conProviders.size() >0) {for (ContentProviderRecord cpr : app.conProviders.keySet()) { if (cpr.proc != null && cpr.proc.lruSeq != mLruSeq) { updateLruProcessInternalLocked(cpr.proc, oomAdj, updateActivityTime, i+1); }} } if (oomAdj) {updateOomAdjLocked();调用updateOomAdjLocked 更新oom adj值 } }

这个函数主要作用 1.为该进程计算LRU序列号和LRU weight 2.根据计算出来的LRU weight，将该进程信息插入到mLRUProcesses合适的位置之中 3.如果该进程之中有content provider或者service，重新计算LRU weight 4.判断是否需要调用updateOomAdjLocked函数来更新oom adj的值

到此为止updateLruProcessLocked结束，可以看出，这个函数只是调整进程的LRU weight和在mLruProcesses中的位置，并没有直接参与进程的管理，真正参与进程管理的是updateOomAdjLocked函数，这个函数用来更新oom adj的值，这个值影响着进程的回收

2 OOM adjOOM adj 定义了一系列的OOM的调整级别，从-17到15。在Low Memory Killer机制中已经介绍过，这里看一下Android中定义了13个调整级别,在ProcessList文件中

class ProcessList { // OOM adjustments for processes in various states: // This is a process without anything currently running in it. Definitely // the first to go! Value set in system/rootdir/init.rc on startup. // This value is initalized in the constructor, careful when refering to // this static variable externally. static final int EMPTY_APP_ADJ = 15; // This is a process only hosting activities that are not visible, // so it can be killed without any disruption. Value set in // system/rootdir/init.rc on startup. static final int HIDDEN_APP_MAX_ADJ = 15; static int HIDDEN_APP_MIN_ADJ = 7; // This is a process holding the home application -- we want to try // avoiding killing it, even if it would normally be in the background, // because the user interacts with it so much. static final int HOME_APP_ADJ = 6; // This is a process holding a secondary server -- killing it will not // have much of an impact as far as the user is concerned. Value set in // system/rootdir/init.rc on startup. static final int SECONDARY_SERVER_ADJ = 5; // This is a process currently hosting a backup operation. Killing it // is not entirely fatal but is generally a bad idea. static final int BACKUP_APP_ADJ = 4; // This is a process with a heavy-weight application. It is in the // background, but we want to try to avoid killing it. Value set in // system/rootdir/init.rc on startup. static final int HEAVY_WEIGHT_APP_ADJ = 3; // This is a process only hosting components that are perceptible to the // user, and we really want to avoid killing them, but they are not // immediately visible. An example is background music playback. Value set in // system/rootdir/init.rc on startup. static final int PERCEPTIBLE_APP_ADJ = 2; // This is a process only hosting activities that are visible to the // user, so we'd prefer they don't disappear. Value set in // system/rootdir/init.rc on startup. static final int VISIBLE_APP_ADJ = 1; // This is the process running the current foreground app. We'd really // rather not kill it! Value set in system/rootdir/init.rc on startup. static final int FOREGROUND_APP_ADJ = 0; // This is a process running a core server, such as telephony. Definitely // don't want to kill it, but doing so is not completely fatal. static final int CORE_SERVER_ADJ = -12; // The system process runs at the default adjustment. static final int SYSTEM_ADJ = -16; .....}

AMS提供了函数来改变这个值:updateOomAdjLocked

final void updateOomAdjLocked() { final ActivityRecord TOP_ACT = resumedAppLocked(); final ProcessRecord TOP_APP = TOP_ACT != null ? TOP_ACT.app : null; if (false) {RuntimeException e = new RuntimeException();e.fillInStackTrace();Slog.i(TAG, updateOomAdj: top= + TOP_ACT, e); } mAdjSeq++; // Let's determine how many processes we have running vs. // how many slots we have for background processes; we may want // to put multiple processes in a slot of there are enough of // them. int numSlots = ProcessList.HIDDEN_APP_MAX_ADJ - ProcessList.HIDDEN_APP_MIN_ADJ + 1; int factor = (mLruProcesses.size()-4)/numSlots; if (factor < 1) factor = 1; int step = 0; int numHidden = 0; // First update the OOM adjustment for each of the // application processes based on their current state. int i = mLruProcesses.size(); int curHiddenAdj = ProcessList.HIDDEN_APP_MIN_ADJ; int numBg = 0; while (i >0) {i--;ProcessRecord app = mLruProcesses.get(i);//Slog.i(TAG, OOM + app + : cur hidden= + curHiddenAdj); //调用重载函数updateOomAdjLocked，更新OOM adj的值updateOomAdjLocked(app, curHiddenAdj, TOP_APP);if (curHiddenAdj < ProcessList.EMPTY_APP_ADJ && app.curAdj == curHiddenAdj) { step++; if (step >= factor) { step = 0; curHiddenAdj++; }}if (!app.killedBackground) { // 如果adj的值大于等于ProcessList.HIDDEN_APP_MIN_ADJ if (app.curAdj >= ProcessList.HIDDEN_APP_MIN_ADJ) { numHidden++; if (numHidden >mProcessLimit) {Slog.i(TAG, No longer want + app.processName + (pid + app.pid + ): hidden # + numHidden);EventLog.writeEvent(EventLogTags.AM_KILL, app.pid, app.processName, app.setAdj, too many background);app.killedBackground = true;Process.killProcessQuiet(app.pid);//杀死进程 } else {numBg++; } } else if (app.curAdj >= ProcessList.HOME_APP_ADJ) { numBg++; }} } ...... }

其中调用了重载函数updateOomAdjLocked，具体代码如下:

private final boolean updateOomAdjLocked(ProcessRecord app, int hiddenAdj, ProcessRecord TOP_APP) { app.hiddenAdj = hiddenAdj; if (app.thread == null) {return false; } final boolean wasKeeping = app.keeping; boolean success = true; // 1调用computeOomAdjLocked方法计算oom adj的值 computeOomAdjLocked(app, hiddenAdj, TOP_APP, false); if (app.curRawAdj != app.setRawAdj) {if (false) { // Removing for now. Forcing GCs is not so useful anymore // with Dalvik, and the new memory level hint facility is // better for what we need to do these days. if (app.curRawAdj >ProcessList.FOREGROUND_APP_ADJ&& app.setRawAdj <= ProcessList.FOREGROUND_APP_ADJ) { // If this app is transitioning from foreground to // non-foreground, have it do a gc. scheduleAppGcLocked(app); } else if (app.curRawAdj >= ProcessList.HIDDEN_APP_MIN_ADJ&& app.setRawAdj < ProcessList.HIDDEN_APP_MIN_ADJ) { // Likewise do a gc when an app is moving in to the // background (such as a service stopping). scheduleAppGcLocked(app); }}if (wasKeeping && !app.keeping) { // This app is no longer something we want to keep. Note // its current wake lock time to later know to kill it if // it is not behaving well. BatteryStatsImpl stats = mBatteryStatsService.getActiveStatistics(); synchronized (stats) { app.lastWakeTime = stats.getProcessWakeTime(app.info.uid, app.pid, SystemClock.elapsedRealtime()); } app.lastCpuTime = app.curCpuTime;}app.setRawAdj = app.curRawAdj; } if (app.curAdj != app.setAdj) {// 2 调用setOomAdj来修改进程的oom adj的值 if (Process.setOomAdj(app.pid, app.curAdj)) { if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v( TAG, Set app + app.processName + oom adj to + app.curAdj + because + app.adjType); app.setAdj = app.curAdj;} else { success = false; Slog.w(TAG, Failed setting oom adj of + app + to + app.curAdj);} } if (app.setSchedGroup != app.curSchedGroup) {app.setSchedGroup = app.curSchedGroup;if (DEBUG_SWITCH || DEBUG_OOM_ADJ) Slog.v(TAG, Setting process group of + app.processName + to + app.curSchedGroup);if (app.waitingToKill != null && app.setSchedGroup == Process.THREAD_GROUP_BG_NONINTERACTIVE) { Slog.i(TAG, Killing + app.toShortString() + : + app.waitingToKill); EventLog.writeEvent(EventLogTags.AM_KILL, app.pid,app.processName, app.setAdj, app.waitingToKill); // 3 调用killProcessQuiet杀死进程 Process.killProcessQuiet(app.pid); success = false;} else { if (true) { long ldId = Binder.clearCallingIdentity(); try { // 4调用setProcessGroup修改进程的调度组 Process.setProcessGroup(app.pid, app.curSchedGroup); } catch (Exception e) {Slog.w(TAG, Failed setting process group of + app.pid + to + app.curSchedGroup);e.printStackTrace(); } finally {Binder.restoreCallingIdentity(oldId); } } else { if (app.thread != null) {try { app.thread.setSchedulingGroup(app.curSchedGroup);} catch (RemoteException e) {} } }} } return success; }

函数updateOomAdjLocked，更新OOM adj的值,这一部分的主要工作有: 1.调用computeOomAdjLocked方法计算oom adj的值，这个函数比较复杂，通过一系列的运算，计算出oom adj的值 2.调用setOomAdj来修改进程的oom adj的值，这个函数就是向进程的/proc/

/oom_adj文件写入计算出来的oom adj值 3.调用killProcessQuiet杀死进程 4.调用setProcessGroup修改进程的调度组这里主要看第三步killProcessQuiet，这个函数在Process.java文件中:

public static final void killProcessQuiet(int pid) { sendSignalQuiet(pid, SIGNAL_KILL); }调用了 sendSignalQuiet函数,这是一个native函数:

public static final native void sendSignalQuiet(int pid, int signal);对应的实现在android_util_Process.cpp文件中:

void android_os_Process_sendSignalQuiet(JNIEnv* env, jobject clazz, jint pid, jint sig){ if (pid >0) { kill(pid, sig);//杀死进程 }}到此为止进程杀死了,这种方式是直接杀死进程的方式，同样android还提供了一个被动杀死进程的机制 Low Memory Killer机制

3 Low Memory Killer机制这一机制的主要思想就是定义不同的oom adj级别，并为每一个级别指定最小剩余阈值，

当内存中可用内存小于该阈值时，就杀死所有等于或者大于该级别的进程，这部分参看 Low Memory Killer机制

篇8：怎样进行系统“电源管理”

电源管理的主要任务是设置电源方案，即指定系统空闲多长时间后关闭监视器或硬盘，从而延长设备的使用寿命。

[方法一]

第一步：在桌面上单击“开始”一“设置”一“控制面板”。

第二步：双击“电源管理”图标，缺省状态下，打开的是“电源使用方案”选项卡。

第三步：根据需要设置不同计算机状态的关闭或等待时间，并可选择其他需要的设置，多数情况下可采用系统缺省设置。

第四步：单击“应用”可以使修改生效。

第五步：单击“确定”使修改生效并关闭“电源管理”对话框。

[方法二]

第一步：在桌面上右键单击任意空白处，在弹出菜单中单击“属性”。

第二步：单击“屏幕保护”一“设置”，即打开“电源管理”对话框，根据需要设置，操作同方法一。

篇9：电源管理芯片power1208介绍

电源管理芯片power1208介绍

摘要：介绍莱迪思（Lattice）半导体公司推出的业界第一个混合信号的可编程逻辑器件Power1208的特征、结构和原理。该器件的特点就是用一颗芯片就可完成对现代集成电路板上复杂电源的管理。

关键词：可编程逻辑器件电源管理 Power1208

在对现代集成电路板的设计中，设计者们往往要使用一大堆的比较器、电阻器、电容器、定时器和逻辑器来实现对电路板电源的管理，而这样做的后果就是需要花费大量的时间和占用电路板的空间。而莱迪思半导体公司推出的ispPAC电源管理器Powr1208就用单颗芯片实现了对电路板电源定序和监控功能完全管理！而且要重新更改设计时，只要对器件的 E2CMOS® 配置内存重新编程就可以了。

首先我们先来了解一下莱迪思公司电源管理器系列产品（见表1）：

表1

器件

供电传感输入

监督信号输出

MOS场效应管驱动器

封装

ispPAC-POWR1208

44-引脚 TQFP

ispPAC-POWR604

44-引脚 TQFP

其中他们的输出节点各为8个和4个。

一． Power1208结构说明

Powr1208它综合了可编程逻辑和模拟的特性，如图1.0 就是其基本组成框图。

它由六部分组成：供电监控，场效应管驱动，可编程数字输出，可编程数字输入，可编程定时器，可编程时序和控制逻辑。每一部分的特点如下：

1. 供电监控

在供电监控这部分，它有12个精确的可编程门限比较器，每个比较器有192级，步长为1%，精度为0.9%。每个比较器都含有一个低频干扰滤波器，而且每个比较器件都有一个在芯片的精度参考。

2. 驱动场效应管

该部分它含有有4个可编程的高压电泵驱动器，每个驱动器的电流可设置成从0.5uA到50uA的32个不同的值，电压从8V到12V的8个不同的值。而且在这部分其HVout引脚可单独设置成开路模式以驱动逻辑电平信号。

3. 可编程数字输出

这部分它提供了4个用于监控和报警的开路输出。

4. 可编程数字输入

这个部分它提供的'是4个用于去噪音的数字输入。

5. 可编程定时器

Powr1208它有一个以250KHz频率工作的内置振荡器，并且提供32us到524ms的延时。

6. 可编程时序和控制逻辑

这部分它提供的相当于一个含有16个宏单元的CPLD，而且每个宏单元可达到80个乘积项。

二．Power1208功能说明

首先它无需添加分立的元件就可以精确的同时监控多个电源。在供电时序方面，其输出可以在可控的斜率下驱动MOS场效应管或击活电源模块和LDO。在跟踪方面，它能提供上斜下斜或平稳启动并提供过压保护。在产生监控信号方面，其输出可作为CPU复位，电源正常指示或供电中断信号。在数字输入部分，它可用来做系统级的控制信号，如系统复位，面板关闭或其它组合逻辑。定时器方面，它可用来做可控的延时和监视时钟的功能。

所以综合起来，Powr1208的功能如下：

（1）第一个可编程模拟 + 数字的解决方案！

（2）耐用的 CPLD 有效实现定序、监控和监督信号逻辑

（3）可编程的模拟输入门限同时监控标准的和非标准的供电电压

（4）可编程的时延定时器（32µs 到 524ms）灵活控制时间

（5）250 kHz 的内部振荡器在芯片产生时钟

（6）MOS 场效应管驱动器的高电压输出控制供电电源的斜坡率

（7）LVTTL/LVCMOS 输入和开漏极输出（逻辑 I/O）用于产生监督信号和实现控制功能

（8）通过 E2COMS 配置存储器实现的 JTAG 在系统可编程能力

（9）灵活、有效地跟踪电源

基于上述的功能，所以Powr1208就可以非常方便对低于等于含有8个供电节点的面板进行管理。

图2.0是Powr1208应用的示意图