APP 的优化

APP的优化，一般来说是有下面几种优化

1. App启动优化
2. 布局优化
3. 响应优化
4. 内存优化
5. 电池使用优化
6. 网络优化

#1 APP 启动优化

#2布局优化

界面为什么会出现卡顿，Android中有一个16ms的原则（即Android每16ms会重新绘制我们的界面），当CPU和GPU在16ms内完不成界面的渲染时候，就只能再等16ms才能完成，即用户就会产生卡顿的现象，即丢帧就是卡的现象，丢的帧越多卡顿会越严重

卡顿的原因：

1.布局过于复杂，UI布局的嵌套过深或者自定义控件的onDraw（）中有复杂的运算，Hierarchy Viewer这个工具来帮我们分析布局（可以看到嵌套的布局有几层还提供了节点来显示onMeasure，onLayout，onDrawx的性能消耗）--------CPU的运算过于复杂

2.过度绘制ovverdraw，每屏每帧上，每个像素点只能被绘制一次，如果有多次绘制就是ovverdraw多次绘制了----------GPU的运算过于复杂

3.UI线程的复杂运算，即ANR（运算阻塞导致的卡顿的分析可以使用Traceview）

4.频繁的GC调用，如对象的频繁创建和销毁，瞬间产生大量的对象，剩余空间不足时

#1 内存溢出

产生原因

Android 的虚拟机是基于寄存器的Delvik，它的最大堆内存是16M，有的机器是24M，因此所能用的内存空间是有限的，如果我们的内存占用超过一定水平就会出现OOM异常

对象内存过大

---------保存了多个好用内存的过大的对象（比如Bitmap，XML文件），造成内存超出限制

1.图片过大导致OOM

• 等比例压缩图片
• 对图片采用软引用，及时回收
• 缓存图片到内存中，使用LruCache（最近最少使用算法）类专门用来处理图片缓存

2.界面切换OOM

1.查看页面布局中有没有大的图片比如背景图之类的

2.直接把XML配置文件加载成View放到容器中

3.页面切换时尽可能少的重复使用一些代码

3.查询数据库没有关闭游标

4.构造Adapter没有使用缓存的convertView

5.Bitmap不使用及时回收

#2 内存泄漏

1.资源没有及时释放

程序代码中长期保持某些资源，比如Context、Cursor，IO流的引用，资源得不到释放造成内存泄漏

2.static 关键字的使用

• ---------用static修饰的成员变量属于该类，而不是该类的实例，所以用static修饰的变量他的生命周期是很长的，如果用它来应用一些资源会耗费过多的实例在context中最多

解决方案

1.避免使用static成员变量引用资源耗费过多的实例，比如Context

context尽量使用ApplicationContext，因为他的生命周期比较长，引用他不会出现内存泄漏问题

使用弱引用代替强引用

3.线程生命周期的不可控性

#3