1 代码优化
1.1 缓存结果
使用Android的稀疏数组(Spare Array):SparseArray、SpareBooleanArray、
SparseIntArray对结果进行缓存.当然也可以使用也可是使用Java容器缓存. 不过Android定义的SpareArray类，当键是整数时,比容器的HashMap效率
高.因为HashMap使用的是java.lang.Integer对象,而SparseArray使用的基本类型int.因此使用HashMap会创建很多Integer对象，而使用SpareArray则可避免.当然HashMap也是有好处的,就是可以不依赖android.总之:使用缓存存储结果.随便提下:LruCache<K,V > 是使用缓存不错的选择、它可以定义缓存的最大长度，注意的是它是Android3.1引入的.
1.2 响应能力
其实大家都知道Android有一个主线程也称为UI线程,可以说应用就在其中
运行.在主线程中运行所有代码是可以的,但不推荐.因为应用只有一个主线程,因此所有时间都按顺序处理.这样响应能力会受到影响，说不定给予没有响应对话框即大家说的假死.那么我们有哪些方法呢:
1.2.1 降低布局复杂度
Android的onCreate() 方法一般会包含调用setContentView展开资源方法.然展开资源是一个很大开销操作，那么我们使用RelativeLayout代替嵌套LinerLayouts;<merge/>标签来合并布局,往往自己布局的顶层元素是一个Fragmentlayout;多次使用相同的组成部分用<include/>包含; 同时用使用SDK的layoutopt工具来分析布局来降低布局复杂度.
1.2.2 推迟初始化
内存分配需要花时间，等到对象真正需要时才进行配置.使用ViewStub来
推迟初始化.感觉有点像Java中延迟加载似的.
1.2.3 转移线程
“假死”是因为输入事件在5秒钟没有被处理或者BroadcastReceiver在10秒内没有执行完毕,那么这个”假死”对话框弹出来. 我们可以把操作转移到另一个线程来加快应用响应速度.单一定要确保是任务执行慢原因、而不是坏的算法或实现.
1.2.4 检测缓慢代码
使用StrictMode检测应用中执行缓慢的代码或潜在缓慢的代码.
从主线程调用start() 执行时间太长,如果StrictMode Thread策略配置为
检测缓慢调用时会出现如下日志:
1.3 数据库
1.3.1 优化SQL语句字符串
因为String是不可改变的,会分配2倍的对象( 查看Java String),所以使用StringBuilder或调用String.format()加快SQL语句字符串的创速度.
1.3.2 预编译
预编译我相信做开发都知道数据库操作预编译吧,也知道其作用！那么Android中也有预编译.是SQLiteDatabase. compileStatement();
1.3.3 事务
Android跟JDBC一样，没有设置事务时会自动为每个操作创建一个事务 并且在每次操作后立即提交.但有时候我们多数据插入所有到完成或不完成.那么还是用原方法效率是极低的而且是错误的.这就需要我们自己建立事务.
1.3.4 只读需要的数据
调用查询时选择正确的参数可以使性能得到客观的提高.如果只需要一定数量的行，指定查询调用的限制参数()，则可以进一步减少数据库访问时间.比如:SQLite的选择合适的查询方法(query()有几种根据情况选择) 、SQL中加Limit和Offset进行分页.
2 内存优化
2.1 避免类型转换.尽量保持类型一致.
2.2 满足要求的最小数据类型
当使用到数组的值很多很大时可以将数据存在几个数组中.比如:需要存储0-10W大数据,一个数组存0-32767(short数组),一个存大于32767(int数组)，虽然有点复杂，但内存节约和潜在的性能会提升很大甚至优化方法实现.
3 多线程与同步
3.1 使用Thread
3.2 使用AsyncTask
AsyncTask在UI线程中收到非UI线程中处理事件的结果刷新UI.
3.3 Handler和Looper
Lopper用来封装消息循环和消息队列的一个类,一般和Handler同时运用.Handler在非UI线程创建会报错，需使用Looper才可以.
3.4 Activity生命周期
Activity和线程共用时需注意两点:
① 转屏幕就创建新的对象,那么旧对象设置的状态将无效.
② 内部类与外围类实例相关联,不会关联到新实例,因此新实例不会有响应.
4 性能评测和剖析
4.1 时间测量
使用Debug.threadCpuTimeNanos()进行时间测量.它只测量在当前线程中所花费的时间,所以它的结果更正确.不过,如果要测量的部分运行在多个线
程上，只调用一次Debug.threadCpuTimeNanos()不会给出准确的估值,必须在所有涉及的线程调用此方法并把结果相加.