对Android中的多图片异步加载的重新思考


起因

不知道大家有没有发现,在2.0.4.1(37)版本之前的开源中国客户端首次加载图片的时候,会很慢,尤其是动弹列表中的图片。甚至网速慢的时候感觉图片根本加载不出来。

原因是在下载网络图片的时候使用了多线程并发执行的方式,什么意思呢,也就是开启了多个线程同时去下载多张图片。按照正常的思维来想,做图片加载操作使用多线程,这应该是很正常的,因为在我们的思维中,多线程资源利用率更高,程序响应更快。

举个例子:一个应用程序需要从本地文件系统中读取和处理文件的情景。比方说,从磁盘读取一个文件需要5秒,处理一个文件需要2秒。处理两个文件则需要

  5秒读取文件A
  2秒处理文件A
  5秒读取文件B
  2秒处理文件B
---------------------
  总共需要14秒

从磁盘中读取文件的时候,大部分的CPU时间用于等待磁盘去读取数据。在这段时间里,CPU非常的空闲。它可以做一些别的事情。通过改变操作的顺序,就能够更好的使用CPU资源。看下面的顺序

  5秒读取文件A
  5秒读取文件B + 2秒处理文件A
  2秒处理文件B
---------------------
  总共需要12秒

CPU等待第一个文件被读取完。然后开始读取第二个文件。当第二文件在被读取的时候,CPU会去处理第一个文件。记住,在等待磁盘读取文件的时候,CPU大部分时间是空闲的。总的说来,CPU能够在等待IO的时候做一些其他的事情。这个不一定就是磁盘IO。它也可以是网络的IO,或者用户输入。通常情况下,网络和磁盘的IO比CPU和内存的IO慢的多。

既然采用多线程并发执行可以提高CPU的利用率,可是为什么反倒用在Android的图片加载上变得更慢了?

看到这里,你应该已经想到原因了。就好像我们写代码,一个人同时写两个Android应用,并发布上线。假设应用发布不需要上线审核,且A与B的功能几乎相同。如果我们去先写应用A的一个功能,当A某一个功能写完的时候再去写应用B相同的功能,那么写起来自然是要快很多。这就是并发执行,同时去执行A与B。但是这样A与B完成的总时间是缩短了,可以单个A应用完成的时间却被拉长了。因为写到一半的时候被迫去完成B应用。

所以这也是为什么你会发现37版本之前的OSC客户端图片几乎是同时出来的。

回到Android上,我之前的博客曾讲过:AsyncTask在android2.3的时候线程池是一个核心数为5线程,队列可容纳10线程,最大执行128个任务,这存在一个问题,当你真的有138个并发时,即使手机没被你撑爆,那么超出这个指标应用绝对crash掉。 后来升级到3.0,为了避免并发带来的一些列问题,AsyncTask竟然成为序列执行器了,也就是你即使你同时execute N个AsyncTask,它也是挨个排队执行的。 这一点请同学们一定注意,AsyncTask在3.0以后,是异步的没错,但不是并发的。不知道的同学可以去看看《Thread并发请求封装——深入理解AsyncTask类》《一套完善的Android异步任务类》

现在想来,Android SDK把并行执行改为串行执行也并不无道理。

也许你会担心,那改回串行以后会不会又出现同时加载129个图片的时候崩溃的问题。当然,是不会的。在图片加载的时候已经做了下载任务取消的设计,在listView中加载图片的时候,如果滚动出这一屏,图片的下载任务会马上停止,而去加载新的图片下载。总不会一个屏幕就显示129张图吧。

  /**
   * 取消一个下载请求
   *
   * @param view
   */
  public void cancle(View view) {
    for (BitmapWorkerTask task : taskCollection) {
      if (task.imageView.equals(view)) {
      task.cancelTask();
      taskCollection.remove(task);
      break;
      }
    }
  }


对Android中的多图片异步加载的重新思考


起因

不知道大家有没有发现,在2.0.4.1(37)版本之前的开源中国客户端首次加载图片的时候,会很慢,尤其是动弹列表中的图片。甚至网速慢的时候感觉图片根本加载不出来。

原因是在下载网络图片的时候使用了多线程并发执行的方式,什么意思呢,也就是开启了多个线程同时去下载多张图片。按照正常的思维来想,做图片加载操作使用多线程,这应该是很正常的,因为在我们的思维中,多线程资源利用率更高,程序响应更快。

举个例子:一个应用程序需要从本地文件系统中读取和处理文件的情景。比方说,从磁盘读取一个文件需要5秒,处理一个文件需要2秒。处理两个文件则需要

  5秒读取文件A
  2秒处理文件A
  5秒读取文件B
  2秒处理文件B
---------------------
  总共需要14秒

从磁盘中读取文件的时候,大部分的CPU时间用于等待磁盘去读取数据。在这段时间里,CPU非常的空闲。它可以做一些别的事情。通过改变操作的顺序,就能够更好的使用CPU资源。看下面的顺序

  5秒读取文件A
  5秒读取文件B + 2秒处理文件A
  2秒处理文件B
---------------------
  总共需要12秒

CPU等待第一个文件被读取完。然后开始读取第二个文件。当第二文件在被读取的时候,CPU会去处理第一个文件。记住,在等待磁盘读取文件的时候,CPU大部分时间是空闲的。总的说来,CPU能够在等待IO的时候做一些其他的事情。这个不一定就是磁盘IO。它也可以是网络的IO,或者用户输入。通常情况下,网络和磁盘的IO比CPU和内存的IO慢的多。

既然采用多线程并发执行可以提高CPU的利用率,可是为什么反倒用在Android的图片加载上变得更慢了?

看到这里,你应该已经想到原因了。就好像我们写代码,一个人同时写两个Android应用,并发布上线。假设应用发布不需要上线审核,且A与B的功能几乎相同。如果我们去先写应用A的一个功能,当A某一个功能写完的时候再去写应用B相同的功能,那么写起来自然是要快很多。这就是并发执行,同时去执行A与B。但是这样A与B完成的总时间是缩短了,可以单个A应用完成的时间却被拉长了。因为写到一半的时候被迫去完成B应用。

所以这也是为什么你会发现37版本之前的OSC客户端图片几乎是同时出来的。

回到Android上,我之前的博客曾讲过:AsyncTask在android2.3的时候线程池是一个核心数为5线程,队列可容纳10线程,最大执行128个任务,这存在一个问题,当你真的有138个并发时,即使手机没被你撑爆,那么超出这个指标应用绝对crash掉。 后来升级到3.0,为了避免并发带来的一些列问题,AsyncTask竟然成为序列执行器了,也就是你即使你同时execute N个AsyncTask,它也是挨个排队执行的。 这一点请同学们一定注意,AsyncTask在3.0以后,是异步的没错,但不是并发的。不知道的同学可以去看看《Thread并发请求封装——深入理解AsyncTask类》《一套完善的Android异步任务类》

现在想来,Android SDK把并行执行改为串行执行也并不无道理。

也许你会担心,那改回串行以后会不会又出现同时加载129个图片的时候崩溃的问题。当然,是不会的。在图片加载的时候已经做了下载任务取消的设计,在listView中加载图片的时候,如果滚动出这一屏,图片的下载任务会马上停止,而去加载新的图片下载。总不会一个屏幕就显示129张图吧。

  /**
   * 取消一个下载请求
   *
   * @param view
   */
  public void cancle(View view) {
    for (BitmapWorkerTask task : taskCollection) {
      if (task.imageView.equals(view)) {
      task.cancelTask();
      taskCollection.remove(task);
      break;
      }
    }
  }