讲到Android开发，就不得不谈一下Android的优化，不管是平时开发中我们需要注意的一些Android对Java的一些类的优化，还是实际开发中对性能的优化，其实早在15年的google全球大会上google就Android的性能优化就给我们做了很好的介绍：点击打开链接。
接下来本文从几个方面入手讲一讲Android 的优化，主要从以下几点：布局优化，绘制优化，内存优化，响应速度优化，bitmap优化（主要结合listview），线程优化，其他常用性能优化；内存检测工具mat分析与提高。
为了达到优化的目的，我们先来看看应用市场的现状和优化需要从哪些方面着手优化。
应用现状
通过对现状app市场的应用分析，现状应用普遍存在如下问题：
l 约60%应用冷启动时间超过2S
l SDK的不合理使用（基础类型和装箱类型、HashMap和SparseArray）
l 在系统回调或频繁调用的代码块中创建新的实例
l 几乎所有的APP都存在过渡绘制问题，Activity和Window都设置了背景
l json库的不合理使用，导致Launcher严重卡顿
l 近10个应用监听开机广播，导致开机后一段时间内Launcher严重卡顿
l 应用内存占用不合理（适配不规范、缓存不合理、回收不及时）
l 系统SDK导致的内存泄漏（InputMethodManager、WebView，AndroidExcludedRefs.java等）
l 非静态内部类导致的内存泄漏（Handler、Observer、AsyncTask）
l 四大组件的Context和ApplicationContext的不合理使用
l IO操作完成后没有关闭文件（Cursor、TypedArray、File等）
l 功耗问题明显（循环动画、过渡绘制、网络请求不合理、后台服务常驻等）
性能优化指标
性能优化没有一个标准，主要的资料也是通过google大会的优化方案，我们 从google给我们提供的几个方面做优化，总结一下，主要优化集中在以下几点：
性能、内存、稳定性、流量、电量、安装包大小。
所以我们在优化的时候就不能：
- 不能凭感觉，要看数据说话，有足够多的测量
- 尽量使用低配置设备进行测试
- 权衡利弊，以保证进度、稳定为主
- 改善后一定要验证，保证每一次改善都有效，不会导致其它问题
接下来将通过工具检测，问题分析，优化解决几个步骤，对常用的问题进行优化。
在性能测试之前，首先要对工程源码进行排错和调优。Android Lint 可以通过扫描和检查对Android工程可能存在的问题进行审查。通过AS的Analyze->Inspect Code可以打开该工具。
- Inspect Code检测出来的常见的错误有：
- Missing translations (and unused translations) 没有翻译的文本
- Layout performance problems (all the issues the old layoutopt tool used to find, and more) 布局性能
- Unused resources未使用的冗余资源
- Inconsistent array sizes (when arrays are defined in multiple configurations)在多个配置中的数组大小不一致文件
- Accessibility and internationalization problems (hardcoded strings, missing contentDescription, etc)
- Icon problems (like missing densities, duplicate icons, wrong sizes, etc)
- Usability problems (like not specifying an input type on a text field)
- Manifest errors
经过as的lint检测如下：
我们点击打开后，就可以按照提示的修改了，虽然是小细节，但是这影响着你app的编译和运行。
AS Performance Monitor（性能监视器）
Performance Monitors是Android studio集成的又一大利器，主要由GPU Rendering Monitor（GPU渲染监视器），Network Monitor（网络监视器），Memory Monitor（内存监视器）和CPU Monitor（CPU监视器）组成。
使用data analysis能定位某一个进程的内存使用情况，然后大致定位内存泄漏的位置。
使用步骤如下：
- 打开app，手动触发GC；
- 内存降低
- 点击memory useage选项查看当前进程的内存和组件使用情况
- 生成内存占用的文案，然后分析
大家自己编写App的时候，有时会感觉界面卡顿，尤其是自定义View的时候，大多数是因为布局的层次过多，存在不必要的绘制，或者onDraw等方法中过于耗时。那么究竟需要多快，才能给用户一个流畅的体验呢？这里大家需要了解下Android 的view渲染机制，详细的绘制流程我们就不多讲解了。Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，那么整个过程如果保证在16ms以内就能达到一个流畅的画面。
如果操作超过了16ms，系统发生的VSYNC信号，而此时无法进行渲染，还在做别的操作，那么就会导致丢帧的现象。
大家知道渲染的过程是由CPU与GPU协作完成，下面一张图很好的展示出了CPU和GPU的工作，以及潜在的问题，检测的工具和解决方案。
说完了Android的渲染，我们再来看看Android的OverDraw是什么鬼玩意。
我们可以通过打开手机的过渡绘制调试来看我们的布局是否有过渡绘制。
设置 -> 开发者选项 -> 调试GPU过度绘制 -> 显示GPU过度绘制
如果上图中我们的红色比较多，那么过渡绘制就比较多。
过渡绘制的一些基本概念：
1，GPU过渡绘制测试:对于过度绘制的测试主要通过人工进行测试，也是发现应用过渡绘制的首选途径 .通过打开开发者选项中的 显示GPU过度绘制(魅族手机:设置—辅助功能–开发人员工具–硬件加速渲染—调试GPU过渡绘制— 显示过渡绘制区域. (魅族手机需要打开开发者模式：需要在电话界面输入: ##6961## )) 来进行测试（PS：只有android4.2及以上的版本才具备此功能),2，颜色标识: GPU过渡绘制从好到差:蓝-绿-淡红-红
蓝色1x过度绘制
绿色2x过度绘制
淡红色3x过度绘制
红色超过4x过度绘制,3，验收标准:
控制过度绘制为2x
不允许存在4x过度绘制
不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）
手机上打开几个常用的app（之前待过的公司），我们开看两张图，
我们发现第一张图过渡绘制是比较严重的，这给GPu的压力就比较大。那么要解决过渡绘制我们需要注意以下几点：
- 移除不必要的background
- 减少不必要的层次：巧用Hierarchy Viewer
StrictMode意思为严格模式（用过RN的对这个不陌生（javascript有严格模式）），是用来检测程序中违例情况的开发者工具。最常用的场景就是检测主线程中本地磁盘和网络读写等耗时的操作。
在Android中，主线程，也就是UI线程，除了负责处理UI相关的操作外，还可以执行文件读取或者数据库读写操作（从Android 4.0 开始，网络操作禁止在主线程中执行，否则会抛出NetworkOnMainThreadException）。使用严格模式，系统检测出主线程违例的情况会做出相应的反应，如日志打印，弹出对话框亦或者崩溃等。换言之，严格模式会将应用的违例细节暴露给开发者方便优化与改善。
严格模式主要检测两大问题，一个是线程策略，即TreadPolicy，另一个是VM策略，即VmPolicy。
线程检测策略：
- 自定义的耗时调用 使用detectCustomSlowCalls()开启
- 磁盘读取操作 使用detectDiskReads()开启
- 磁盘写入操作 使用detectDiskWrites()开启
- 网络操作 使用detectNetwork()开启
虚拟机检测策略：
- Activity泄露 使用detectActivityLeaks()开启
- 未关闭的Closable对象泄露 使用detectLeakedClosableObjects()开启
- 泄露的Sqlite对象 使用detectLeakedSqlLiteObjects()开启
- 检测实例数量 使用setClassInstanceLimit()开启
严格模式的开启可以放在Application或者Activity以及其他组件的onCreate方法。为了更好地分析应用中的问题，建议放在Application的onCreate方法中。
关于如何使用请参考这篇文章：
点击打开链接
TraceView
关于TraceView使用请参照下面的文章：
http://blog.csdn.net/xiangzhihong8/article/details/52411976
内存泄露检测 Leakcanary
