一文高端Android性能优化-总结篇

以下从几个方面来总结一下Android的性能优化：

1：界面卡顿优化

2：内存优化

3：App启动优化

界面卡顿优化

Android的界面为每秒60帧，即必须在16ms内完成1帧的绘制，如果某个方法耗时过程，导致16ms内无法完成绘制，会导致丢帧，丢帧的多了，直观上感受就是界面卡顿。

60帧是人眼观看动画比较合适的频率，如果每秒的帧数过少，即频繁的出现丢帧，就会感觉界面的卡顿。

1：通过Traceview找出卡主主线程的地方

卡住主线程说明函数在主线程被调用的时长比较长，包括：

1）单个函数调用的时长长

2）函数被调用的次数比较多

2：使用方法：

1）Terminal打开DDMS，输入指令：Monitor

2）点击start method profiling

3）操作APP可能有问题的界面

4）再次点击stop method profiling，生成表格：

3：具体案例分析：recyclerView的onBindViewHolder，当复用屏幕外的数据是，是脏数据，会进行重新绑定，调用onBindViewHolder

@Override

publicvoid onBindViewHolder(RecyclerView.ViewHolder holder, int position)

{

Log.d(TAG, "onBindViewHolder--->" + position);

。。。。。。

　　　　　　　。。。。。。。

SystemClock.sleep(7);

}

SystemClock.sleep(10)模拟RecyclerView滚动过程中的耗时操作，操作Recyclerview，得到以下表格：

Real Time/Call表示一个函数被调用的时长, Calls+Recursion + call totals表示一个函数被调用和被递归调用的次数

内存优化：

1：Memory Monitor：

Memory Monitor只能看个大概，可以查看内存抖动，或者内存增长的趋势，具体的小的泄漏，还得通过Heap Viewer查看

内存抖动：短时间内发生了多次内存的涨跌，意味着很有可能发生率内存抖动。

内存抖动带来的问题：短时间内的内存飙升，系统需要频繁的进行GC，而GC是需要主线程停下来，并且占用CPU资源的，会导致界面卡顿。

例子1：

publicvoid click(View view) {

for (int i = 0; i < 100; i++) {

byte[] b = newbyte[2000];

}

}

例子2：

privateint nums[][] = newint[250][250];

//内存抖动案例：

//短时间内创建大量的临时变量privatevoid init() {

Random random = new Random();

for (int i = 0; i < nums.length; i++) {

for(int j=0; j<nums[i].length; j++){

nums[i][j] = random.nextInt(1000);

}

}

}

privatevoid printNums(){
        String totalNums = "";
        for (int i = 0; i < nums.length; i++) {
            for(int j=0; j<nums[i].length; j++){
                totalNums += nums[i][j];
            }
        }
    }

//优化：
    private void printNums2(){
        StringBuffer totalNums = new StringBuffer();
        for (int i = 0; i < nums.length; i++) {
            for(int j=0; j<nums[i].length; j++){
                totalNums.append(nums[i][j]);
            }
        }
    }

使用Monitor监控：

避免内存抖动的方法：

1）尽量避免在循环体内创建对象，应该把对象创建移到循环体外

2）自定义view的onDraw会被频繁调用，避免在这个函数里面new一个新的对象

2：Heap Viewer：

监控：能够实时观测内存的变动（短时间内通过Memory Monitor是看不出来的，曲线坡度太小，内存变动值很小,定位不到具体的代码）

Heap Viewer具体定位到哪个位置内存泄漏。

内存泄漏例子：

protectedvoid onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //test1();        init();
        handler.sendEmptyMessageDelayed(0, 100000);
    }

//模拟当MainActivity跳转到MainActivity2的时候，
    // 延迟发送消息导致的内存泄漏问题private Handler handler = new Handler(){
        @Override
        publicvoid handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
        }
    };

    publicvoid click(){
        Intent intent = new Intent(this, MainActivity2.class);
        startActivity(intent);
        finish();
    }

首先运行应用，处在MainActivity，点击Dump Java Heap,获取当前内存的快照：

得到以下表格：

修改为根据包名查看更方便快速定位到我们自己的代码:

Leaks为0说明当前没有发生内存泄漏

MainActivity的depth为3，说明MainActivity有被引用

点击MainActivity的click，跳转到MainActivity2，MainActivity.finish(),模拟MainActivty发生内存泄漏的场景（Handler引用MainActivity导致内存泄漏），然后点击GC，再截取内存快照

Dump Java Heap：

黄色的Leaks为2说明发生了内存泄漏，点击Leaks,通过以下References可以找到MainActivity被引用的路径。

3：LeakCanary

在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存

在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存

在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存

在一个Activity执行完onDestroy后，将它放入到WeakReference中，然后将这个WeakReference类型的Activity的对象与ReferenceQueue关联，注意: 如果一个对象要被GC回收了，会把它引用的对象放入到ReferenceQueue中。这时候只需要在ReferenceQueue中去查找是否存在该对象，如果没有就执行一个GC，再次查找，如果还是没有，则说明该对象可能无法被回收，也就可能发生了内存泄漏，最后使用HAHA这个开源库取分析dump之后的heap内存

分为两个步骤：

1）通过虚引用的ReferenceQueue,判断一个对象是否被回收：

虚引用：对于对象来说，是无感的，如果只存在虚引用，GC的时候会直接被回收。虚引用的目的是为了追踪一个对象被回收的时机。如果一个定义了虚引用的对象GC之后被回收了，这个对象会被放入RefereceQueue中，LeakCanary就是在GC之后去检测该队列中是否有该对象判断该对象是否已经被回收。

2）初步判定有内存泄漏之后，通过开源库Haha分析dump之后的heap内存，从而定位到具体的内存泄露的对象的引用链条。

APP应用启动优化

1：冷启动和热启动

1）冷启动：app没有启动过或者进程被杀死，系统不存在该app进程，此时启动为冷启动。冷启动流程就是app启动流程全过程，包括创建app进程、加载资源、启动MainThread、初始化SplashActivity并加载布局等。

2）热启动：app暂时退到了后台，热启动将它从后台重新带到前台，展示给客户。

我们要做的优化就是针对热启动

3）：冷启动的函数调用过程：

Zygote Fork Proccess 
-> Application:attachBaseContext()
-> Application:onCreate() 
-> MainActiviity:onCreate()

2：用TraceView获取App的启动耗时，查找具体的耗时的函数进行优化：

publicclass MyApplication extends Application {

@Override

publicvoid onCreate() {

Debug.startMethodTracing("startApp");

super.onCreate();

try {

Thread.sleep(1000);

} catch (InterruptedException e) {

e.printStackTrace();

}

Debug.stopMethodTracing();

}

}

在/sdcard/目录下得到一个startApp.trace文件

通过DDMS打开该文件：可以看到Application里面的onCreate里的哪些代码进行了耗时操作：

3：解决方案：

1）将启动页主题背景设置成闪屏页图片

这么做的目的主要是为了消除启动时的黑白屏，给用户一种秒响应的感觉，但是并不会真正减少用户启动时间，仅属于视觉优化。

2）第三方工具的初始化一般都在Application的onCreate里面执行，会造成大量的耗时，解决方案：

a:放在子线程中加载不影响业务的情况，则优先选择放在子线程中加载

b:第三方工具的懒加载初始化，即用到的时候再进行初始化