Glide源码细节分析

1.Glide框架介绍
Glide框架是个图片加载框架，平时用的最多，功能最强大的图片加载框架，他对比universalimageloader 增加了Acitivyt和Fragment的生命周期的管理，也增加了一级缓存，Glide源码比ImageLoader的源码复杂很多，完全针对接口编程，导致很多方法很难找见对应实现类的入口，网上介绍Glide的代码个人感觉结构不是很清晰，分析的也不是重点，我对整个Glide做了一个详细的梳理，整理了一下大致脉络，下面大家跟我一起一点点剖析Glide的代码，Glide加载图片方法很简单也就一句话Glide.with(PicLoadActivity.this).load(url).diskCacheStrategy(DiskCacheStrategy.NONE).into(iv);，咱们一个个代码进行梳理
2.Glide.with(PicLoadActivity.this)
很多博客或者网站对这个方法没有进行分析，个人认为这个方法很重要，因为他是联动Activity和Fragement的生命周期，当加载的Actvitiy和Fragment destroy的时候，会销毁这个加载图片的请求，Glide是怎么做到的呢，只能从源码中得到答案了。①Glide.with(FragmentActivity activity)②Glide.with(Fragment fragment) ;③Glide.with(Context context) 这个方法大概有这三种形式分别对应activity的生命周期和Fragement 和Application的生命周期，咱们主要分析第一种，其他的简略说一下就可以了，功能实现都很类似

//和Acitivity生命周期做绑定的 最后返回一个RequestManager的管理
public static RequestManager with(FragmentActivity activity) {
    RequestManagerRetriever retriever = RequestManagerRetriever.get();
    return retriever.get(activity);
}

//获取RequestManager的方法
public RequestManager get(FragmentActivity activity) {
    if (Util.isOnBackgroundThread()) {
        //判断不是主线程的话调用这个，为什么要判断主线程了，大家不用着急看下面代码就清楚了
        return this.get(activity.getApplicationContext());
    } else {
        assertNotDestroyed(activity);
        //获取acitivy的FragmentManager，这个不是创建fragement时候用的吗？不错你猜对了，下面方法就要创建Fragement了
        android.support.v4.app.FragmentManager fm = activity.getSupportFragmentManager();
        return this.supportFragmentGet(activity, fm);
    }
}

RequestManager supportFragmentGet(Context context, android.support.v4.app.FragmentManager fm) {
    //看来真的添加了一个Fragement到activity里面，为什么要添加这个Fragement呢，下面有详细的代码大家可以
    //看一下
    SupportRequestManagerFragment current = this.getSupportRequestManagerFragment(fm);
    //第一次走这个方法的时候肯定为空
    RequestManager requestManager = current.getRequestManager();
    if (requestManager == null) {
        //创建一个RequestManager然后这个Fragement关联这个RequestManager,第二次进来的话就能通过		           				 //current.getRequestManager得到了，不用创建了
        //从这大家就明白了一个Activity对应创建一个空白的Fragement关联唯一一个RequestManager
        //获取fragment的lifecycle 添加一个lisenter 这样就能监听Fragement的生命周期了，在	   				                        ///RequestManager的onDestroy执行的就是
        //this.requestTracker.clearRequests();清空网络请求
        requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
        current.setRequestManager(requestManager);
    }

    return requestManager;
}

//创建Fragement添加到Activity里面 这个Fragement的生命周期就和Activity绑定了，Fragement里面有一//个lifecycle当生命周期变化的时候调用lifecycle的listenerSupportRequestManagerFragment
 getSupportRequestManagerFragment(android.support.v4.app.FragmentManager fm) {
    SupportRequestManagerFragment current = (SupportRequestManagerFragment)fm.findFragmentByTag("com.bumptech.glide.manager");
    if (current == null) {
        current = (SupportRequestManagerFragment)this.pendingSupportRequestManagerFragments.get(fm);
        if (current == null) {
            current = new SupportRequestManagerFragment();
            this.pendingSupportRequestManagerFragments.put(fm, current);
            fm.beginTransaction().add(current, "com.bumptech.glide.manager").commitAllowingStateLoss();
            this.handler.obtainMessage(2, fm).sendToTarget();
        }
    }

    return current;
}

Glide.with(Activity activity)这个方法控制怎么控制生命周期的，我感觉他用的很巧妙，为每一个Acitivyt添加一个空的Fragement，通过Fragement关联activity的生命周期，在Fragement添加一个lifecycle可以添加监听生命周期的listener这是个简单的观察者模式的案例，一个Fragement 关联一个RequestManager（从名字上看出这个是请求管理类）保证一个Acitivty对应一个Fragement对应一个RequestManager，RequestManager关联了Fragement的lifecycle内部还添加了listener（观察者角色），Fragement执行onDestroy(),onStart()这些方法的时候都会循环遍历每一个listener进行回调（Fragement这里相当主题角色，当发生变化的时候通知某一个listener进行回调）RequestManager的回调方法就对网络请求进行处理执行listener的onDestoy(),清空网络请求，这个时候恍然大悟为什么要判断是不是其他线程了(Util.isOnBackgroundThread()) ,只有主线程才能添加Fragement，其他的线程统一交个Application的RequestManager进行管理，Glide.with(Fragment fragment) 与activity类似只不过是创建一个空白的子Fragement添加到Fragement而已监听Fragement的生命周期，不过Application没有监听生命周期，个人猜测是不是Application 挂掉之后被系统杀死了，不用监听生命周期，资源都会被回收Glide不用做单独的处理，大家有什么不同的意见，可以在下面评论给出来，多谢指教！

Glide源码细节分析

猜你喜欢