一、性能问题
主要总结为4个类别：
1、卡顿：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。
2、crash：减低 crash 率和 ANR 率，不要在用户使用过程中崩溃和无响应。
3、耗电：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。
4、包大小
性能问题的主要原因，但归根到底，不外乎内存使用、代码效率、合适的策略逻辑、代码质量、安装包体积这一类问题。
二、卡顿分析
卡顿的场景有很多，主要有：UI 绘制、应用启动、页面跳转、事件响应；根本原因可以分为两大类：
1、界面绘制：主要原因是绘制的层级深、页面复杂、刷新不合理，该场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
1.1、View的绘制中有三个核心步骤，通过Measure和Layout来确定当前需要绘制的View所在的大小和位置，通过绘制(Draw)到surface
1.2、绘制任务太重，绘制一帧内容耗时太长；主线程太忙了，导致VSYNC信号来时还没有准备好数据导致丢帧。
1.3、性能问题需要借助相应的的调试工具，比如查看 Layout 层次的 Hierarchy View、GPU Profile 工具Systrace UI 性能分析、调试GPU过度绘制、和静态代码检查工具 Lint等，这些工具对性能优化起到非常重要的作用。
2、数据处理：该原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。
三、卡顿的解决
1、布局优化，主要通过减少层级、减少测量和绘制时间、提高复用性三个方面入手。总结如下：
减少层级：合理使用ConstraintLayout、RelativeLayout和LinerLayout，合理使用Merge。
提高显示速度：使用ViewStub，它是一个看不见的、不占布局位置、占用资源非常小的视图对象。
布局复用：可以通过include、merge、标签来提高复用。
尽可能少用wrap_content：wrap_content会增加布局measure时计算成本，在已知宽高为固定值时，不用wrap_content。
2，避免过度绘制
过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的UI结构中，如果不可见的UI也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的CPU以及GPU资源。
移除XML中非必须的背景，移除Window默认的背景、按需显示占位背景图片
适时使用Color.TRANSPARENT，因为透明色Color.TRANSPARENT是不会被渲染的,他是透明的。
自定义View优化。使用canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。
3，启动优化
启动主要完成三件事：UI布局、绘制和数据准备。因此启动速度优化就是需要优化这三个过程：
UI布局。应用一般都有闪屏页，优化闪屏页的UI布局，可以通过Profile GPU Rendering检测丢帧情况。
启动加载逻辑优化。可以采用分布加载、异步加载、延期加载策略来提高应用启动速度。
数据准备。数据初始化分析，加载数据可以考虑用线程初始化等策略。
先测量activity的启动时间-------Activity的reportFullyDrawn()方法
windowIsTranslucent设置成true，就可以让程序在初始化的时候窗口是透明的，初始化结束后程序主界面才会显示出来，从而也就完全看不到白屏界面了
android:Background设置为图片或者背景颜色
4、Application优化
很多第三方组件（包括App应用本身）都在 Application 中进行初始化
必要的组件一定要在主线程中立即初始化(入口 Activity 可能立即会用到)
重要组件的加载一定要在主线程中初始化，但是可以延迟初始化。
其他组件Bugly，x5内核初始化，SP的读写，友盟等组件放到子线程中初始化。（子线程初始化不能影响到组件的使用）
5，合理的刷新机制
数据的变化，需要刷新页面来展示新的数据，但频繁刷新会增加资源开销，并且可能导致卡顿发生，
尽量减少刷新次数。
尽量避免后台有高的CPU线程运行。
缩小刷新区域。
四、降低Crash率
1、armeabi兼容armeabi-v7和armeabi-v8a以及新的arm体系结构的问题，在gradle里进行配置支持
2、Java层面借助于Android全局的异常捕捉方式比如Thread.setDefaultUncaughtExceptionHandler()等来实现
C/C++层面，则通过signal的捕捉来处理
3、代码静态处理方式和工具
代码扫描和代码静态安全检测工具可以使用Coverity或类似的工具
通过GodEyes-android或类似的工具进行扫描来避免可能触发的Crash问题
4、Crash问题分析总结反馈补充测试用例和测试场景，加强测试手段。
5、对于空指针问题，越界问题，类查找问题，资源查找问题，非法参数问题，数据传输超限问题，资源加载引起的超时问题，数据库问题，Bundle加载问题等通过代码扫描工具以及静态安全检测工具并结合Code Review在编译阶段和代码提交阶段就尽可能避免，同时通过增加测试用例包括边界点测试进一步避免Crash问题。