android应用唤醒
‘壹’ Android 唤起QQ应用的正确方式
Intent intent =new Intent();
ComponentName cmp =new ComponentName("com.tencent.mobileqq", "com.tencent.mobileqq.activity.SplashActivity");
intent.setAction(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_LAUNCHER);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setComponent(cmp);
startActivity(intent);
com.tencent.qq.SplashActivity
com.tencent.mobileqq.activity.HomeActivity
正确包名：com.tencent.mobileqq.activity.SplashActivity
PackageManager packageManager =this.getPackageManager();
Intent intent= packageManager.getLaunchIntentForPackage("com.tencent.mobileqq");
startActivity(intent);
‘贰’ 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会被调用，从而实现定时触发。
‘叁’ 求安卓里应用唤醒和关联启动区别
应用唤醒是指此应用在后台（内存）常驻一接收器。当接收器收到相应指令时便会启动应用。关联启动是说此应用的开发者有可能在他开发的应用上动了手脚，在启动某一程序后，后台自动关联他的其他程序一起启动
‘肆’ 安卓12阻止app自动唤醒
安卓12关闭app自动唤醒
在我们进入手机应用启动管理界面之后，系统默认的是全部自动管理，自动管理将自动识别应用和使用场景，禁止应用不必要的启动。自动管理，不会影响新消息的接收；而手动管理需要用户选择应用和后台活动，相对固话点，但是效果要好很多。
另外，需要注意的是：在开启手动管理之前，要关闭掉所有应用的自动管理按钮，一般是在应用管理页面的右上角“三点”的标志，之后再手动批量管理、操作。
‘伍’ Android保活——蓝牙唤醒（主动kill掉也可唤醒）
项目需要后台保活，但无论怎么保活，只要用户主动kill掉，app依然是活不了。
发现了蓝牙唤醒这个方式，用户主动kill掉也可行。
Android 8.0开始提供了 startscan的方法，
public void startScan(ScanCallback callback)
public void startScan(List<ScanFilter> filters,ScanSettings settings,ScanCallback callback)
public int startScan(List<ScanFilter> filters,ScanSettings settings,PendingIntent callbackIntent)
第一个没有过滤条件，锁屏就停止扫描
第二个可以加过滤条件，锁屏不影响扫描
第三个的扫描结果由PendingIntent发送，即使app没有在运行，系统也可以扫描后唤醒app，这就是我们要的方法了。
PendingIntent是对Intent的封装，是满足某些条件或触发某些事件后才执行指定的行为，主要用于闹钟、通知、桌面部件。Android的四大组件之间通信用Intent，跨进程通信用PendingIntent。
Android 8.0 引进了Context.startForegroundService()，在系统创建服务后，应用需要在ANR发生前调用startForeground(int ,android.app.Notification)，如果未及时调用该方法，系统将报ANR错误 。系统给前台服务的ANR时间是20秒。
用startScan蓝牙唤醒的原理是：app向系统订阅了扫描结果（预先加了过滤条件），当蓝牙连接断开的时候，设备就会发广播，这时系统就可以扫描到对应的广播，唤醒对应的service，这时想做什么操作就根据你的项目需要了。至于系统会为你扫描多久，这个还没测试。
（1）setScanMode有四个参数可以选 ：
SCAN_MODE_BALANCED：在平衡电源模式下执行蓝牙LE扫描。返回扫描结果的速度能够很好地权衡扫描频率和功耗。
SCAN_MODE_LOW_LATENCY：扫描使用最高占空比。建议只在应用程序在前台运行时使用此模式。
SCAN_MODE_LOW_POWER：在低功耗模式下执行蓝牙LE扫描。这是默认的扫描模式，因为它消耗的能量最少。如果扫描应用程序不在前台，则强制执行此模式。
SCAN_MODE_OPPORTUNISTIC：一种特殊的蓝牙LE扫描模式。使用这种扫描模式的应用程序将被动地侦听其他扫描结果，而不启动BLE扫描本身
（2）settingBuilder.setMatchMode有两个参数可以选：
MATCH_MODE_AGGRESSIVE： 信号弱也会报告
MATCH_MODE_STICKY： 信号比较强和扫描到的次数比较多才会报告
（3)settingBuilder.setCallbackType也有其他参数可选，但适用的就一个
(4) ScanFilter 的过滤方法有几个,如下图，打勾的是测试了可行的，但只有第一个DeviceAddress有唯一性
‘陆’ Android 休眠唤醒频繁问题分析的一些工具
大家都知道目前的手机，平板等电子设备耗电都比较大，Android系统因为历史和开源等原因，一直对耗电支持的不是很好。特别现在很多apk完全不care耗电，动不动给你装上全家桶，还会相互间互相唤醒进程，简直就是流氓软件。从现有的应用来说，为了他们商业目的，有很多是类似要求长期后台运行的，或者定时运行的，这些服务对耗电影响都非常大。
虽然Android每次版本大更新，都对其进行了优化，加入了很多特性。比如在Android 5.0加入了JobScheler 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的中断脚。
通过mpsys 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的定频唤醒间隔（适度不然造成电池电量不准）
最后改一张调整过的电池状态图：
‘柒’ Android上某应用唤醒另一应用的方式有多少种
进程中线程同步的四种常用方式：
1、 临界区（CCriticalSection）
当多个线程访问一个独占性共享资源时，可以使用临界区对象。拥有临界区的线程可以访问被保护起来的资源或代码段，其他线程若想访问，则被挂起，直到拥有临界区的线程放弃临界区为止。具体应用方式：
1、 定义临界区对象CcriticalSection g_CriticalSection;
2、 在访问共享资源（代码或变量）之前，先获得临界区对象，g_CriticalSection.Lock（）；
3、 访问共享资源后，则放弃临界区对象，g_CriticalSection.Unlock（）；
2、 事件（CEvent）
事件机制，则允许一个线程在处理完一个任务后，主动唤醒另外一个线程执行任务。比如在某些网络应用程序中，一个线程如A负责侦听通信端口，另外一个线程B负责更新用户数据，利用事件机制，则线程A可以通知线程B何时更新用户数据。每个Cevent对象可以有两种状态：有信号状态和无信号状态。Cevent类对象有两种类型：人工事件和自动事件。
自动事件对象，在被至少一个线程释放后自动返回到无信号状态；
人工事件对象，获得信号后，释放可利用线程，但直到调用成员函数ReSet()才将其设置为无信号状态。在创建Cevent对象时，默认创建的是自动事件。
1、1234CEvent(BOOL bInitiallyOwn=FALSE, BOOL bManualReset=FALSE, LPCTSTR lpszName=NULL, LPSECURITY_ATTRIBUTES lpsaAttribute=NULL);
bInitiallyOwn:指定事件对象初始化状态，TRUE为有信号，FALSE为无信号；
bManualReset：指定要创建的事件是属于人工事件还是自动事件。TRUE为人工事件，FALSE为自动事件；
后两个参数一般设为NULL，在此不作过多说明。
2、BOOL CEvent：：SetEvent();
将Cevent类对象的状态设置为有信号状态。如果事件是人工事件，则Cevent类对象保持为有信号状态，直到调用成员函数ResetEvent()将其重新设为无信号状态时为止。如果为自动事件，则在SetEvent（）后将事件设置为有信号状态，由系统自动重置为无信号状态。
3、BOOL CEvent：：ResetEvent();
将事件的状态设置为无信号状态，并保持该状态直至SetEvent（）被调用为止。由于自动事件是由系统自动重置，故自动事件不需要调用该函数。
一般通过调用WaitForSingleObject（）函数来监视事件状态。
3、 互斥量（CMutex）
互斥对象和临界区对象非常相似，只是其允许在进程间使用，而临界区只限制与同一进程的各个线程之间使用，
但是更节省资源，更有效率。
4、 信号量（CSemphore）
当需要一个计数器来限制可以使用某共享资源的线程数目时，可以使用“信号量”对象。CSemaphore类对象保存了对当前访问某一个指定资源的线程的计数值，该计数值是当前还可以使用该资源的线程数目。如果这个计数达到了零，则所有对这个CSemaphore类对象所控制的资源的访问尝试都被放入到一个队列中等待，直到超时或计数值不为零为止。
CSemaphore(
LONG lInitialCount = 1,
LONG lMaxCount = 1,
LPCTSTR pstrName = NULL,
LPSECURITY_ATTRIBUTES lpsaAttributes = NULL
);
lInitialCount:信号量对象的初始计数值，即可访问线程数目的初始值；
lMaxCount：信号量对象计数值的最大值，该参数决定了同一时刻可访问由信号量保护的资源的线程最大数目；
后两个参数在同一进程中使用一般为NULL，不作过多讨论；
一般是将当前可用资源计数设置为最大资源计数，每增加一个线程对共享资源的访问，当前可用资源计数就减1，只要当前可用资源计数大于0，就可以发出信号量信号。如果为0，则放入一个队列中等待。线程在处理完共享资源后，应在离开的同时通过ReleaseSemaphore（）函数将当前可用资源数加1。
BOOL ReleaseSemaphore( HANDLE hSemaphore, // hSemaphore:信号量句柄
LONG lReleaseCount, // lReleaseCount：信号量计数值
LPLONG lpPreviousCount // 参数一般为NULL);
‘捌’ 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时会唤醒微信是什么原因
知乎调用微信sdk中分享的相关接口，微信sdk的相关接口里面，给微信发送了一个广播，微信app就被唤醒了，这不是知乎的主观行为，而是微信的（而且结合实际的分析来看，这个应该也算是正常的功能）。