概述
Android一些有效的性能优化方法，主要包括布局优化，绘制优化，内存泄露优化，响应速度优化，Bitmap优化，线程优化以及一些性能优化建议，同时在介绍响应速度优化的同时还介绍了ANR日志的分析方法。
布局优化
- 布局优化其实就是减少布局文件的层级嵌套，布局中的层级少了，这就意味着Android绘制时的工作量少了，那么程序的性能自然就高了。
- 首先删除布局中无用的控件和层级，其次有选择地使用性能较低的ViewGroup。如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，主要是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以考虑使用它们，但是很多时候单车通过一个LinearLayout或者FrameLayout无法实现产品效果，需要通过嵌套的方式来完成。这种情况下就建议采用RelativeLayout，因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。
- 采用<include>标签，<merge>标签和ViewStub。<include>标签主要用于布局重用，<merge>标签一般和<include>配合使用，它可以降低减少布局的层级，而ViewStub则提供了按需加载的功能，当需要时才会将ViewStub中的布局加载到内存，这提高了程序的初始化效率。具体用法请自行百度。
绘制优化
- 绘制优化是指View的onDraw方法要避免执行大量的操作。
- 首先，onDraw中不要创建新的布局对象，因为onDraw方法可能会被频繁调用，这样就会在一瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁GC，降低了程序的执行效率。
- onDraw不要做耗时的任务，也不能执行成千上万次的循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占CPU的时间片，会造成View的绘制过程不流畅。按照Google官方给出的性能优化典范中的标准，View的绘制帧率保证60fps是最佳的，这就要求每帧绘制时间不超过16ms，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法的复杂度总是切实有效的。
内存泄露优化
场景1：静态变量导致的内存泄露
由于是静态变量，一直存在于堆内存中，它内部持有当前Activity，所以当Activity销毁时，Activity无法释放。场景2：单例模式导致的内存泄露
如果Activity实现单例对象里面的接口，由于缺少解注册的操作所以会引起内存泄露，泄露的原因是Activity的对象被单例模式所持有，而单例模式的生命周期和Appliction保持一致，因此Activity对象无法被及时释放。场景3：属性动画导致的内存泄露
从Android3.0开始，Google提供了属性动画，属性动画中有一类无限循环的动画，如果在Activity中播放此类动画且没有在onDestry中去停止动画，那么动画会一直播放下去，尽管已经无法在界面上看到动画效果，并且这个时候Activity的View会被动画持有，而View又持有了Activity，最终Activity无法释放。下面动画是无限动画，会泄露当前Activity，解决方法是在Activity的onDestroy中调用 animator.cancle()来停止动画。
响应速度优化和ANR日志分析
响应速度优化的核心思想是避免在主线程中做耗时操作，在开发的过程中可以将这些耗时操作放在线程中去执行，采用异步的方式执行耗时操作。响应速度过慢更多地体现在Activity的启动速度上面，如果在主线程中做太多事情，会导致Activity启动出现黑屏现象，严重就会出现ANR。Android规定，如果在5秒中之内无法响应屏幕触摸时间或者键盘输入时间就会出现ANR，而BroadcastReceiver如果10秒钟之内还未执行完操作也会出现ANR。
线程优化
线程优化的思想是采用线程池，避免程序中存在大量的Thread。线程池可以重用内部的线程，从而避免了线程的创建和销毁所带来的性能开销，同时线程池还能有效地控制线程池的最大并发数，避免大量的线程因互相抢占系统资源从而导致阻塞现象的发生。因此在实际开发中，我们要尽量采用线程池，而不是每次都要创建一个Thread对象。
性能优化
避免创建过多的对象；
不要过多的使用枚举，枚举占用的内存空间要比整型大；
常量请使用 static final来修饰；
使用一些Android特有的数据结构，比如SparseArray和Pair等，它们都具有更好的性能；
适当的使用 软引用与弱引用；
采用内存缓存和磁盘缓存；
尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄露
提高程序的可维护性
1. 命名要规范，要能正确地传达出变量或者方法的含义，少用缩写，关于变量的前缀可以参考Android源码的命名方式，比如私有成员以m开头，静态成员以s开头，常量则全部用大写字母表示，
2. 代码排版上需要留出合理的空白来区分不同的代码块，其中同类变量的声明要放在一组，两类变量之间要留出一行空白作为区分。
3. 仅为非常关键的代码添加注释，其他地方不写注释，这就对变量和方法的命名风格提出了很高的要求，一个合理的命名风格可以让读者阅读源码就像在阅读注释一样，因此根本不需要为代码额外写注释。