源码分析glide对线程中断的优化

转载请注明出处:

源码分析glide对线程中断的优化

地址:http://blog.csdn.net/qq_22744433/article/details/78297635

目录

android中我们需要很小心对待线程的创建取、监听、取消。如果不小心处理,可能就会引入内存泄漏,监听的生命周期与宿主不一致导致crash,频繁创建线程对资源的消耗,线程无意义的运行等问题。那么这里对于线程中断,源码分析一下glide对其的优化。对于线程创建/监听的选择,总结了一些知识点。

1. 线程中断

1. 线程中断(取消)的方法

我们知道,如果一个线程已经被废弃了(没有监听者了),那么线程就没有继续运行的必要了。如果只是取消监听者,这么做肯定是不够的,因为线程还在运行。所以我们需要中断线程的运行来节省CPU,而线程的中断并不是一件容易的事。大体的方法是:

如果使用Thread.interrupt(),那么当线程处于阻塞状态时(比如wait住,sleep),那么线程会抛出InterruptException异常,退出循环。我们需要捕获这个异常,进行相应处理,不然就crash了。

如果是非阻塞情况下,Thread.interrupt()是不能把线程中断的。这时候只能设置volitie关键字来中断线程。

这两种情况需要配合使用来中断已经废弃且还在运行的线程。
Glide是一个很优秀的图片加载库。在处理大量图片上,其做了很多的优化,那么我们看下其对线程的取消(取消图片的网络加载)做了哪些事情:

2.源码分析glide对线程中断的优化

glide中EngineJob中:

public void removeCallback(ResourceCallback cb) {
Util.assertMainThread();
if (hasResource || hasException) {
    addIgnoredCallback(cb);
} else {
    cbs.remove(cb);
    if (cbs.isEmpty()) {
        cancel();
    }
}
}

void cancel() {
if (hasException || hasResource || isCancelled) {
    return;
}
engineRunnable.cancel();
Future currentFuture = future;
if (currentFuture != null) {
    currentFuture.cancel(true);
}
isCancelled = true;
listener.onEngineJobCancelled(this, key);
}

当一个图片加载任务EngineJob已经没有监听者时,会调用future的cancel()方法。future是提交给线程池任务返回的。当调用future的cancel(true)时,如果任务还没执行,那么就取消任务。如果任务已经执行,但被阻塞了,那么会调用Thread的interrupt()方法中断线程。
EngineJob中往线程池抛的task是:EngineRunnable,当调用其cancel()时:

    private volatile boolean isCancelled;


   public void cancel() {
    isCancelled = true;
    decodeJob.cancel();
}

@Override
public void run() {
    if (isCancelled) {
        return;
    }

    Exception exception = null;
    Resource resource = null;
    try {
        resource = decode();
    } catch (Exception e) {
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            Log.v(TAG, "Exception decoding", e);
        }
        exception = e;
    }

    if (isCancelled) {
        if (resource != null) {
            resource.recycle();
        }
        return;
    }

    if (resource == null) {
        onLoadFailed(exception);
    } else {
        onLoadComplete(resource);
    }
}

使用了volatile关键字来让runnable的方法不再执行。当task还在队列中还没有执行的话(这应该经常发生,如果发送的图片请求太多),那么直接return。如果已经请求执行,请求获取了数据后,也会做一次判断。

那么我们看下进行请求过程中

     resource = decode();,

是不是就不能中断了呢?网络请求在DecodeJob的decodeSource()方法:

  private Resource decodeSource() throws Exception {
    Resource decoded = null;
    try {
        long startTime = LogTime.getLogTime();
        final A data = fetcher.loadData(priority);
        if (Log.isLoggable(TAG, Log.VERBOSE)) {
            logWithTimeAndKey("Fetched data", startTime);
        }
        if (isCancelled) {
            return null;
        }
        decoded = decodeFromSourceData(data);
    } finally {
        fetcher.cleanup();
    }
    return decoded;
}

其中isCancelled也是volatie关键字,在 decodeJob.cancel();中会被置为true。前面代码中EngineRunnable#cancle()会调用这个方法。所以在请求完网络数据时,还会判断一下,是不是需要中断。如果需要,那么就不用解码了(解码是很耗时的操作)。那网络请求有没有在这方面做判断呢?真正的网络请求在DataFetcher#load()中。DataFetcher类的存在能够解耦图片加载的具体实现。比如你是使用android原生的http加载的(生成httpUrlConnection…),还是使用其他的协议加载的,还是使用第三方库加载的(比如okhttp)。这里我们以HttpUrlFetcher为例:

    private volatile boolean isCancelled;

     @Override
public InputStream loadData(Priority priority) throws Exception {
    return loadDataWithRedirects(glideUrl.toURL(), 0 /*redirects*/, null /*lastUrl*/, glideUrl.getHeaders());
}

private InputStream loadDataWithRedirects(URL url, int redirects, URL lastUrl, Map headers)
        throws IOException {
    if (redirects >= MAXIMUM_REDIRECTS) {
        throw new IOException("Too many (> " + MAXIMUM_REDIRECTS + ") redirects!");
    } else {
        // Comparing the URLs using .equals performs additional network I/O and is generally broken.
        // See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html.
        try {
            if (lastUrl != null && url.toURI().equals(lastUrl.toURI())) {
                throw new IOException("In re-direct loop");
            }
        } catch (URISyntaxException e) {
            // Do nothing, this is best effort.
        }
    }
    urlConnection = connectionFactory.build(url);
    for (Map.Entry headerEntry : headers.entrySet()) {
      urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
    }
    urlConnection.setConnectTimeout(2500);
    urlConnection.setReadTimeout(2500);
    urlConnection.setUseCaches(false);
    urlConnection.setDoInput(true);

    // Connect explicitly to avoid errors in decoders if connection fails.
    urlConnection.connect();
    if (isCancelled) {
        return null;
    }
    final int statusCode = urlConnection.getResponseCode();
    if (statusCode / 100 == 2) {
        return getStreamForSuccessfulRequest(urlConnection);
    } else if (statusCode / 100 == 3) {
        String redirectUrlString = urlConnection.getHeaderField("Location");
        if (TextUtils.isEmpty(redirectUrlString)) {
            throw new IOException("Received empty or null redirect url");
        }
        URL redirectUrl = new URL(url, redirectUrlString);
        return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
    } else {
        if (statusCode == -1) {
            throw new IOException("Unable to retrieve response code from HttpUrlConnection.");
        }
        throw new IOException("Request failed " + statusCode + ": " + urlConnection.getResponseMessage());
    }
}

这里也有一个volitile关键字isCancelled。当http链接已经建立了,这时候在进行请求(code/data)之前判断一下,如果已经取消了,那么就不进行请求数据或code了。isCancelled关键字会在其cancel()方法会置为true。而cancel()方法在DecodeJob的cancel()方法中会被调用。

所以当取消一个任务时,网络请求如果还没加载数据,会进行相应的中断。

通过上面的分析:当一个图片网络任务没有任何监听时,线程处于阻塞状态下、任务还没执行、网络连接后还没请求数据、数据请求结束还没解码、还没发送给监听者这些状态时,都会进行中断取消判断。所以glide在网络请求的取消这块做的真的很棒。

2. 线程的使用

上面说完了线程的取消。在android中使用线程,我们还需要注意是不是会导致内存泄漏,串行/并发,与UI线程交互,线程的创建销毁等问题,那么我这里总结一些知识点。并没有源码分析。

1. 直接new 一个线程

直接

new  thread(new runnable{ 
  @override
  public void run{
  ...
  } 
 }).start();

缺点:

  • 匿名内部类持有外部类的引用,会造成内存泄漏。
  • 线程优先级和ui线程一样高。
  • 需要自己使用handler处理与ui线程的通信。同时由于handler写法如果不规范,handler也会持有外部类的引用,造成内存泄漏。但是,如果handler写成静态内部类,那么如果handler的handleMessage(){//逻辑..}逻辑中使用到了activty中的某些view或成员变量,那么如果activty已经消失了(虽然持有了activty的成员变量,但静态handler并没有持有activty,所以activty还是可能被销毁。导致里面的view为空),那么这时候再操作这些view,就会报空指针。所以只能在逻辑的最前面加一些撇脚的 fragment!=null&&fragment.isAdd()的判断。这是因为这里使用handler处理与ui线程的通信并没有使用观察者模式。所以并没有取消订阅这些操作。导致很可能crash增加。AsyncTask同理。

  • 不好管理线程的取消。

2. 使用AsyncTask

不用自己去处理与ui线程的同步。
缺点:

  • 如果使用匿名内部类,会持有外部类的引用,会造成内存泄漏。
  • 直接使用不含有参数的execute()启动task,那么task是串行执行的。这点虽然不用考虑同步问题,但是如果task多的话,会有性能影响。如果想并发执行task,那么需要使用带参数的execute(ExecutorService),即指定线程池。
  • AsyncTask需要使用cancel()取消订阅(有时候可能会不起作用),不然可能造成crash。与上面同理。

3.使用 HandlerThread

handlerThread 是含有一套looper,handler,messageQueue的线程。如果我们有一个业务场景:需要一个持久的后台线程,且该线程与ui线程需要相互通信。使用handlerThread会比较方便。

缺点

  • 如果activty界面消失了,那么不容易找到这个handlerThread,并且这个thread的优先级并没有那么高,很可能在内存吃紧的时候被销毁。所以HandlerThread一般是在其他组件内部使用,比如IntentService、ThreadPoolExecutor的coreThread都是基于HandlerThread形成的。
  • 使用HandlerThread的handler向HandlerThread抛任务时,是串行执行的。

4. 使用IntentService

前面说了,IntentService内部的工作原理就是service+HandlerThread。我们一般使用service时,一般启动有两种方式:
一种:startService(Intent)通过intent来指派执行任务(service的onStartCommand(intent)会被回调)。生命周期比较长,如果不手调用selfStop()/stopService,那么service会一直存在(即使activty销毁了)。
第二种:如果使用bindService(intent)(service的onBind(ServiceConnection)会被回调),如果所有页面的地方都unBindService(),那么service就会被停止。并且,不像开启一个线程后,我们基本不能再对线程做什么了。我们可以通过binder获取到service的实例(startService()或bindService()也只能回调service的某些生命周期方法,并不能得到service实例本身),进而调用service实例的某些方法来调控后台。

虽然上面两种方式我们都可以在service中创建新线程来执行新的任务。如果我们的任务不紧急,我们也不想操心线程创建的事情。我们就可以直接使用IntentService来开启一个后台。
相比直接使用线程开启后台,service的优先级更高,更不容易被销毁。

5. 使用线程池

线程池的worker线程(线程池中,线程被封装成了work类)其实和HandlerThread差不多。都是一个无线循环的线程。task执行完了,再到线程池workQueue阻塞队列中拿task来执行。coreThread核心线程即使没有任务,也不会被回收。当task超过了核心线程的数量,那么就放到阻塞队列中。如果阻塞队列也塞满了任务,那么就继续开启worker,直到所有worker的数目到MaxThreadNum,这时候使用某些策略来回应,比如停止接收,报错等。

你可能感兴趣的:(源码分析)