2301_76766616

android优化篇

布局优化

大家肯定都知道Android中有许多布局，比如Linerlayout、RelativeLayout等，布局优化就是减少布局文件层级，层级减少了，那么程序绘制时就快了许多，所以可以提高性能。

在布局代码中，使用什么布局基本遵守以下规则：

如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。
如果布局需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout，因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。

3.使用或标签和ViewStub，提取布局中公共部分的布局，可提高布局初始化效率。

内存泄漏优化

内存泄漏优化换句话说，就是什么情况可能会导致内存泄漏：

不要再Acticity中声明静态变量，这样会是的Activity无法完全销毁释放
单例设计模式一起的内存泄漏，单例设计模式的静态特性会使他的生命周期和应用程序的生命周期一样长，这就说明了如果一个对象不在使用了，而这时单例对象还在持有该对象的引用，这时GC就会无法回收该对象，造成了内存泄露的情况。所以使用单例模式时，传入的context应该使用ApplicationContext
非静态内部类创建的静态实例造成的内存泄漏
Handler造成的内存泄漏，不要在Activity中用非静态匿名内部类的方式去引用hanlder，比如:

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        loadData();
    }
    private void loadData(){
        Message message = Message.obtain();
        mHandler.sendMessage(message);
    }
}

这样hanlder会持有Activity的引用，handler是运行在一个Looper线程中的，而Looper线程是轮询来处理消息队列中的消息的，假设我们处理的消息有10条，而当他执行到第6条的时候，用户退出销毁了当前的Activity，这个时候消息还没有处理完，handler还在持有Activity的引用，这个时候就会导致无法被GC回收，造成了内存泄漏。

RecyclerView优化

RecyclerView缓存机制

众所周知，RecyclerView拥有四级缓存，它们分别是：

Scrap缓存：包括mAttachedScrap和mChangedScrap，又称屏内缓存，不参与滑动时的回收复用，只是用作临时保存的变量。
- mAttachedScrap：只保存重新布局时从RecyclerView分离的item的无效、未移除、未更新的holder。
- mChangedScrap：只会负责保存重新布局时发生变化的item的无效、未移除的holder。
CacheView缓存：mCachedViews又称离屏缓存，用于保存最新被移除(remove)的ViewHolder，已经和RecyclerView分离的视图，这一级的缓存是有容量限制的，默认最大数量为2。
ViewCacheExtension：mViewCacheExtension又称拓展缓存，为开发者预留的缓存池，开发者可以自己拓展回收池，一般不会用到。
RecycledViewPool：终极的回收缓存池，真正存放着被标识废弃(其他池都不愿意回收)的ViewHolder的缓存池。这里的ViewHolder是已经被抹除数据的，没有任何绑定的痕迹，需要重新绑定数据。

RecyclerView的回收原理

（1）如果是RecyclerView不滚动情况下缓存(比如删除item)、重新布局时。

把屏幕上的ViewHolder与屏幕分离下来，存放到Scrap中，即发生改变的ViewHolder缓存到mChangedScrap中，不发生改变的ViewHolder存放到mAttachedScrap中。
剩下ViewHolder会按照mCachedViews > RecycledViewPool的优先级缓存到mCachedViews或者RecycledViewPool中。

（2）如果是RecyclerView滚动情况下缓存(比如滑动列表)，在滑动时填充布局。

先移除滑出屏幕的item，第一级缓存mCachedViews优先缓存这些ViewHolder。
由于mCachedViews最大容量为2，当mCachedViews满了以后，会利用先进先出原则，把旧的ViewHolder存放到RecycledViewPool中后移除掉，腾出空间，再将新的ViewHolder添加到mCachedViews中。
最后剩下的ViewHolder都会缓存到终极回收池RecycledViewPool中，它是根据itemType来缓存不同类型的ArrayList，最大容量为5。

RecyclerView的复用原理

当RecyclerView要拿一个复用的ViewHolder时：

如果是预加载，则会先去mChangedScrap中精准查找(分别根据position和id)对应的ViewHolder。
如果没有就再去mAttachedScrap和mCachedViews中精确查找(先position后id)是不是原来的ViewHolder。
如果还没有，则最终去mRecyclerPool找，如果itemType类型匹配对应的ViewHolder，那么返回实例，让它重新绑定数据。
如果mRecyclerPool也没有返回ViewHolder才会调用createViewHolder()重新去创建一个。

这里有几点需要注意：

在mChangedScrap、mAttachedScrap、mCachedViews中拿到的ViewHolder都是精准匹配。
mAttachedScrap和mCachedViews没有发生变化，是直接使用的。
mChangedScrap由于发生了变化，mRecyclerPool由于数据已被抹去，所以都需要调用onBindViewHolder()重新绑定数据才能使用。

缓存机制总结

RecyclerView最多可以缓存 N（屏幕最多可显示的item数【Scrap缓存】） + 2 (屏幕外的缓存【CacheView缓存】) + 5*M (M代表M个ViewType，缓存池的缓存【RecycledViewPool】)。
RecyclerView实际只有两层缓存可供使用和优化。因为Scrap缓存池不参与滚动的回收复用，所以CacheView缓存池被称为一级缓存，又因为ViewCacheExtension缓存池是给开发者定义的缓存池，一般不用到，所以RecycledViewPool缓存池被称为二级缓存。

如果想深入了解RecyclerView缓存机制的同学，可以参考《RecyclerView的回收复用缓存机制详解》这篇文章。

性能优化方案

根据上面我们对缓存机制的了解，我们可以简单得到以下几个大方向：

1.提高ViewHolder的复用，减少ViewHolder的创建和数据绑定工作。【最重要】
2.优化onBindViewHolder方法，减少ViewHolder绑定的时间。由于ViewHolder可能会进行多次绑定，所以在onBindViewHolder()尽量只做简单的工作。
3.优化onCreateViewHolder方法，减少ViewHolder创建的时间。

提高ViewHolder的复用

1.多使用Scrap进行局部更新。