布局优化
尽量减少布局文件的层级,这个道理很简单,布局中的层级少了,Android绘制的工作量就少了,程序的性能自然就提高了。
如何优化布局?
首先删除布局中无用的控件和层级,其次有选择的使用心梗较低的ViewGroup,比如RelativeLayout。如果布局中既可以使用LinearLayout也可以使用RelativeLayout,那么就采用LinearLayout,因为RelativeLayout的功能比较复杂,它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup,因此可以考虑使用它们,但是很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果,需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout。
布局优化的另外一种手段就是使用<include>标签、<merge>标签和ViewStub。<include>标签主要用于布局重用,<merge>标签一般和<include>配合使用,它可以降低减少布局的层级,而ViewStub则提供了按需加载的功能,当需要时才会将ViewStub中的布局加载到内存,这提高了程序初始化的效率。
<merge>标签
<merge>标签一般和<include>标签一起使用从而减少布局的层级,由于当前布局是一个竖直方向的LinearLayout,这个时候如果被包含的布局文件也采用了竖直方向的LinearLayout,那么显然被包含的布局文件中的LinearLayout就是多余的,通过<merge>标签可以去掉多余的一层LinearLayout。
ViewStub
ViewStub继承自View,它非常轻量级且宽高都是0,因此本身不参与布局和绘制过程。ViewStub的意义在于按需加载所需的布局文件,在实际开发中,有很多布局文件在正常的情况下不显示,比如网络异常时的界面,这个时候就没有必要在整个界面初始化的时候将其进行加载,通过ViewStub就可以做到在使用的时候再加载,提高程序初始化的性能:
<ViewStub
android:id="@+id/viewStub"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_gravity="bottom"
android:inflatedId="@+id/fatherId"
android:layout="@layout/layout_net_error"/>
其中,fatherId是layout/layout_net_error这个布局的根元素id。在需要加载ViewStub中的布局时,可以按照如下两种方式进行:
((ViewStub) findViewById(R.id.viewStub)).setVisibility(View.VISIBLE);
或者
View importPanel = ((ViewStub) findViewById(R.id.stub_import)).inflate();
当ViewStub通过setVisibility或者inflate方法加载后,ViewStub就会被它内部的布局替换掉,这个时候ViewStub就不再是整个布局结构中的一部分了。另外,目前ViewStub不支持<merge>。
绘制优化
绘制优化是指View的onDraw方法要避免执行大量的操作,主要体现在两方面:
- 首先,onDraw中不要创建的局部对象,这是因为onDraw方法可能会被频繁调用,这样就会在一瞬间产生大量的临时对象,这不进占用了过多的内存,而且会导致系统更加频繁gc,降低了程序的执行效率。
- 另外,onDraw方法中不要做耗时的任务,也不能执行成千上万的循环操作,尽管每次循环都很轻量级,但是大量的循环仍然十分抢占CPU时间片,这会造成View的绘制过程不流畅。按照Google官方给出的性能优化典范中的标准,View的绘制帧率保证60fps是最佳的,这就要求每帧的绘制时间不超过16ms,虽然程序很难保证16ms这个事件,但是尽量降低onDraw方法的复杂度是切实有效的。
内存泄漏优化
内存泄漏在开发过程中是一个需要重视的问题,由于内存泄漏问题对开发人员的经验和开发意识有较高要求,因此这是开发人员最容易犯的错误之一。内存泄露的优化分为2个方面:
- 一方面是在开发过程中避免写出内存泄漏的代码
- 另一方面是通过一些分析工具比如MAT来查找潜在的内存泄漏继而解决
常见的内存泄漏场景:
静态变量导致的内存泄漏
public class MemoryLeakActivity extends Activity {
private static Context mContext;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mContext = this;
}
}
上面的mContext是静态变量会导致Activity无法正常销毁,如果改造一下,让sView作为一个静态变量持有Activity,也会导致Activity无法正常释放。
public class MemoryLeakActivity extends Activity {
private static View sView;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
sView = new View(this);
}
}
单例模式导致的内存泄漏
这是一种容易被忽视的情况:
public class TestManager {
private ArrayList<OnDataArrivedListener> mOnDataArrivedListeners = new ArrayList<>();
private static class SingletonHolder {
public static final TestManager INSTANCE = new TestManager();
}
private TestManager() {
}
public static TestManager getInstance() {
return SingletonHolder.INSTANCE;
}
public synchronized void registerListener(OnDataArrivedListener listener) {
if (!mOnDataArrivedListeners.contains(listener)) {
mOnDataArrivedListeners.add(listener);
}
}
public synchronized void unRegisterListener(OnDataArrivedListener listener) {
mOnDataArrivedListeners.remove(listener);
}
public interface OnDataArrivedListener {
void onDataArrived(Object data);
}
}
然后再让Activity实现OnDataArriveedListener接口并向TestManager注册监听,,如果缺少解除注册的操作就会引起内存泄漏,泄漏的原因是Activity对象被单例模式的TestManager所持有,而单例模式的特点是声明周期和Application保持一致,因此Activity对象无法被及时释放。
属性动画导致的内存泄漏
从Android3.0开始,提供了属性动画,属性动画是一类无限循环的动画,如果在Activity中播放此类动画而没有在onDestroy停止动画的话,动画就会一直播放下去,尽管已经无法在界面上看到动画效果了,这个时候Activity的View会被动画持有,而View又Activity,最终Activity无法释放,因此需要在onDestroy中调用animator.cancel()来停止动画。
线程优化
线程优化的思想采用线程,避免程序中存在大量的Thread。线程池可以重用内部的线程,从而避免了线程的创建和销毁来带的性能开销,同时线程池还能有效的控制线程池的最大并发数量,避免因为大量的线程因相互争夺资源而导致阻塞的发生。因此在实际开发中,我们要尽量采用线程池,而不是每次都创建一个新的Thread对象。
其他
- 避免过多的创建对象
- 不要大量使用枚举,枚举占用的内存空间要比整形大
- 常量使用static final修饰
- 使用一些Android特有的数据结构,比如SparseArray和Pair等,他们都具有更好的性能
- 适当使用软引用和弱引用
- 采用内存缓存和磁盘缓存
- 尽量采用静态内部类,这样可以避免潜在的由于内部类而导致的内存泄漏
网友评论