android唤醒,android唤醒和休眠

在Android系统上启动知乎app时会唤醒微信是什么原因？

知乎调用微信sdk中分享的相关接口，微信sdk的相关接口里面，给微信发送了一个广播，微信app就被唤醒了，这不是知乎的主观行为，而是微信的（而且结合实际的分析来看，这个应该也算是正常的功能）。

十载的石鼓网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整石鼓建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联建站从事“石鼓网站设计”,“石鼓网站推广”以来，每个客户项目都认真落实执行。

1首先说一下app的被唤醒（自启动）机制。

app自启动，基本上都是依靠Android的广播来实现的，而且是静态注册的广播（在AndroidManifest.xml文件中进行配置的广播），发送广播的方法在一般情况下是sendBroadcast。

2按照惯例，反编译一下微信apk，然后搜索一下它能够由哪些静态广播进行唤醒，同时抓取广播相关的log。

结合微信的AndroidManifest.xml文件以及抓取的log，可以知道相关的BroadcastReceiver是EntryReceiver，相关的action为

com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_REGISTER

com.tencent.mm.plugin.openapi.Intent.ACTION_HANDLE_APP_UNREGISTER

从其名称上看，是和注册/注销相关,具体接收到广播之后做了哪些处理，这些就不赘述了。

3接下来分析知乎的代码,搜索一下知乎反编译之后的smali文件(sendBroadcast),其中只有一条是和微信相关的

Android-让设备保持唤醒（激活）状态

为了避免电池尿崩，Android会在没有任务的时候快速进入睡眠状态。然而有时候应用需要保持激活状态。

你的需求决定了你选择的方法。一般来说，尽可能选择尽量轻量的方法满足你的需求。下面几个选项讲述了如何选择这些方法。

attribute:

简而言之，通过设置 FLAG_KEEP_SCREEN_ON 标记来是屏幕保持常亮，这是一种比较轻量级的方法，系统会根据App是否在前台决定这个设置是否生效，如果是一般阅读类App，电影App推荐使用这个。

To release the wake lock, call wakelock.release() . This releases your claim to the CPU. It's important to release a wake lock as soon as your app is finished using it to avoid draining the battery.

使用WAKE_LOCK保持CPU运算，但是一般不推荐使用，除非你有非要完成的任务。绝对不要在Activity中使用，一般在Service中使用即可。具体使用方法已经很清楚了，不译了。

android app被杀死 alarmmanager能不能唤醒

可以唤醒的，但是得需要注意设置进程属性。

在Android中，AlarmManager提供了不受休眠状态的系统定时功能，其一般使用方法如下。

1、创建一个BroadcastReceiver类的子类，接收定时器事件：

public class MyReceiver extends BroadcastReceiver {

......

}

2、在AndroidMenifest.xml中定义上述广播事件接收类的定义：

receiver android:name=".MyReceiver"

/receiver

3、在程序中在需要时设置定时器：

Intent intent = new Intent(context,MyReceiver.class);

PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);

AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);

alarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP , SystemClock.elapsedRealtime() + ms, pendingIntent);

经过ms毫秒之后，MyReceiver会被调用，从而实现定时触发。

Android 休眠唤醒频繁问题分析的一些工具

大家都知道目前的手机，平板等电子设备耗电都比较大，Android系统因为历史和开源等原因，一直对耗电支持的不是很好。特别现在很多apk完全不care耗电，动不动给你装上全家桶，还会相互间互相唤醒进程，简直就是流氓软件。从现有的应用来说，为了他们商业目的，有很多是类似要求长期后台运行的，或者定时运行的，这些服务对耗电影响都非常大。

虽然Android每次版本大更新，都对其进行了优化，加入了很多特性。比如在Android 5.0加入了JobScheduler API机制（批处理）；在Android 6.0加入App Standby（应用待机），Doze休眠机制;并且在Android7.0谷歌对Doze休眠机制做了进一步的优化，只要手动在后台删掉应用卡片，关屏后该应用就会被很快深度休眠。

但是应用开发工程师由于各种原因没有使用新的特性，导致用户感觉设备耗电还是很大。所以国内很多手机厂家都有对android系统的耗电进行优化，从原理来说，目前这些厂家也是主要对两方面进行优化：

1.减少定时休眠唤醒频率，比如合并应用申请的定时唤醒闹钟来唤醒已经休眠的设备。

2.减少wake lock的频率和时间。只要系统中存在任一有效的wake_lock，系统就不能进入深度休眠，但可以进行设备的浅度休眠操作。wake_lock一般在关闭lcd、tp但系统仍然需要正常运行的情况下使用，比如听歌、传输很大的文件等。

可通过如下打印来确认唤醒源：

4[ 1321.989235] wakeup gpio0: 00000010

具体意思如下：

gpio0：表示是GPIO0

00000010：表示的是GPIO分组从高到低四个字节分别是：DCBA，每个字节的0-7bit就表示D7-D0  C7-C0  B7-B0  A7-A0.

从这里可以看出上面唤醒的GPIO是：GPIO0 PA4，对应的是RTC的中断脚。

通过dumpsys alarm命令打印可以看到哪个应用唤醒次数比较多，和总共占用的时间：

这里的唤醒统计的是：应用申请 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 的Alarm。不管系统是否在休眠，都会产生Alarm，所以这里的Alarm次数与第一章中说的kernel中统计的被RTC中断唤醒的次数是匹配不上的，前都会大于后者。

看下Android系统定义的休眠唤醒不同的类型。

这个信息可以通过Project Volta里的工具historian.py将其图形化显示。

先导出bugreport

将其转换成图形化结果（目前好像只有百度浏览器才能打开这个html）

简单说明如下：

1.横轴是时间

2. wifi_scan指的是wifi处于扫描

3. wifi_running指的是wifi打开状态

4. screen指的是屏亮的状态

5. plugged指的是插入外设

6. wake_lock指的是kernel中被锁住的状态

可通过screen与wake_lock来初步确认系统是否被唤醒，如果screen是关的，然后又有wake_lock，也表明系统被唤醒并被锁住一段时间。

把上层的唤醒和wifi唤醒都关了，测试了39个小时消耗30%电量

有以下几个问题：

1.唤醒次数的确少了，但是healthd每10分钟唤醒在图上体现不出来

2.有2次唤醒后，系统被锁住10多钟才休眠下去

查看Alarm状态，可以很明显看到上层没有再去wake up

但是驱动中还看到有被RTC唤醒，经过验证是healthd唤醒的，不插充电的时候10分钟，插充电的时候1分钟间隔。这个唤醒后就更新battery的信息，上层Baterry更新下，UI刷新下。

系统被锁住10几分钟，通过log分析在wifi断开的时候，gms刚好去连接服务器，通讯很久造成wake 比较久。从下面的信息可以判断，系统目前wake lock线程最多的是gms线程。

Wake lock 在Android的电源管理系统中扮演一个核心的角色，wakelock是一种锁的机制, 只要有task拿着这个锁, 系统就无法进入休眠, 可以被用户态进程和内核线程获得。这个锁可以是有超时的或者是没有超时的, 超时的锁会在时间过去以后自动解锁。如果没有锁了或者超时了, 内核就会启动标准Linux的那套休眠机制机制来进入休眠。

提高电池续航，也就意味着减少系统和程序的电量消耗。为此 经过测试发现，每次唤醒设备，1-2秒的时候，都会消耗2分钟（个别应用更久）的待机电量，可见每次唤醒设备的时候，不仅仅是点亮了屏幕，系统也在后台处理很多事情。

电池消耗比较大，从系统的行为上分析，有两个地方影响最大

1.系统在被唤醒的期间，被一些应用wake lock比较久，造成很久时间无法再进入二级休眠。

2.系统频繁的被唤醒，系统被唤醒目前包含三个唤醒源

（1）.系统上层通过AlarmMananger的接口注册rtc唤醒，

（2）.wifi芯片自动唤醒，

（3）.电池healthd定频唤醒。

所以如果应用比较多的时候，应用在唤醒期间动作比较多，容易造成系统被wake lock，从而不会很快的进入二级休眠。

通过上述的分析来看，系统可以优化的地方有4个方面。

1).查看系统wake lock最多的线程，看能不能优化。

2).系统上层过滤的应用唤醒行为，从而降低唤醒频率。AlarmManager包含四种类型定时策略，AlarmManager.ELAPSED_REALTIME、AlarmManager.ELAPSED_REALTIME_WAKEUP、AlarmManager.RTC、AlarmManager.RTC_WAKEUP、AlarmManager.POWER_OFF_WAKEUP。

其中应用申请RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP的Alarm在系统休眠的情况下会唤醒系统。通过建立白名单或者黑名单的方式过滤此种应用的唤醒行为

3）. 定时批处理一批操作，压缩硬件唤醒时间，就像心跳一样，让硬件充分休息，还有就是精确监测应用请求，智能安排请求执行时间，让资源利用最大化。

4).扩大healthd的定频唤醒间隔（适度不然造成电池电量不准）

最后改一张调整过的电池状态图：