Android性能优化

作者: 发光的老金 | 来源:发表于2019-10-08 09:51 被阅读0次

参考资料《Android开发艺术探索》

Android设备作为一种移动设备，不管是内存还是CPU的性能都受到了一定的限制，无法做到像PC设备那样具有超大的内存和高性能的CPU。鉴于这一点，这也意味着Android程序不可能无限制的使用内存和CPU资源，过多地使用内存会导致程序内存溢出，即OOM。而过多地使用CPU资源，一般是指做大量的耗时任务，会导致手机变卡顿甚至出现程序无法响应的情况，即ANR。由此看来，Android程序的性能问题就变得异常突出了，这对开发人员也提出了更高的要求。
性能优化中很重要的问题就是内存泄漏，内存泄漏并不会导致程序功能异常，但是它会导致Android程序的内存占用过大，这将提高内存溢出的发生几率。

Android的性能优化方法

布局优化

布局优化的思想很简单，就是尽量减少布局文件的层级，这个道理是很浅显的，布局中的层级少了，这就意味着Android绘制时的工作量少了，那么程序的性能自然就高了。
如何进行布局优化呢？首先删除布局中无用的空间和层级，其次有选择地使用性能较低的ViewGroup，比如RelativeLayout。如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以考虑使用他们，但是很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果，需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout，因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。
布局优化的另外一种手段是采用<include>标签，<merge>标签和ViewStub。<include>标签主要用于布局重用，<merge>标签一般和<include>配合使用，它可以降低减少布局的层级，而ViewStub则提供了按需加载的功能，当需要时才会将ViewStub中的布局加载到内存，这提高了程序的初始化效率。

<include>标签

<include>标签可以将一个指定的布局文件加载到当前的布局文件中

<LinearLayout style="@style/style_apply_relative">
     <include
            android:id="@+id/titleView"
            layout="@layout/item_title" />
 </LinearLayout>

上面的代码中，@layout/item_title指定了另外一个布局文件，通过这种方法就不用把item_title这个布局文件的内容再重复写一遍了，这就是<include>的好处。<include>标签只支持以android:layout_开头的属性，比如android:layout_width，android:layout_height，其他属性是不支持的，比如android:background。当然，android:id这个属性是特例，如果<include>指定了这个id属性，同时被包含的布局文件的根元素也指定了id属性，那么以<include>指定的id属性为准。需要注意的是，如果<include>标签指定了android:layout_这种属性，那么要求android:layout_width和android:layout_height必须存在，否则其他android:layout_形式的属性无法生效。

<merge>标签

<merge>标签一般和<include>标签一起使用从而减少布局的层级。在上面的示例中，由于当前布局是一个竖直方向的LinearLayout，这个时候如果被包含的布局文件中也采用了竖直方向的LinearLayout，那么显然被包含的布局文件中的LinearLayout是多余的，通过<merge>标签就可以去掉多余的那一层LinearLayout，如下所示

<merge xmlns:android="http://schemas.android.com/apk/res/android">
        <Button
                android:layout_width="match_parent"
                android:layout_height="match_parent">

        <Button
                android:layout_width="match_parent"
                android:layout_height="match_parent">
</merge>

ViewStub

ViewStub继承了View，它非常轻量级且宽高都是0，因此它本身不参与任何的布局和绘制过程。ViewStub的意义在于按需加载所需的布局文件，在实际开发中，有许多布局文件在正常情况下不会显示，比如网络异常时的界面，这个时候就没有必要在这个那个界面初始化的时候将其加载进来，通过ViewStub就可以做到在是使用的时候在加载，提高了程序初始化时的性能。下面是一个ViewStub的示例：

<ViewStub
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:id="@+id/viewStub"
        android:inflatedId="@+id/panel_import"
        android:layout="@layout/activity_main"
        android:layout_gravity="bottom"/>

其中viewStub是ViewStub的id，而panel_import是layout/activity_main这个布局的根元素的id。如何做到按需加载呢？在需要加载ViewStub中的布局时，可以按照如下两种方式进行：

((ViewStub)findViewById(R.id.viewStub)).setVisibility(View.VISIBLE);

或

View inflate = ((ViewStub) findViewById(R.id.viewStub)).inflate();

当ViewStub通过setVisibility或者inflate方法加载后，ViewStub就会被它内部的布局替换掉，这个时候哦ViewStub就不再是整个布局结构中的一部分了。另外，目前ViewStub还不支持<merge>标签。

绘制优化

绘制优化是指View的onDraw方法要避免执行大量的操作，这主要体现在两个方面。
首先，onDraw中不要创建新的布局对象，这是因为onDraw方法可能会被频繁的调用，这样就会在一瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁gc，降低了程序的执行效率。
另外一方面，onDraw方法中不要做耗时的任务，也不能执行成千上万次的循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占cpu的时间片，这会造成view的绘制过程不流畅。按照Google官方给出的性能优化典范中的标准，view的绘制帧率保证60fps是最佳的，这就要求每帧的绘制时间不超过16ms，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法的复杂度总是切实有效的。

内存泄漏优化

内存泄漏在开发过程中是一个需要重视的问题，但是由于内存泄漏问题对开发人员的经验和开发意识有较高的要求，因此这也是开发人员最容易犯的错误之一。内存泄漏的优化分为两个方面，一方面是在开发过程中避免削除有内存泄漏的代码，另一方面是通过一些分析工具比如MAT来找出潜在的内存泄漏继而解决。

场景1：静态变量导致的内存泄漏

下面这种情况是最简单的内存泄漏，下面的代码将导致Activity无法正常销毁，因为静态变量mContext引用了它。

public class AActivity extends Activity {
    private static Context mContext;
     @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_a);
        mContext = this;
   }
}

上面的代码也可以改造一下，如下所示。view是一个静态变量，它内部持有了当前Activity，所以Activity仍然无法释放。

public class AActivity extends Activity {
    private static View view;;
     @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_a);
       view = new View(this);
   }
}

场景2：单例模式导致的内存泄漏

静态变量导致的内存泄漏都太过于明显，而单例模式所带来的内存泄漏是我们容易忽视的，如下所示。

public class TestManager {
    private List<OnDataArrivedListener> mOnDataArrivedListeners = new ArrayList<OnDataArrivedListener>();

    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 unregisierListener(OnDataArrivedListener listener){
        mOnDataArrivedListeners.remove(listener);
    }
    
    public interface OnDataArrivedListener{
        public void onDataArrived(Object data);
    }
}

接着再让Activity实现OnDataArrivedListener接口并向TestManager注册监听，如下所示。下面的代码由于缺少解注册的操作所以会引起内存泄漏，泄漏的原因是Activity的对象被单例模式的TestManager所持有，而单例模式的特点是其生命周期和Application保持一致，因此Activity对象无法被及时释放

protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_a);
        TestManager.getInstance().registerListener(this);
}

场景3：属性动画导致的内存泄漏

属性动画中有一类无限循环的动画，如果在Activity中播放此类动画并没有在onDestroy中去停止动画，那么动画会一直播放下去，尽管已经无法在界面上看到动画效果了，并且这个时候Activity的View会被动画持有，而View又持有了Activity，最终Activity无法释放。解决方式是在Activity的onDestroy中调用animator.cancal()来停止动画。

响应速度优化和ANR日志分析

响应速度优化的核心思想是避免在主线程中做耗时操作，但是有时候的确有很多耗时操作，那么可以将这些耗时操作放在线程中去执行，即采用异步的方式执行耗时操作。相应速度过慢更多的体现在Activity的启动速度上面，如果在主线程中做太多的事情，会导致Activity启动是出现黑屏现象，甚至出现ANR。Android规定，Activity如果5秒内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR，而BoardacastReceiver如果10秒内还未执行完操作也会出现ANR。

一些性能优化建议

避免创建过多的对象；
不要过多是用枚举，枚举占用的内存空间要比整型大；
常量请使用static final来修饰；
使用一些Android特有的数据结构，比如SparseArray和Pair等，它们都具有更好的性能；
适当使用软引用和弱引用；
采用内存缓存和磁盘缓存；
尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄漏。