前言：现在市场上很多App装上之后发现手机变烫，每月流量猛增的问题。开篇前先讲一个不恰当的段子热热身吧：“某程序猿同时携带某米手机和某星手机过机场安检被抓了起来，被指怀疑其蓄意携带定时爆炸物”。
技术背景：能耗问题其实主要和App对CPU\GPU消耗使用率成一个比例关系的。我暂且总结为：电量消耗+流量消耗。其实这两者也是互相牵制的。
Ok，让我们从代软件开发者的角度来深入剖析一下。
电能消耗：
● 网络请求耗电：按照系统层次原理，使用4G网络远远比WIFI更耗电，因为手机网络需要调用更底层的硬件模块。还有一点在网络切换监听广播中代码注意精简，去除耗时过重的操作。
● UI页面嵌套太深、频繁刷新：Layout绘制的过程是经过一连串的计算最终渲染，如果开发者在编写的UI中嵌套太深很容易造成卡顿的同时还造成了电能的过于消耗。具体如何解决，可以看下我之前的文章：Android 性能优化系列－UI篇
● 频繁的IO、数据库操作：在短时间频繁读写会造成手机消耗大量电能。
● 定时任务：手机上的设置JOB非万不得已建议不要去尝试。如定时拉服务器数据，即便你用 AlarmManager也是一样，要不停的唤醒CPU执行任务，造成电量消耗。
● 数据传输、解析：尽量不要用XML解析交互，使用Json、 Protobuf 。数据压缩传输。避免频繁的进制转换等等。
● 定位服务：GPS打开后会不停的合理选择定位服务的方式，可以使用wifi定位、移动网络定位来取代GPS定位。按照实际场景
● WakeLock的不合理使用
● 对象回收：要记住手动回收对象有百里无一害。
流量消耗：
● 还是网络请求：请求频次过多，尽量减少请求报文大小，返回报文包大小。包括合理的网络请求缓存。
● 心跳包： 和服务端交互的定时心跳，尽量避免直接传输String。判断当前app是否在前台来调节频次。
● 拒绝轮询调用服务端接口。
● 推送频繁、内容过大：合理采用推送渠道，用业务字段id取代内容字符集。
● 文件下载：在确保大文件压缩前提下，合理使用内存、磁盘存储，避免重复下载。
● 无视了用户的网络环境：在业务允许下尽量区分当前是否是wifi状态，合理走流量。
总结：个人觉得整体的优化是一个协调复杂的过程，需要客户端、服务端，当然还会涉及到服务器的部署方式、产品的需求、业务运维的方式等等。
未完待续。。。（如何检查能耗及细节解决方案）
