优化
1.ANR
无响应，acitivity最大执行事件为5s，broadcastReceier中最大执行时间为10s
应用的响应由ActivityManager和windowManager监视
原因
1.主线程被IO操作阻塞（4.0后网络IO不允许出现在主线程中
2.主线程中有耗时计算
主线程操作
1.Activity的回调
2.service默认在主线程，处理耗时操作
3.BroadcastReceiver的onReceive回调
4.没有使用looper和handler的handleMessage，post（runnable）
5.AsyncTask的回调中（除了doInBackGround）
解决
1.AsyncTask 处理IO操作
2.Thread（子线程不可创建handler）或者handlerThread（可创建handler）提高优先级
3.handler处理耗时操作
4.Activity的oncreate和onresume不做耗时操作
systrace + 函数插桩
2.OOM
申请的内存资源超过dalvik虚拟机的最大内存限制
内存溢出
内存抖动 短时间产生大量对象并很快回收
内存泄漏 导致内存溢出
bitmap
1.显示缩略图
2.listview滑动停止再调用网络请求
3.及时释放内存，通过JNI再c中释放内存
4.图片压缩
5.使用inbitmap属性，销毁不用的bitmap
6.捕获异常
其他listview
1.convertview的复用，大图控件使用LRU策略
2.避免ondraw的时候执行对象创建
3.谨慎使用多进程，业务不大则少用，使用不当会有其他crash
3.bitmap
1.recycle
1.回收JAVA
2.回收native
2.LRU策略
一个泛型类，用linkedHashmap实现，提供get和put方法来添加和获取缓存对象，当缓存满了的时候，调用trimtosize方法，把较早的对象移除
3.计算insampleSize值 来适当缩放大小
4.缩略图
BitmapFactory
5.三级缓存 网络 本地 内存
4.UI卡顿
轻量ANR
流畅60fps，16ms处理完
GPU选项 减少红色，多蓝色
overDraw 大量重叠，非必要背景
原因：
1。人为地再UI线程中做轻微耗时操作
2.layout过于复杂，无法再16ms内完成渲染
3.同一时间动画执行次数过多，导致CPU和GPU负载过重
4.view过度绘制，导致某些像素在同一祯内绘制多次
5.view频繁出发measure，layout，导致耗时过多，整个view频繁重新渲染
6。view频繁GC，暂时阻塞渲染操作
7.冗余资源及逻辑等导致加载执行过慢（使用异步任务处理，启动顺序等
优化
1.include，merge
merge标签可以减少视图树中的节点个数，加快视图的绘制，提高UI性能。
少嵌套，若通用，使用include导入，使用Gone代替Invisibel（仍然绘制
使用weight代替长宽减少计算，item复杂嵌套时使用自定义view
2.列表及adapter优化
尽量复用listview在adapter当中的getview方法，不要重复获取实例
使用convertview ，列表滑动时不进行listview更新，并用viewholder代替findviewbyid
3.减少不必要的背景设置，图片压缩
4.使用性能消耗更小布局（TableLayout、ConstraintLayout）
5.通过使用半透明颜色值(#77000000)代替透明色
6.使用ViewStub懒标签，延迟加载不必要的视图
5.内存泄漏
1.JAVA内存分配策略
静态存储区==方法区 线程共享
静态数据 常量 全局变量
保存系统的类信息。比如类的字段、方法、常量池等，在app整个运行期间都存在
栈区 内存分配连续 线程私有
局部变量表、操作数据栈和帧数据区
局部变量表：用于报错函数的参数及局部变量
操作数栈：主要保存计算过程的中间结果，同时作为计算过程中的变量临时的存储空间。
帧数据区:除了局部变量表和操作数据栈以外，栈还需要一些数据来支持常量池的解析
基本数据类型和对象引用变量
方法内的局部变量会在栈上创建内存空间，并在方法执行完后被自动释放
堆区 ==动态内存分配 线程共享
new出来的对象 ，会被java GC
2. java内存管理
无引用对象的会被回收
3.java内存泄漏
无引用对象持续占用内存或得不到及时释放，造成内存空间浪费
1.单例 静态属性
单例持有activity的context会泄漏，应该使用应用的引用，getApplicationContext
2.匿名内部类
非静态内部类默认持有外部类引用给，使用静态内部类
3.handler
也是非静态内部类的问题
改为静态内部类，并持有外部类的弱引用，removeCallbacksandMessages
4.避免static成员变量
占用内存过大，容易被系统优先回收
5.资源未关闭
contentObserver ，游标，socket，bitmap，广播接收器
6.AsyncTask和handler类似，
在ondestroy的时候cancel
6.内存管理
1.Android内存管理机制
分配机制：弹性分配要求，初始不会分配太多内存，由Ram大小决定
回收机制 进程优先级 前台--可见--服务--后台--空
2.特点
占内存少，合理释放资源，内存紧张时可以释放不重要内存，在特殊生命周期中保存式还原重要数据
3.优化
1.service完成后，尽量停止，可用intentService（开启子线程，可自动推出
2.UI不可见时，释放资源
3.内存紧张时，释放不重要资源
4.避免滥用bitmap，压缩+LRU
5.使用针对内存优化的数据结构，arraymap代替hashmap
6.避免使用依赖注入的框架 dagger2
7.使用zip对齐apk
8.使用多进程，消耗多且需要长期运行的模块，webview
7.其他优化
1不用静态变量存储数据
使用文件 sp，contentPRovider
2.sharedPreference
不能跨进程同步，进程不安全
apply不反回结果，commit返回
sp文件过大，kv模式存储配置信息，不能过大，不然阻塞主线程，UI卡顿，而且解析起来产生大量对象
3.内存对象序列化
序列化，java中将对象状态信息转换为可存储或者可传输的形式
putExtra只能传输基本数据类型
若为复杂对象，需要实现serailizable接口，产生大量临时变量，影响UI性能，使用磁盘存储比较安全
或者实现parcelble接口，不能使用存储在磁盘上的数据，使用内存时，用parcelble较好
4.避免UI线程中耗时操作
可以使用strictMode追踪ui卡顿，在oncreate中开启
8listview
ArrayAdapter:简单易用的Adapter，通常用于数组或list集合的数据源（多个值包装成多个列表项）。
simpleAdapter:并不见得、功能强大的Adapter，可用于list集合的多个对象包装成多个列表项。
simpleCursorAdapter:与上相似，但是用于包装jCursor(数据库游标)提供的数据源。
BaseAdapter:通常用于被扩展。扩展BaseAdapter可以对各列表项进行最大限度的定制。
增加优化一：convertView的使用，主要优化加载布局问题
1.listivew每次滚动都会调用gitview()方法，所以优化gitview是重中之重。
通过JUnit进行Android单元测试
