功耗和温升通常是Android系统的硬伤，尤其是结构空间有限的Android系统设备，比如用Android系统开发的手表设备。结构有限意味着能放的电池容量不会很大，导致待机时间变得特别短。
而且通常这种手表设备的在原始Android系统上，功耗比较正常，但内置一些功能应用后，功耗变得很大，待机时间特别短。下面是功耗分析的一般步骤：
遇到待机功耗偏高问题，分析步骤如下：
1.确定飞行模式下低电流是否正常？
正常情况飞行模式下待机电流在3-5mA;
不正常：给硬件和驱动分析解决；
2.若飞行模式正常，开始确认原生Launcher3的软件版本是否正常？（去掉一切客户预置的apk）
正常情况下Launcher3软件版本
4G模式待机电流10-13mA
2G/3G模式待机电流7-9mA
需要注意的是信号不好时会影响这个范围值；
若不正常：抓取mtklog分析；
3.若Launcher3软件正常，加上客户预置的WatchLauncher等apk后电流不正常？
抓取mtklog分析；
4.功耗异常mtklog分析方法：
一般应用层的功耗问题有以下种情况
一是某个应用持有唤醒锁未释放；
二是后台有网络访问行为发生;
三是定位调用GPS；
四是蓝牙WIFI搜索或扫描
五其他Sensor在后台持续工作如心率传感器。
4.1 首先确认是否正常待机
要确认CPU是否正常睡眠进入待机，需要查看PowerManagerService是否释放了所有持有的唤醒锁，如下：
查看sys_log
Line 3115: 01-01 00:05:14.731848 973 1003 D PowerManagerService: acquireWakeLockInternal: lock=256728484, flags=0x3000001a, tag="key_u_wake_lock", ws=null, uid=1000, pid=4287
Line 3137: 01-01 00:05:14.753272 973 1003 D PowerManagerNotifier: onWakeLockAcquired: flags=805306394, tag="key_u_wake_lock", packageName=android.fise.com.fiseassitant, ownerUid=1000, ownerPid=4287, workSource=null
Line 4344: 01-01 00:05:24.765232 973 2238 D PowerManagerService: releaseWakeLockInternal: lock=256728484 [key_u_wake_lock], flags=0x0, total_time=10033ms
Line 4345: 01-01 00:05:24.765673 973 2238 D PowerManagerNotifier: onWakeLockReleased: flags=805306394, tag="key_u_wake_lock", packageName=android.fise.com.fiseassitant, ownerUid=1000, ownerPid=4287, workSource=null
Line 6433: 01-01 00:05:43.614531 973 2910 D PowerManagerService: acquireWakeLockInternal: lock=23202550, flags=0x3000001a, tag="key_u_wake_lock", ws=null, uid=1000, pid=4287
Line 6452: 01-01 00:05:43.621134 973 2910 D PowerManagerNotifier: onWakeLockAcquired: flags=805306394, tag="key_u_wake_lock", packageName=android.fise.com.fiseassitant, ownerUid=1000, ownerPid=4287, workSource=null
如上如果灭屏后一段时间走了PowerManagerService: releaseWakeLockInternal方法且没有在走PowerManagerService: acquireWakeLockInternal
其中tag是持有或释放锁的名字，packageName是持有或释放该锁的进程。
这其中需要注意的是，测试功耗时先将时间同步到正常网络时间，并且灭屏1分钟后开始记下测试时间，精确到秒。再来对比log。
另外需要编译userdebug/eng版本才有PowerManagerServicelog输出,测试时只保留mobilelog开启，其他log都关闭。
4.2若CPU正常进入休眠，那说明有其他行为
网络访问行为需要查看mainlog，搜索关键字libc-netbsd 找到res_queryN后面的网址，如下，设备访问的每一个网址都会走这个方法：网址就是name = mepodownload.mediatek.com；
找到应用所访问的网址，再系统里整个搜索该网址名字，搜不到则是三方应用访问。如果搜出是系统所访问，则再仔细追踪为何会走到访问网络代码。
Line 1738: 01-01 00:00:09.832529 261 2119 D libc-netbsd: res_queryN name = mepodownload.mediatek.com., class = 1, type = 1
Line 1944: 12-04 18:21:59.875462 261 3053 D libc-netbsd: res_queryN name = xcap.ims.mnc000.mcc460.pub.3gppnetwork.org, class = 1, type = 1
Line 1962: 12-04 18:21:59.910583 261 3060 D libc-netbsd: res_queryN name = device.jiajialife.com, class = 1, type = 1
Line 1983: 12-04 18:22:00.029618 261 3075 D libc-netbsd: res_queryN name = device.jiajialife.com, class = 1, type = 1
Line 1993: 12-04 18:22:00.086842 261 3084 D libc-netbsd: res_queryN name = asia.pool.ntp.org, class = 1, type = 1
Line 2007: 12-04 18:22:00.151345 261 3089 D libc-netbsd: res_queryN name = s.jpush.cn, class = 1, type = 1
Line 2031: 12-04 18:22:00.633921 261 3147 D libc-netbsd: res_queryN name = push5.adups.com, class = 1, type = 1
Line 2036: 12-04 18:22:00.697235 261 3053 D libc-netbsd: res_queryN name = xcap.ims.mnc000.mcc460.pub.3gppnetwork.org succeed
Line 2037: 12-04 18:22:00.697236 261 3060 D libc-netbsd: res_queryN name = device.jiajialife.com succeed
Line 2038: 12-04 18:22:00.697236 261 3075 D libc-netbsd: res_queryN name = device.jiajialife.com succeed
Line 2052: 12-04 18:22:01.004627 261 3172 D libc-netbsd: res_queryN name = hshh.org, class = 1, type = 1
Line 2064: 12-04 18:22:01.031378 261 3174 D libc-netbsd: res_queryN name = app-measurement.com, class = 1, type = 1
Line 2068: 12-04 18:22:01.075390 261 3084 D libc-netbsd: res_queryN name = asia.pool.ntp.org succeed
Line 2070: 12-04 18:22:01.538021 261 3089 D libc-netbsd: res_queryN name = s.jpush.cn succeed
Line 2071: 12-04 18:22:01.540837 261 3172 D libc-netbsd: res_queryN name = hshh.org succeed
Line 2072: 12-04 18:22:01.541703 261 3147 D libc-netbsd: res_queryN name = push5.adups.com succeed
Line 2078: 12-04 18:22:01.578749 261 3174 D libc-netbsd: res_queryN name = app-measurement.com succeed
Line 2090: 12-04 18:22:03.000968 261 3177 D libc-netbsd: res_queryN name = bsf.mnc000.mcc460.pub.3gppnetwork.org, class = 1, type = 1
Line 2099: 12-04 18:22:03.978395 261 3177 D libc-netbsd: res_queryN name = bsf.mnc000.mcc460.pub.3gppnetwork.org succeed
Line 2116: 12-04 18:22:09.304616 261 3209 D libc-netbsd: res_queryN name = stats.jpush.cn, class = 1, type = 1
Line 2120: 12-04 18:22:09.738866 261 3209 D libc-netbsd: res_queryN name = stats.jpush.cn succeed
Line 2135: 12-04 18:22:10.544604 261 3211 D libc-netbsd: res_queryN name = t1.hshh.org, class = 1, type = 1
Line 2141: 12-04 18:22:11.455542 261 3211 D libc-netbsd: res_queryN name = t1.hshh.org succeed
Line 2153: 12-04 18:22:13.353241 261 3215 D libc-netbsd: res_queryN name = hshh.org, class = 1, type = 1
Line 2154: 12-04 18:22:13.353320 261 3215 D libc-netbsd: res_queryN name = hshh.org succeed
Line 2166: 12-04 18:22:14.875000 261 3219 D libc-netbsd: res_queryN name = stats.jpush.cn, class = 1, type = 1
Line 2167: 12-04 18:22:14.875085 261 3219 D libc-netbsd: res_queryN name = stats.jpush.cn succeed
Line 2208: 12-04 18:22:17.129304 261 3234 D libc-netbsd: res_queryN name = supl.google.com, class = 1, type = 1
Line 2212: 12-04 18:22:18.877794 261 3234 D libc-netbsd: res_queryN name = supl.google.com succeed
Line 2236: 12-04 18:22:22.354728 261 3238 D libc-netbsd: res_queryN name = t1.hshh.org, class = 1, type = 1
Line 2237: 12-04 18:22:22.354806 261 3238 D libc-netbsd: res_queryN name = t1.hshh.org succeed
Line 2266: 12-04 18:22:25.201207 261 3317 D libc-netbsd: res_queryN name = push5.adups.com, class = 1, type = 1
Line 2267: 12-04 18:22:25.201321 261 3317 D libc-netbsd: res_queryN name = push5.adups.com succeed
Line 2308: 12-04 18:22:28.354897 261 3387 D libc-netbsd: res_queryN name = imtt.dd.qq.com, class = 1, type = 1
Line 2323: 12-04 18:22:28.372317 261 3389 D libc-netbsd: res_queryN name = stats.jpush.cn, class = 1, type = 1
Line 2324: 12-04 18:22:28.372513 261 3389 D libc-netbsd: res_queryN name = stats.jpush.cn succeed
如果看到自己的log res_queryN name = 后面没有名字输出，那说明你的代码是Android O以后的，可以去bionic/libc/dns/net/getaddrinfo.c
里面修改打印方法：
res_queryN(){
.....
if (LOAD_IS_USER)
debug_log("res_queryN succeed");
else
debug_log("res_queryN name = %s succeed", name);
return ancount;
改为：
if (LOAD_IS_USER)
debug_log("res_queryN name = %s succeed", name);
else
debug_log("res_queryN name = %s succeed", name);
return ancount;
这样再编译，访问的所有网址域名都能打印出来了。
4.3CPU正常，网络也没访问，则查看GPS定位是否有持续
定位直接搜索Location关键字，可以搜出
开始定位log：可以得到是gps定位还是network定位，是哪个应用调用了定位等信息。
083004 05-12 09:50:00.510 827 1468 D LocationManagerService: request 1434db9 gps Request[ACCURACY_FINE gps requested=+10s0ms fastest=+10s0ms] from com.tct.weather(10052)//是哪个应用定位。
结束定位log：
108716 05-12 09:50:31.004 827 1468 I LocationManagerService: remove 1434db9
这句log打印在LocationManagerService.java的requestLocationUpdatesLocked方法中，user版本不会输出，可以将log级别调到e级。
4.4如果CPU正常待机，没有使用网络，没有定位，功耗还是挺不正常，那可以想想是否有使用蓝牙功能，若有
搜索startLeScan字样，这里是确定使用的是蓝牙4.0或以上。
2324: 12-04 18:22:28.372513 261 3389 D BluetoothAdapter: startLeScan(): 00000000-0000-1000-8000-00805F9B34FB
然后看多久扫描一次，是不是频繁在扫描。
4.5如果蓝牙也正常，则看看是否有一些后台测试类的Sensor，如心率，血压等。计步的GSensor可以忽略，这个比较成熟消耗功耗比较少。
这个只能自己看自己的监听代码，是否睡眠后还在监听着Sensor。
找到功耗的引起的原因，有时候也不一定能优化好，比如找到是定位，但是定位必须要那么短间隔定位一次，那也没法进行优化。
不过知道每一部分功耗消耗在哪里，我们作为软件工程师也能够向客户交代，每一部分功耗消耗在哪里。
常规功耗优化手段：
1.访问数据网络间隔尽量加长，减少访问量：比如如果和服务器后台有连接，可以减少发送数据包，心跳包等。
2.尽量加长定位间隔：比如5分钟一次改为10分钟一次等。
3.用户不操作时可以将网络切换到2G或3G去待机，晚上半夜期间甚至可以判断用户未使用时然后开启分析模式。-------这个效果比较好。
基本上所有软件层功耗问题，通过以上步骤都可以得到解决。若有遗漏，请大家补充。
