Android性能优化方案

Android性能优化有以下一个方面：

ANR,内存溢出，内存抖动，内存泄漏，UI卡顿，冷启动优化等方面来回答

1.ANR

• 主线程被io操作阻塞（4.0后网络io不允许主线程中）。
• 主线程做了耗时任务超过 5秒。
• Service做了耗时操作超过20秒，这是由于service默认执行在主线程，可以使用IntentService 。
• BroadcastReceiver的onReciver做了耗时操作超过10秒。

解决方式：

• 开一个子线程，使用Handler来处理。
• 使用AsyncTask来处理耗时任务。

2.内存溢出

内存溢出主要是由于加载大的图片引起的。解决方式：

1. 及时释放bitmap，调用.recycler（Bitmap会占用java内存和c(native)内存，java内存会自动释放，c内存需要手动释放）。
2. 使用lru 最近最少使用
   LruCache来存储对象put(key,value),,使用的使用LinkHashMap()。
3. 计算inSampleSize
   官方提供的方法，使用BitmapFactory.Options来计算inSampleSize(图片的缩略比)
4. 缩略图
   使用Options的inJustDecodeBounds属性来处理加载缩略图
5. 三级缓存
   内存，本地，网络。

3.内存泄露

内存泄漏是指无用对象（不在使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成的内存空间的浪费称为内存泄漏。

（1）单例导致内存泄漏

public class SingleInstanceTest { 
    private static SingleInstanceTest sInstance; 
    private Context mContext; 
    private SingleInstanceTest(Context context){ 
            this.mContext = context; 
    } 
    public static SingleInstanceTest newInstance(Context context){ 
            if(sInstance == null){ 
                sInstance = new SingleInstanceTest(context); 
            } return sInstance; 
    } 
}

上面是一个比较简单的单例模式用法，需要外部传入一个 Context 来获取该类的实例，如果此时传入的 Context 是 Activity 的话，此时单例就有持有该 Activity 的强引用（直到整个应用生命周期结束）。这样的话，即使该 Activity 退出，该 Activity 的内存也不会被回收，这样就造成了内存泄露，特别是一些比较大的 Activity，甚至还会导致 OOM（Out Of Memory）。

解决方式：

public class SingleInstanceTest { 
    private static SingleInstanceTest sInstance; 
    private Context mContext; 
    private SingleInstanceTest(Context context){ 
            his.mContext = context.getApplicationContext();
    } 
    public static SingleInstanceTest newInstance(Context context){ 
            if(sInstance == null){ 
                sInstance = new SingleInstanceTest(context); 
            } return sInstance; 
    } 
}

（2）内部类导致内存泄漏

非静态内部类会默认持有外部类的引用。会导致内部类的生命周期过长。
正确的做法就是修改成静态内部类。

（3）Handler
看下面的代码

 

public class HandlerActivity extends AppCompatActivity {
    private final static int MESSAGECODE = 1 ;
    private final Handler handler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Log.d("mmmmmmmm" , "handler " + msg.what ) ;
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        //点击结束Activity
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                finish();
            }
        });
         //新建线程，内部类
        new Thread(new Runnable() {
            @Override
            public void run() {
                handler.sendEmptyMessage( MESSAGECODE ) ;
                try {
                    Thread.sleep( 8000 );
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                //持有对象的引用
                handler.sendEmptyMessage( MESSAGECODE ) ;
            }
        }).start() ;
    }
}

这段代码运行起来后，立即点击 finish 按钮，通过检测，发现 HandlerActivity 出现了内存泄漏。

当Activity finish后，延时消息会继续存在主线程消息队列中8秒钟，然后处理消息。而该消息引用了Activity的Handler对象，然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完，这样就导致该Activity对象无法被回收，从而导致了上面说的 Activity泄露。

Handler 是个很常用也很有用的类，异步，线程安全等等。如果有下面这样的代码，会发生什么呢？ handler.postDeslayed ，假设 delay 时间是几个小时… 这意味着什么？意味着只要 handler 的消息还没有被处理结束，它就一直存活着，包含它的 Activity 就跟着活着。

我们来想办法修复它，修复的方案是 WeakReference ，也就是所谓的弱引用。垃圾回收器在回收的时候，是会忽视掉弱引用的，所以包含它的 Activity 会被正常清理掉。

解决方式
1.静态内部类
2.弱引用
3.注意在onDestroy中移除消息

public class HandlerActivity extends AppCompatActivity {
    private final static int MESSAGECODE = 1 ;
    private static Handler handler ;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        findViewById( R.id.finish ).setOnClickListener(new View.OnClickListener() 
            @Override
            public void onClick(View v) {
                finish();
            }
        });
        //创建Handler
        handler = new MyHandler( this ) ;
        //创建线程并且启动线程
        new Thread( new MyRunnable() ).start();
    }
    private static class MyHandler extends Handler {
        WeakReference<HandlerActivity> weakReference ;
      public MyHandler(HandlerActivity activity ){
            weakReference  = new WeakReference<HandlerActivity>( activity) ;
        }
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if ( weakReference.get() != null ){
                // update android ui
                Log.d("mmmmmmmm" , "handler " + msg.what ) ;
            }
        }
    }
    private static class MyRunnable implements Runnable {
        @Override
        public void run() {
            handler.sendEmptyMessage( MESSAGECODE ) ;
            try {
                Thread.sleep( 8000 );
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            handler.sendEmptyMessage( MESSAGECODE ) ;
        }
    }
}

 

4.UI卡顿

1. 在UI线程中做轻微耗时操作，会导致UI线程卡顿
2. 布局Layout过于复杂，无法再16ms内完成渲染
   60fps-->16ms
   60ms一帧 每过16ms就会更新一下ui，要达到60ms一帧，否则可能会卡顿
3. 同一时间动画执行的次数过多，导致cpu或gpu负载过重。
4. View过度绘制，导致某些像素在同一时间内被绘制多次，从而导致cpu，gpu负载过重。
   overdraw
   过度绘制，
5. view频繁的触发measure。layout，导致measure。layout累计耗时过多以及整个view频繁的重新渲染
6. 内存频繁触发Gc过多，导致展示阻塞渲染操作
7. 屯余资源及逻辑导致加载和执行缓慢

解决ui卡顿:
1.布局优化 include，merge，viewsuble
2.背景和图片等内存分配优化