1.布局优化
删除布局中无用的控件和层级,有选择地使用性能较低的ViewGroup。如果布局中既可以使用LinearLayout也可以使用RelativeLayout,那么就采用LinearLayout,因为RelativeLayout的功能比较复杂,它的布局过程需要花费更多的CPU时间。
采用<include>
标签,<merge>
标签和ViewStub。<include>
标签主要用于布局重用,<merge>
标签一般和<include>
配合使用,它可以降低减少布局的层级,而ViewStub则提供了按需加载的功能,当需要时才会将ViewStub中的布局加载到内存,这提高了程序的初始化效率。
<include>
标签只支持以android:layout_开头的属性,android:id属性是个特例:
<include
android:id="@+id/new_title"
android:layout_width="match_parent"
android:layout_height="match_parent"
layout="@layout/title" />
如果当前布局是一个竖直方向的LinearLayout,被包含的的布局文件中也采用竖直方向的LinearLayout,则可通过<merge>
标签去掉被包含的布局文件中多余的那一层LinearLayout:
<merge xmlns:android="http://schemas.android.com/apk/res/android">
...
</merge>
ViewStub继承了View,它非常轻量级且宽/高都是0,因此它本身不参与任何的布局和绘制过程。
<ViewStub
android:id"@+id/stub_import"
android:inflatedId="@+id/panel_import"
android:layout="@layout/layout_newwork_error"
android:layout_width="match_parent"
android:layout_height="wrap_content" />
按照如下两种方式按需加载:
((ViewStub) findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);
或者
View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();
当ViewStub通过setVisibility或者inflate方法加载后,ViewStub就会被它内部的布局替换掉,这个时候ViewStub就不再是整个布局结构中的一部分了。另外,目前ViewStub还不支持<merge>
标签。
2.绘制优化
onDraw中不要创建新的局部对象,这是因为onDraw方法可能会被频繁调用,这样就会在一瞬间产生大量的临时对象,这不仅占用了过多的内存而且还会导致系统更加频繁gc,降低了程序的执行效率。
onDraw方法中不要做耗时的任务,也不能执行成千上万次的循环操作,尽管每次循环都很轻量级,但是大量的循环依然十分抢占CPU的时间片,这会造成View的绘制过程不流畅。
3.内存泄漏优化
场景1:静态变量导致的内存泄漏
场景2:单例模式导致的内存泄漏
场景3:属性动画导致的内存泄漏
4.响应速度优化和ANR日志分析
Android规定,Activity如果5秒内无响应屏幕触摸事件或者键盘输入事件就会出现ANR,而BroadcastReceiver如果10秒内还未执行完操作也会出现ANR。当一个进程发生ANR后,系统会在/data/anr目录下创建一个文件traces.txt,通过分析这个文件就能定位出ANR的原因。
5.ListView和Bitmap优化
首先要采用ViewHolder并避免在getView中执行耗时操作;
其次要根据列表的滑动状态来控制任务的执行频率,比如当列表快速滑动时显然是不太适合开启大量的异步任务的;
最后可以尝试开启硬件加速来使ListView的滑动更加流畅。
6.线程优化
线程优化的思想是采用线程池,避免程序中存在大量的Thread。
7.一些性能优化建议
避免创建过多的对象;
不要过多使用枚举,枚举占用的内存空间要比整型大;
常量请使用static final来修饰;
使用一些Android特有的数据结构,比如SparseArray和Pair等,它们都具有更好的性能;
适当使用软引用和弱引用;
采用内存缓存和磁盘缓存;
尽量采用静态内部类,这样可以避免潜在的由于内部类而导致的内存泄漏;