Android性能优化

项目中的单例

在分析性能优化之前偶然的看到项目中的有很多单例模式，单例模式几乎是项目中被应用最多的设计模式，不同单例模式对性能开销也是不一样的。

饿汉式

public class HungSingle {
    private static final HungSingle hungSingle = new HungSingle();

    //构造函数私有
    private HungSingle() {

    }

    //公有的静态函数，对外暴露获取单例对象的接口
    public static HungSingle getHungSingle() {
        return hungSingle;
    }

}

HungSingle类不能通过new的形式构造对象，只能通过HungSingle.getHungSingle()方法来获取，而这个HungSingle对象是静态对象，并且在声明的时候就已经初始化，这就保证了HungSingle对象的唯一性。

懒汉式

public class Singleton {
    private static Singleton instance;

    private Singleton() {
        
    }

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

上述方法中添加synchronized字段保证在多线程情况下单例对象的唯一性，但是会有一个问题，每次调用getInstance()方法都会进行同步，这样会消耗不必要的资源，这也是懒汉式存在的最大问题，这种模式一般不建议使用。

Double Check Lock (DCL)单例

public class Singleton {
       private static Singleton sInstance = null;

       private Singleton() {
       
    }

       public static Singleton getInstance() {
        if (sInstance == null) {
            synchronized (Singleton.class) {
                 if (sInstance == null) {
                     sInstance = new Singleton();
                   }
            }
         }
        return sInstance;
       }
   }

可以看到getInstance()方法中对sInstance进行了两次判空，第一层判断主要为了避免不必要的同步，第二层的判断则是为了在null的情况下创建实例。

假设有个线程A执行到了sInstance = new Singleton()语句，它大致做了如下3件事：

给Singleton的实例分配内存；
调用Singleton的私有构造函数，初始化成员字段；
将sInstance对象指向分配的内存空间，此时sInstance对象就不为空了。

在JDK 1.5之前上面的第二和第三顺序是无法保证的，如果3执行完、2未执行，这时候被切换到B线程，由于sInstance在线程A内执行过第3步了，sInstance已经是非空了，所以线程B直接取走了sInstance,再使用就会出错，这就是DLC失效问题。在JDK1.5之后官方加入了volaatile关键字，因此在1.5之后的版本只需要将sInstance的定义改为private volatile static Singleton sInstance = null即可。

静态内部类单例模式（最推荐的模式）

public class Singleton{
       private Singleton() {

       }

    public static Singleton getInstance() {
        return SingletonHolder.sInstance;
    }

    /**
     * 静态内部类
     */
    private static class SingletonHolder {
         private static final Singleton sInstance = new Singleton();
     }
   }

只有在第一次调用Singleton的getInstance方法时才会导致sInstance被初始化。因此，第一次调用getInstance方法会导致虚拟机加载SingletonHolder类，这种方式不仅能够保证线程安全，也能够保证单例对象的唯一性，同时也延迟了单例的实例化。

项目中的单例

   // 获取单例
    public static Common getInstance() {
        synchronized (Common.class) {
            if (instance == null) {
                instance = new Common();
                activityList = new ArrayList<>();
            }
        }

        return instance;
    }

 public static XunfeiSpeekUtils getInstance() {
        synchronized (XunfeiSpeekUtils.class) {
            if (instance == null) {
                instance = new XunfeiSpeekUtils();
            }
        }

        return instance;
    }

每次调用getInstance()都会进行同步操作，这样是非常不友好的，造成很大的开销。即使加双重判断锁也会出现DLC失效的问题。

内存泄露

首先要搞清楚内存泄露跟内存溢出是两个概念，比如一车最多能坐5个人，你却非要塞下10个，车就挤爆了，这就是内存溢出。而车上的五个人本来应该在车到站后都下车的，结果只下车了3个人，还有两个人一直赖在座位上不肯下来，这就是内存泄露 ，泄露的多了就会导致OOM产生。

非静态内部类

在java中，内部类会隐式的持有外部类的引用，项目中用的比较多的是Handler作为非静态内部类的使用，如果Handler在fragment或者Activity结束的时候扔有未执行完的任务，比如一个定时任务等，那么就会导致内存泄露，项目中非静态内部类的Handler比比皆是：

 private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            Bitmap thumbnailBitmap = (Bitmap) msg.obj;
            mJCVideoPlayerStandard.thumbImageView.setImageBitmap(thumbnailBitmap);
        }
    };

    Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            int what = msg.what;
            switch (what) {
                case READ_ADDRESS_IN_JSON:
                    String json = (String) msg.obj;
                    //得到地址的实体类对象
                    try {
                        JSONObject object = new JSONObject(json);
                        JSONArray array = object.getJSONArray("data");
                        ...

  private Handler handler = new Handler() {
        public void handleMessage(android.os.Message msg) {
            switch (msg.what) {
                //0101绑定指令
                case 11:
                    setWriteCharacteristicNotification("0101", writeBtCharacteristic);
                    cancelScan();
                    Common.getInstance().setBluetoothState(true, bluetoothGatt.getDevice().getName());
                    runOnMainThread(new Runnable() {
                        @Override
                        public void run() {
                            EventBus.getDefault().post(new ConnectSuccessEvent("ConnectSuccess", bluetoothGatt.getDevice().getName()));
                        }
                    });

                    handler.removeMessages(11);//移除消息
                    break;

   Handler myHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            switch (msg.what) {
                case 1000:
                    NoHttpUtils.httpGet(AppConstant.URL_HEARTBEAT, new HashMap(), mOnResponseListener, REQUEST_HEARTBEAT_CODE);
                    break;
                default:
                    break;
            }
        }
    };
    ...

上面我们分析非静态内部类的Handler可能会导致内存泄露，检测工具就给了我们下面这张图，追踪下去发现是StateLayout产生的，并且会发生在每个Fragment中，清楚源头之后我们点击进入StateLayout类中

public class StateLayout extends FrameLayout {
    private Handler handler = new Handler();
    ...

...
  final Runnable runnable = new Runnable() {
                @Override
                public void run() {
                    switch (switchPosition) {
                        case 0:
                            progressTextView.setText(mContext.getString(R.string.state_loading1));
                            break;
                        case 1:
                            progressTextView.setText(mContext.getString(R.string.state_loading2));
                            break;
                        case 2:
                            progressTextView.setText(mContext.getString(R.string.state_loading3));
                            break;
                        case 3:
                            progressTextView.setText(mContext.getString(R.string.state_loading4));
                            switchPosition = -1;
                            break;
                        default:
                            break;
                    }
                    switchPosition++;
                    handler.postDelayed(this, 500);
                }
            };
            handler.post(runnable);
            ...

果然可以在里面看到一个非静态内部类Handler，我们可以看到当前类是继承自FrameLayout的，在Android控件中绝大部分都是持有布局对应的fragment或者Activity的引用的，而当前Handler是非静态内部类隐性的持有了外部类的引用，间接的就导致在布局中使用了这个StateLayout的fragment被Handler所持有，即使执行了onDestory，其引用一直无法被回收掉。

解决方案：这里我将Handler删除，用一个属性动画代替，就不会再出现Handler的内存泄露问题了，不过这里却报了属性动画的内存泄露，查阅相关资料发现，属性动画如果不及时释放也是会导致内存泄露的，最终在显示隐藏回调方法里判断当前StateLayout不再显示的时候将动画释放。

@Override
    protected void onVisibilityChanged(@NonNull View changedView, int visibility) {
        super.onVisibilityChanged(changedView, visibility);
        if (valueAnimator == null) {
            return;
        }
        if (visibility == GONE || visibility == INVISIBLE) {
            valueAnimator.cancel();
            valueAnimator = null;
        }
    }

Context 导致内存泄漏

public class XunfeiSpeekUtils {
    private static XunfeiSpeekUtils instance;

    public static XunfeiSpeekUtils getInstance() {
        synchronized (XunfeiSpeekUtils.class) {
            if (instance == null) {
                instance = new XunfeiSpeekUtils();
            }
        }

        return instance;
    }

    SpeechRecognizer mIat;
    RecognizerDialog mIatDialog;
    HashMap mIatResults = new LinkedHashMap();
    Context mContext = null;
   ...

 XunfeiSpeekUtils.getInstance().init(mActivity).speak(voice);

上面这行代码是必然会导致内存泄露的，而且露的还不少，我们可以看下面两张图：

红框部分我们点击进去可以看到正是这个XunfeiSpeekUtils导致了2.7MB的内存泄露：

案例分析：XunfeiSpeekUtils是个单例类，生命周期是很长的，持有的context是mActivity，这就导致当前activity在销毁的时候其引用扔被这个单例所持有，这就造成的内存泄露，解决方法是传入getApplicationContext，因为Application的生命周期是贯穿整个程序的，所以XunfeiSpeekUtils类持有它的引用，也不会造成内存泄露问题。

集成LeakCanary内存泄露检测工具到项目

在只监控Activity的时候，打开咱们项目app的时候LeadCanary立刻就发送了通知过来，点击通知栏我们可以看到具体的泄露地方

如何集成这里就不说了，百度都有，而且非常简单。主要来看下怎么理解这个工具的错误信息

1.以LoginActivity为例，由上至下，ProgressDialogUtils中的静态imageView引用的mContext导致了LoginActivity内存泄露。接着我们打开这个导致内存泄露的ProgressDialogUtils一探究竟。

public class ProgressDialogUtils extends AlertDialog {


    private static ImageView imageView;
    private static TextView  textView;

   ...

可以看到这里所有的View控件都是静态的，而我们的ImageView是持有Activity引用的，static变量在内存中是单独存在于内存块中的，这种情况下，Activity是没法被彻底销毁的，因为在内存中一直有一个引用，导致Activity也无法被回收，自然就会内存泄漏了。建议，在Android中不要使用static修饰控件。

2.接着来看另一个导致内存泄露的MainActivity

public class Player implements OnCompletionListener {
    private MediaPlayer mediaPlayer;
    private PlayerHandler mPlayerhandler;
    Context mContext = null;

    public Player(Context context) {
        mContext = context;
        mPlayerhandler = new PlayerHandler();

这个就比较简单了，Player控件中真正执行操作的其实还是MediaPlayer, MediaPlayer的源码中是持有Activity的引用的，因此在使用完之后需要及时的释放，咱们代码中并未释放过，这里其实还是有个坑的，一般来说释放代码应该像这样的

 /**
     * 释放播放器资源
     */
    private void ReleasePlayer() {
        if (player != null) {
            player.stop();
            player.release();
            player = null;
        }

但是这样写之后，发现还是存在内存泄露，大致原因就是在源码中release方法并未到某个引用做释放动作，而reset方法可以。改成这样：

 /**
     * 释放播放器资源
     */
    private void ReleasePlayer() {
        if (player != null) {
            player.reset();
            player.release();
            player = null;
        }

使用Lint分析

Android Studio内置了Lint，只要点一下就可以使用，Lint 的使用路径：工具栏 -> Analyze -> Inspect Code…

68747470733a2f2f692e696d6775722e636f6d2f7247534e6a45672e706e67.png

自定义View的时候 onDraw onMeasure onLayout等方法会被多次调用，如果在这几个方法里去实例化对象，对性能消耗是很大的，比如下面几个：

项目中经常使用Weight属性来做适配，但是如果父布局跟子布局同时都使用Weight是对性能很不好的，解决方法也很简单，去除子布局中非必须的weight。

静态变量造成的内存泄露

结语：Android的性能优化是多方面的，比如启动速度优化、UI流畅度优化、apk瘦身、电量优化、内存优化等，这里只是对内存方面做一个简短的介绍。

Android性能优化

项目中的单例

项目中的单例

内存泄露

非静态内部类

Context 导致内存泄漏

集成LeakCanary内存泄露检测工具到项目

使用Lint分析

静态变量造成的内存泄露

你可能感兴趣的:(Android性能优化)