Android 性能优化

一、布局优化

1. UI渲染机制

系统通过VSYNC信号触发对UI的渲染、重绘，其间隔时间是16ms。这个16ms其实就是1000ms显示60帧画面的单位时间。如果不能在16ms内完成绘制，那么就会造成丢帧现象。会在下个信号才开始绘制（2*16ms）—导致卡顿

UI渲染时间工具

开发者选项，选择Profile GPU Rendering，并选中On screen as bars的选项，这时候显示一些条形图。

柱状线 蓝色 绘制Display List时间 红色 OpenGL渲染Display List所需要的时间 黄色 CPU等待GPU处理的时间

* 蓝色为VSYNC时间 16ms，需要尽量都控制在绿线之下

2. 避免Overdraw

过度绘制

例如：先绘制Activity的背景，再给布局绘制了重叠的背景。

检查工具Enable GPU OverDraw

3. 优化布局层级

• 降低View树的高度
  对View的测量、布局、绘制，都是对View树进行遍历。
  API文档建议View树高度不宜超过10层。

谷歌将XML文件默认根布局从LinearLayout替换成了RelativeLayout，就是避免前者嵌套所产生布局树的高度，从而提高UI渲染的效率。

4.避免嵌套过多无用布局

1. 使用标签重用layout

将类似的内容来定义一个通用UI
* 将height width设置为0dp,迫使开发者对宽高进行重新设置（否则看不见）

<include layout="@layout/common_ui"   ........   />

注意：若需要覆盖原来原来布局的类似layout_xxxx的属性

需要在include中同时指定layout_width和layout_height属性

2. 使用实现View的延迟加载

• 轻量级组件：不可视、大小为0

< ViewStub >引用的布局没有显示出来

<ViewStub   android:id="@+id/not_often_use" ...... android:layout="@layout/not_often_use"/>

获得ViewStub组件

mViewStub = (ViewStub)findViewById(R.id.not_often_use); //viewstub的ID

显示该View的两种方式

1. mViewStub.setVisibility(View.VISIBLE)
2.

View flateView = mViewStub.inflate();TextView textview = (TextView)inflateView.findViewById(R.id.tv); 

• 不管是哪种方式，ViewStub就不存在了，取而代之的是被inflate的Layout，并将ID重新设置为ViewStub中android：inflateid属性所指的ID，因此两次调用inflate方法会报错

和View.Gone的区别？

ViewStub只会在显示的时候采取渲染布局
View.Gone 初始化布局树的时候已经添加在布局树上了

因此ViewStub更有效率

ViewStub

5.Hierarchy Viewer

现在在 android device monitor中可以使用

二、内存优化

android沙箱机制，每个应用给定内存。过多内存会触发LMK-Low Memory Killer
内存就是RAM

RAM组成：

1. Register：

2. stack：
   存放基本数据类型和对象的引用
   但对象本身不存在stack，而是存放在堆中

3. heap：
   存放new创建的对象和数据。由GC-Java虚拟机的垃圾回收器
4. static field：
   固定的位置存放应用程序运行时一直存在的数据，java中管理一些静态的数据变量
5. constant pool：
   java虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的有序集合，包括直接常量（基本类型，String）和对其他类型、字段、方法的符号引用。

stack和heap的区别
stack分配的内存空间会在该变量作用域结束后，这部分内存立即释放。
heap为new创建的变量分配的空间，不会立即释放，而是等待系统GC进行回收。

• 获得堆的大小

ActivityManager manager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);        int heapsize= manager.getLargeMemoryClass();

内存回收

java创建垃圾收集器线程(Garbage Collection Thread)进行资源管理。

调用System.gc能建议系统进行GC，但是不一定GC。

• 内存泄漏的原因：再强大的算法也会出现部分对象忘记回收的现象。

1.bitmap优化

bitmap是内存占用过高，甚至OOM(out of memory)的最大威胁。
1. 使用分辨率适当的图片—
可以在图片列表使用图片的缩略图thumbnails,显示图片的时候再显示原图。
2. 使用图片缓存—通过内存缓存LruCache和硬盘缓存DiskLruCache

2.代码优化

*