优秀的体验来自于优秀的性能
优秀的体验来自于优秀的性能，而优秀的性能无非就是从这么几个方面着手：降低耗电量、减少CPU使用、CPU使用均衡、及时回收内存、避免频繁GC、使设备及时休眠。
这里列举一些具体实施时的切入点。
AlarmManager
不要不做限制地使用定时器，要根据场景选择性地注册并及时注销定时器。比如，依赖网络条件的应该使用SyncAdapter；用户注销后，记得注销定时器等。
另外，定时器的周期最好控制在15分钟以上，这个是Android官方给出的经验值，再频繁的话，对待机电量消耗的影响就会明显变大了。
关于定时器的模式。wakeup的好处是可以对用户关心的状态及时更新，但会打断机器休眠，如果很频繁的话，会使用机器睡不下去，耗电量明显上升。非wakeup的好处就是比较省电，但会把所有的任务集中到用户唤醒机器的那一刹那来执行，从而造成用户唤醒机器时的卡顿。
Wake Lock
除了像视频播放这种即使用户长时间不操作也需要保持在前台的程序，实质上很少有申请Wake Lock的需求。另外，一旦程序退出前台，记得释放。
Broadcast
通过AndroidManifest.xml静态声明的全局广播接收器是耗电大户。可能会有很多程序注册像“网络状态改变”、“电话状态”、“设置解锁”等常见事件。那么，在这些事件发生时会触发多个进程创建，频繁的GC，卡顿也就来了。所以，请尽量使用动态注册。
另外，“网络状态改变”可以使用Android提供的SyncAdapter来实现低成本的监听。
Receiver的进程配置也有些技巧。如果Receiver需要唤醒UI进程，就把它和UI配置到一个进程当中，如果需要唤醒后台服务，就把它和后台服务配置到一个进程当中。可以减少系统创建进程的开销。
后台服务
把后台服务单独做为一个进程，可以大大减少UI进程的内存压力。如果把它们放到一个进程中，只要它们中的任意一个没有完成任务，它们俩都会一直存在于内存中。
长连接
长连接意味着需要保持网络连接、周期性的心跳数据传输、设备无法休眠，使用需谨慎。
Bitmap
在Java的设计中没有释放内存这个概念的，但实际使用中，大对象除外。Android中的Bitmap就是这么一个例外。Bitmap的不及时回收会造成内存的彪升。详细的分析可以参考这篇文章。
Bitmap recycle方法与制作Bitmap的内存缓存：
http://blog.csdn.net/a345017062/article/details/7963081