随笔

一 拖慢系统Solution
1-1 避免使用静态声明的BroadcastReceiver尽可能的动态注册


1-2 不在需要时禁用静态Receiver（PackageManager.setComponentEnabledSetting(componentName, newState, flags);）


1-3 lazy初始化,分离的UI初始化（利用ActivityLiftCycleCallbacks）


1-4 SyncAdapter、JobScheduler、GcmNetWorkManager


2  Background Services (内存消耗、GC、频繁被重启、Exception spam in LogCat)--Solution


2-1 独立于UI的后台进程
2-2 Object pool
2-3 改掉IDE自动生成的 try {} catch (Exception e) {// TODO Auto-generated catch blocke.printStackTrace();}


二 耗电


1当心Alarm 


1-1 确保targetSdkVersion >=19
1-2 务必使用可对齐的周期 15分钟、30分钟（INTERVAL XXX常亮）
1-3 wake up 与否，有讲究（non wakeup并不总是最佳选择）
1-4尽可能不要使用 Exact Alarm 


2 当心 WakeLock


2-1 RELEASE_WAKA_LOCK
2-2 及时释放
2-3 确保释放try{}finally{}
2-4 不要用作大文件的下载，使用DownloadManager下载
(你真的需要WakeLock吗 1 保持屏幕亮不需要WakeLock WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON 
2小数据的下载上传别惦记WakeLock加上必要的重试机制3大数据下载使用DownloadManager，大数据上传可能需要时WiFiLock)


3 当心后台持久服务
3-1 低端机内存回收，造成后台服务频繁重启，会大量耗电
3-2 被忽视的偷跑后台线程也会造成耗电
3-3 注册的各类回调在ACTION_SCREEN_OFF暂停
（你真的需要持久服务吗 1 SyncAdapter可能已经够用了 2 考虑使用短生命周期的后台服务Broadcast/Alarm+IntentService,选一个不用启动后台持久服务的通道如GCM）


4 当心传感器&定位请求
4-1 尽量使用一次请求避免持续监听
4-2 尽量使用网络定位，避免使用GPS
4-3 采集分析类传感器需求，尽可能采用XX采集机制（Android 4.4+）


5 第三方Push往往耗电
5-1 对比测试，慎用选择
5-2 抱他人大腿省自己的电
5-3 面向全球市场的app，优先选择Google Cloud Messaging
5-4 务必给用户关闭的机会
(你真的需要Push吗1 内容的实时性诉求你提供即时通信，社交网络，协作类工具？考虑使用SyncAdapter代替push 2用户主动迫切的需要获取内容？也许你需要是一个社交媒体账号比如微信公众号)