赞
踩
前言:
在移动端开发中,我们必须正确处理好主线程和子线程之间的关系,耗时操作必须在子线程中完成,避免阻塞主线程,导致ANR。异步处理技术是提高引用性能,解决主线程和子线程之间通信问题的关键。
通常在如下两种情况下会弹出ANR对话框:
造成以上两种情况的首要原因就是在主线程(UI线程)里面做了太多的阻塞耗时操作, 例如文件读写, 数据库读写, 网络查询等等,避免ANR,其实就是不能在主线程中进行耗时操作,这就需要用到异步处理技术了。
异步处理技术有很多种,常见的有Thread、AsyncTask、Handler&Looper、Executor等。一个完整的异步处理技术的继承树如下所示:
下面我们就根据继承树的结构并结合具体使用和源码一一展开介绍。
一、Thread
线程作为Java语言的一个概念,是实际执行任务的基本单元,Thread是异步处理技术的基础。它的使用相当简单,简单的讲,创建线程的方法有两种:
1.继承Thread类并重写run方法
语句如下
public class Mythread extends Thread { @Override public void run() { //实现具体的逻辑,如文件读写,网络请求等 } public void startThread(){ Mythread mythread = new Mythread(); mythread.start();//使用start启动线程 } }
2.实现Runnable接口并实现run方法
public class MyRunnable implements Runnable { @Override public void run() { //实现具体的逻辑,如文件读写,网络请求等 } public void startThread(){ MyRunnable runnable = new MyRunnable(); Thread thread = new Thread(runnable); thread.start();//同样利用start启动线程 } }
这里需要注意的一点是,如果我们没有利用start方法去启动线程,而是直接调用run方法,那这将不会是一个异步操作,而只是一个简单的方法调用,其操作还是在主线程上进行的。
3.Android中的线程分类
此外,我们再扩展一下Android应用中线程的概念。Android引用中的各类线程其本质都是基于Linux系统的pthreads,在应用层可以分为三种类型的线程。
1.主线程:主线程也被称为UI线程,它随着应用的启动而启动,主线程用来运行Android组件,同时刷新屏幕上的UI元素。Android系统如果检测到非主线程在更新UI组件,则会抛出CallFromWrongThreadException异常。为什么只有主线程才能操作UI,这是因为Android的UI工具包并不是线程安全的。主线程中创建的Handler会顺序执行接收到的消息,包括从其他线程中发送的消息。因此,如果消息队列中前面的消息没有很快执行完,那么就会阻塞队列中的 其他消息的及时处理。
2.Binder线程:Binder线程用于不同进程之间的线程通信(其原理在前面文章中有提到),每个进程都维护了一个Binder线程池,用于处理其他进程中线程发送的消息。这些进程包括系统服务、Intents、ContentProvider和Service等。在大部分情况下,应用不需要关心Binder线程,因为系统会优先将请求转换为使用主线程。一个典型的应用场景就是应用提供给其他进程通过AIDL接口绑定的Service。
3.后台线程,在应用中显示创建的线程都是后台线程,也就是当刚创建处理的时候,折现线程的执行体是空的,需要手动添加任务。
为什么有主线程和后台线程的区别,在Linux层面上,主线程和后台线程是一样的,在Android框架中通过WindowManager赋予了主线程只能处理UI更新、后台线程不能直接操作UI的限制。
二、HandlerThread
HandlerThread是一个集成了Looper和MessageQueue的线程,当启动HandlerThread的同时,会生成Looper和MessageQueue,然后等待消息进行处理。
先看一下这个类的结构
既然是集成自Thread类,我们先来看一下它的run方法的源码
@Override public void run() { mTid = Process.myTid(); Looper.prepare(); synchronized (this) { mLooper = Looper.myLooper(); notifyAll(); } Process.setThreadPriority(mPriority); onLooperPrepared(); Looper.loop(); mTid = -1; }
可以发现,HandlerThread内部集成了Looper,通过Looper.prepare()新建了一个Looper。
具体最后会调用到以下方法:
private static void prepare(boolean quitAllowed) { if (sThreadLocal.get() != null) { throw new RuntimeException("Only one Looper may be created per thread"); } sThreadLocal.set(new Looper(quitAllowed)); }
其中 sThreadLocal是ThreadLocal<Looper>类型的变量。
使用HandlerThread的好处在于开发者不需要自己去创建并维护Looper,它的用法和普通线程是一致的
HandlerThread handlerThread = new HandlerThread("myHandlerThread"); handlerThread.start(); Handler myHandler = new Handler(handlerThread.getLooper()){ @Override public void handleMessage(Message msg) { super.handleMessage(msg); //处理接收到的消息 } };
HandlerThread内部只有一个消息队列,队列中的消息是顺序执行的,因而是线程安全的,当然其吞吐量会有一定影响,队列中的任务可能会被前面没有执行完的任务阻塞。
这个时候有人可能会有这样的疑问,那有没有可能出现发送消息的时候Looper还没有准备好呀。这一点我们通过源码,看到其内部的机制就能确保创建Looper和发送消息之间不存在竞态条件。
/** * This method returns the Looper associated with this thread. If this thread not been started * or for any reason is isAlive() returns false, this method will return null. If this thread * has been started, this method will block until the looper has been initialized. * @return The looper. */ public Looper getLooper() { if (!isAlive()) { return null; } // If the thread has been started, wait until the looper has been created. synchronized (this) { while (isAlive() && mLooper == null) { try { wait(); } catch (InterruptedException e) { } } } return mLooper; }
当线程已经启动,Looper还没有准备好的时候,线程会进行wait状态。
在HandlerLooper中还有一个方法声明,onLooperPrepared(),这个方法可以被重写,用于在HandlerThread开始接受消息之前进行某些初始化操作。
import android.os.Handler; import android.os.HandlerThread; import android.os.Message; import android.os.Process; /** * Created by HustZhb on 2017/8/3. * 描述: */ public class MyHandlerThread extends HandlerThread{ private Handler mHandler; public MyHandlerThread() { super("MyHandlerThread", Process.THREAD_PRIORITY_BACKGROUND); } @Override protected void onLooperPrepared() { super.onLooperPrepared(); mHandler = new Handler(getLooper()){ @Override public void handleMessage(Message msg) { switch (msg.what){ case 1: //处理message break; case 2: //处理message break; default: break; } } }; } public void publishedMehthod1(){ mHandler.sendEmptyMessage(1); } public void publishMehthod2(){ mHandler.sendEmptyMessage(2); } }
上述例子在onLooperPrepared函数中创建了与HandlerThread关联的Handler实例,同样对外隐藏了我们的Handler实例。
三、AsyncQueryHandler
而在HandlerThread的基础上,AsyncQueryHandler是用于在ContentProvider上执行异步的CRUD操作的工具类,其中CRUD操作被放到一个单独的子线程中进行,当操作获取到结构后通过message的形式传递给调用AsyncQueryHandler的线程,通常就是主线程。
AsyncQueryHandler是一个抽象类,它继承自Handler,通过封装ContentResolver、HandlerThread和Handler等实现对ContentProvider的异步操作。
通过这个类结构,我们陷入就可以发现其中似乎封装了如下四个方法来操作ContentProvider,同样又封装了对应的四个回调函数。具体如下所示:
四个CRUD方法
//删除操作 public final void startDelete(int token, Object cookie, Uri uri, String selection, String[] selectionArgs) { // Use the token as what so cancelOperations works properly Message msg = mWorkerThreadHandler.obtainMessage(token); msg.arg1 = EVENT_ARG_DELETE; WorkerArgs args = new WorkerArgs(); args.handler = this; args.uri = uri; args.cookie = cookie; args.selection = selection; args.selectionArgs = selectionArgs; msg.obj = args; mWorkerThreadHandler.sendMessage(msg); } //插入操作 public final void startInsert(int token, Object cookie, Uri uri, ContentValues initialValues) { // Use the token as what so cancelOperations works properly Message msg = mWorkerThreadHandler.obtainMessage(token); msg.arg1 = EVENT_ARG_INSERT; WorkerArgs args = new WorkerArgs(); args.handler = this; args.uri = uri; args.cookie = cookie; args.values = initialValues; msg.obj = args; mWorkerThreadHandler.sendMessage(msg); } //查找操作 public void startQuery(int token, Object cookie, Uri uri, String[] projection, String selection, String[] selectionArgs, String orderBy) { // Use the token as what so cancelOperations works properly Message msg = mWorkerThreadHandler.obtainMessage(token); msg.arg1 = EVENT_ARG_QUERY; WorkerArgs args = new WorkerArgs(); args.handler = this; args.uri = uri; args.projection = projection; args.selection = selection; args.selectionArgs = selectionArgs; args.orderBy = orderBy; args.cookie = cookie; msg.obj = args; mWorkerThreadHandler.sendMessage(msg); } //更新操作 public final void startUpdate(int token, Object cookie, Uri uri, ContentValues values, String selection, String[] selectionArgs) { // Use the token as what so cancelOperations works properly Message msg = mWorkerThreadHandler.obtainMessage(token); msg.arg1 = EVENT_ARG_UPDATE; WorkerArgs args = new WorkerArgs(); args.handler = this; args.uri = uri; args.cookie = cookie; args.values = values; args.selection = selection; args.selectionArgs = selectionArgs; msg.obj = args; mWorkerThreadHandler.sendMessage(msg); }
其实现逻辑都是类似的,通过新建一个WorkerArgs来实现配置参数,并将这个配置后的实例传递到msg.obj,然后通过handler发送消息。最后应该是在WorkerHandler中的handleMessage中来调用ContentResolver的对应方法。
具体代码如下:
@Override public void handleMessage(Message msg) { final ContentResolver resolver = mResolver.get(); if (resolver == null) return; WorkerArgs args = (WorkerArgs) msg.obj; int token = msg.what; int event = msg.arg1; switch (event) { case EVENT_ARG_QUERY: Cursor cursor; try { cursor = resolver.query(args.uri, args.projection, args.selection, args.selectionArgs, args.orderBy); // Calling getCount() causes the cursor window to be filled, // which will make the first access on the main thread a lot faster. if (cursor != null) { cursor.getCount(); } } catch (Exception e) { Log.w(TAG, "Exception thrown during handling EVENT_ARG_QUERY", e); cursor = null; } args.result = cursor; break; case EVENT_ARG_INSERT: args.result = resolver.insert(args.uri, args.values); break; case EVENT_ARG_UPDATE: args.result = resolver.update(args.uri, args.values, args.selection, args.selectionArgs); break; case EVENT_ARG_DELETE: args.result = resolver.delete(args.uri, args.selection, args.selectionArgs); break; } // passing the original token value back to the caller // on top of the event values in arg1. Message reply = args.handler.obtainMessage(token); reply.obj = args; reply.arg1 = msg.arg1; if (localLOGV) { Log.d(TAG, "WorkerHandler.handleMsg: msg.arg1=" + msg.arg1 + ", reply.what=" + reply.what); } reply.sendToTarget(); } }
这里我们可以发现在调用完CRUD操作后,它将结果填充到了reply这个Message对象上,发回到调用方。
四个可重写的回调方法
protected void onQueryComplete(int token, Object cookie, Cursor cursor) { // Empty } protected void onInsertComplete(int token, Object cookie, Uri uri) { // Empty } protected void onUpdateComplete(int token, Object cookie, int result) { // Empty } protected void onDeleteComplete(int token, Object cookie, int result) { // Empty }
我们可以根据实际的需求来实现下面的回调方法,从而得到上面的CRUD操作的返回结果。
四、IntentService
IntentService想必大家也不陌生,相比较于Service而言,Service的各个生命周期都是运行在主线程的,因此它本身并不具备异步的能力,所以一般我们在使用Service的时候需要在其中的onStartCommand方法中自己手动新建一个子线程,并且,在子线程的run方法中最后调用stopSelf方法结束自身来确保结束服务。
而这样的写法增加了出错的可能性,忘开线程或者忘记调用stopSelf方法。虽有为了更好的实现一个异步的、可自动停止的服务,Android专门引入了一个Service的子类 IntentService来实现这种操作。
IntentService具有和Service一样的生命周期,同时也提供了后台线程中处理异步任务的机制。与HandlerThread类似,IntentService也是在一个后台线程中顺序执行所有的任务。我们可以通过给Context.startService传递一个Intent类型的参数可以启动IntentService的异步执行,如果此时IntentService正在运行,那么这个新的Intent将会进入到队列中进行排队,知道后台线程处理完队列前面的任务。如果此时IntentService没有在运行,那么将会启动一个新的IntentService,当后台线程队列中所有任务处理后,IntentService将自动结束它的生命周期。
IntentService本身是一个抽象类,使用它之前需要继承并实现其中的onHandleIntent(Intent)方法,在这个方法中实现具体的后台处理业务逻辑,同时在子类的构造方法中需要调用弗雷的有参构造函数。传入子类的名字。
import android.app.IntentService; import android.content.Intent; import android.support.annotation.Nullable; public class SimpleIntentService extends IntentService { /** * Creates an IntentService. Invoked by your subclass's constructor. * * @param name Used to name the worker thread, important only for debugging. */ public SimpleIntentService(String name) { super(SimpleIntentService.class.getName()); setIntentRedelivery(true); } @Override protected void onHandleIntent(@Nullable Intent intent) { //这个方法是在后台线程中调用的 } }
当我们需要启动这个IntentService的时候,我们只需要进行以下操作。
Intent intentService = new Intent(this,SimpleIntentService.class); startService(intentService);
当然,其中有一步是不能够遗忘的,IntentServie作为Service的子类,它同样需要在AndroidManifest文件中注册这个类。
(这里我们在其构造器中写入了一行setIntentRedelivery(true),这边先不解释,下面结合源码会提到)
下面结合源码来看一个它内部的实现。首先先放一张它的类结构图。
下面是一个完整的源码
public abstract class IntentService extends Service { private volatile Looper mServiceLooper; private volatile ServiceHandler mServiceHandler; private String mName; private boolean mRedelivery; private final class ServiceHandler extends Handler { public ServiceHandler(Looper looper) { super(looper); } @Override public void handleMessage(Message msg) { onHandleIntent((Intent)msg.obj); stopSelf(msg.arg1); } } public IntentService(String name) { super(); mName = name; } public void setIntentRedelivery(boolean enabled) { mRedelivery = enabled; } @Override public void onCreate() { super.onCreate(); HandlerThread thread = new HandlerThread("IntentService[" + mName + "]"); thread.start(); mServiceLooper = thread.getLooper(); mServiceHandler = new ServiceHandler(mServiceLooper); } @Override public void onStart(@Nullable Intent intent, int startId) { Message msg = mServiceHandler.obtainMessage(); msg.arg1 = startId; msg.obj = intent; mServiceHandler.sendMessage(msg); } @Override public int onStartCommand(@Nullable Intent intent, int flags, int startId) { onStart(intent, startId); return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY; } @Override public void onDestroy() { mServiceLooper.quit(); } @Override @Nullable public IBinder onBind(Intent intent) { return null; } @WorkerThread protected abstract void onHandleIntent(@Nullable Intent intent); }
代码的逻辑很简答,在onCreate方法中,我们可以清晰地看到IntentService是通过HandlerThread来实现后台任务的处理,
@Override public void onCreate() { super.onCreate(); HandlerThread thread = new HandlerThread("IntentService[" + mName + "]"); thread.start(); mServiceLooper = thread.getLooper(); mServiceHandler = new ServiceHandler(mServiceLooper); }
此外,还有一点需要知道的,刚才在继承IntentService的例子中,我们在其构造器中写入了一行setIntentRedelivery(true),这一行代码的作用是什么呢?
从字面上看是设置Intent重现投递为真。其效果是IntentService的onStartCommand方法将返回 START_REDELIVER_INTENT,这时,如果onHandleIntent方法返回之前进程死亡,那么在进程重新启动的时候,intent会重新投递。
@Override public int onStartCommand(@Nullable Intent intent, int flags, int startId) { onStart(intent, startId); return mRedelivery ? START_REDELIVER_INTENT : START_NOT_STICKY; }
五、Executor FrameWork
1.概述
下面我们来介绍在Java并发开发中经常用到的一个框架Java Executor框架。我们知道创建和销毁对象是存在开销的,如果应用中频繁出现线程的创建和销毁会影响到应用的性能,使用Java Executor 框架可以通过线程池等机制解决这个问题。
1.创建工作线程池,同时通过队列来控制这些线程执行的任务的个数
2.检测导致线程意外终止的错误
3.等待线程执行完成并获取执行结果
4.批量执行线程,并通过固定的顺序获取执行结果
5.在合适的时机启动后台线程,从而保证线程执行结果可以很快反馈给用户。
Executor框架主要由以下三部分组成:
1.任务 包括被执行任务需要实现的接口:Runnable接口或者Callable接口
2.任务的执行 包括任务执行机制的核心接口Executor,以及继承自Executor的ExecutorService接口(Executor框架中有两个类实现了ExecutorService接口,ThreadPoolExecutor和ScheduledThreadExecutor)
3.异步计算的结构 包括接口Future和实现Future接口的Future的FutureTask类。
2.Executor框架中的重要组成部分
1)Executor框架的基础是一个Executor的接口,Executor的主要作用是分离任务的创建和执行,最终实现上述功能。
public interface Executor {
void execute(Runnable command);
}
2)ThreadPoolExecutor是线程池的核心实现类,用来执行被提交的任务。
3)ScheduledThreadPoolExecutor是一个实现类,可以在给定的延迟后执行命令,或者定期执行命令。ScheduledThreadPoolExecutor比Timer更灵活,功能也更加强大。
4)Future接口和实现Future接口的FutureTask类,代表异步计算的结果。
5)Runnable和Callable接口的实现类,可以被ThreadPoolExecutor和ScheduledThreadPoolExecutor执行。
主线程首先要创建一个实现Runnable接口或者Callable接口的任务对象,工具类Executors可以把一个Runnbale对象封装为Callable对象。(Executors.callable(Runnbale task )或 Executor.callable(Runnbale task, Object result)),然后将Runnbale对象直接交给ExecutorService执行(ExecutorService.execute(Runnbale command))或是将Runnbale对象或Callable对象提交给ExecutorServie执行(ExecutorService.submit(Runnable task)或ExecutorService.submit(Callable<T> task))
如果执行的是submit方法,ExecutorService将返回一个实现Future接口的对象,(FutureTask对象),由于FutureTask实现了Runnbale,我们也可以自己创建FutureTask,然后直接交给ExecutorService运行。最后主线程可以执行FutureTask.get()方法来等待任务执行完成,主线程也可以使用FutureTask.cancel来取消任务的执行。
3.核心类ThreadPoolExecutor详解
前面我们提到了ThreadPoolExecutor是框架中核心类,下面就展开详细的介绍。
1)构造函数
先从构造函数入手,下述源码是ThreadPoolExecutor一个常用的构造函数
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory) { this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, threadFactory, defaultHandler); }
上述参数解释如下:
除了上述参数以外,看上面常用的构造函数内部通过this调用其他构造器,其中还有一个参数defaultHandler,ThreadPoolExecutor还有一个参数RejectedExecutionHandler handler,当线程池无法执行新任务的时候(可能是因为任务队列已满或无法成功过执行任务),。这是ThreadPoolExecutor会调用handler的rejectedExecution方法来通知调用者,默认情况会直接抛出一个RejectedExecutionException。
2)ThreadPoolExecutor的执行规则
ThreadPoolExecutor执行任务时大致遵从下述规则:
1.如果线程池中的线程数量未达到核心线程的数量,那么直接启动一个核心线程
2.如果线程池中的线程数量已经达到或者超过核心线程的数量,那么任务会被插入到任务队列中排队等待执行。
3.如果在步骤2中无法将任务插入到任务队列中,这往往是因为任务队列已满,这是如果先吃数量未达到线程池规定的最大值,会立即启动一个非核心线程来执行任务。
4.如果步骤3中的线程数量已经达到线程池规定的最大值,那么就拒绝执行此任务,ThreadPoolExecutor会调用RejectedExecutionHandler的rejectedExecution方法来通知调用者。
3)线程池的分类
ThreadPoolExecutor通常都是通过工厂类Executors来创建,主要有以下三种ThreadPoolTExecutor;
1.FixedThreadPool
2.SingleThreadPool
3.CacheThreadPool
4.ScheduledThreadPool
接下来重点介绍各个线程池。
1.FixedThreadPool 可重用固定线程数的线程池
下面是它的源码实现
public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); }
其corePool和maximumPool值都被设置为创建FixedThreadPoolExecutor时指定的参数nThreads。keepAliveTime为0,即多余的空闲线程会被立即停止,任务队列采用LinkedBlockingQueue
1)如果当前运行的线程数少于corePoolSize,则创建新线程来执行任务
2)当当前线程数等于corePoolSize时,将任务加入到LinkedBlockingQueue中
3)线程执行完1中的任务后,会在循环中反复从LinkedBlockingQueue中获取任务来执行。
2.SingleThreadPoolExecutor
SingleThreadPoolExecutor是使用单个工作线程的Executor,下面是它的源码实现
public static ExecutorService newSingleThreadExecutor() { return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>())); }
可见其核心线程数和最大线程数都为1,任务队列同样采用的是LinkedBlockingQueue。从这个角度讲,当我们把刚才的FixedThreadPoolExecutor传入的nThreads为1 时,它就和SingleThreadPoolExecutor一致。
1)如果当前运行的线程数少于corePoolSize,即线程池中无运行线程,则创建新线程来执行任务
2)当当前线程数等于corePoolSize(1)时,将任务加入到LinkedBlockingQueue中
3)线程执行完1中的任务后,会在循环中反复从LinkedBlockingQueue中获取任务来执行。
3.CachedThreadPoolExecutor
CachedThreadPoolExecutor是一个根据需要创建新线程的线程池,照例贴源码:
public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>()); }
可以发现CachedThreadPoolExecutor它没有核心线程,而将maximumPoolSize的值设为Interger.MAX_VALUE,即为无界的。将keepAliveTime设置为60L,则意味着当CachedThreadPoolExecutor的空闲线程等待新任务的最长时间是60s,否则就会被终止。
CachedThreadPoolExecutor使用的是没有容量的SychronousQueue作为线程池的工作队列,但由于其最大线程数无界,这就意味着如果主线程提交任务的速度高于线程处理任务的速度,就会不断创建新线程,在极端情况下CachedThreadPool会因为创建过度线程耗尽CPU和内存资源。
CachedThreadPoolExecutor的execute过程和前面两个有点不同,具体如下
1)首先执行SynchronousQueue.offer,提交一个任务给工作队列,如果当前的maximumPool中有空闲线程正在执行SynchronousQueue.poll,那么即匹配成功,主线程将任务交给空闲线程执行,execute方法执行完成,否则执行步骤2
2)当初始maximumPool为空或者没有空闲线程时,将没有线程执行SynchronousQueue.poll,这样配对将失败,此时线程池会新建一个线程执行任务怒,execute方法执行完成。
3)当步骤2中创建的线程将任务执行完后,会执行SynchronousQueue.poll,这个poll操作会让空闲线程最多在SychronousQueue中等待60s,如果60s内主线程没有提供新任务,空闲线程将终止。
4.ScheduledThreadPoolExecutor
ScheduledThreadPoolExecutor继承自ThreadPoolExecutor,主要用于在给定延迟之后运行任务或者定期执行任务。这点上与Timer类似,但ScheduledThreadPoolExecutor功能更强大,更灵活,不同于Timer对应于单个后台线程,ScheduledThreadPoolExecutor可以在构造函数中指定多个对应的后台线程数。
private static final long DEFAULT_KEEPALIVE_MILLIS = 10L;
public ScheduledThreadPoolExecutor(int corePoolSize) { super(corePoolSize, Integer.MAX_VALUE, DEFAULT_KEEPALIVE_MILLIS, MILLISECONDS, new DelayedWorkQueue()); }
该线程池只需要指定核心线程数,其最大线程数无界,其超时时间为10ms,并且它使用的工作队列是DelayedWorkQueue,DelayedWorkQueue是一个无界队列,所以其最大线程数没有意义。
1) 当调用ScheduledThreadPoolExecutor的ScheduledThreadPoolExecutor的scheduleAtFixedRate()或scheduleWithFixedDelay()方法时,会从ScheduledThreadPoolExecutor的DelayQueue中添加一个实现了RunnbaleScheduledFuture接口的ScheduledFutureTask。
2)线程池中的线程从DelayQueue中获取ScheduledFutureTask,然后执行任务。
我们先来看一下ScheduledFutureTask的结构
private class ScheduledFutureTask<V> extends FutureTask<V> implements RunnableScheduledFuture<V> {
ScheduledFutureTask(Runnable r, V result, long triggerTime, long period, long sequenceNumber) { super(r, result); this.time = triggerTime; this.period = period; this.sequenceNumber = sequenceNumber; }
}
它继承自FutureTask,它主要包括三个成员变量。如下
time:表示任务将被执行的具体时间
sequenceNumber:表示任务被添加到ScheduledThreadPoolExecutor中的序号
period:表示任务执行的间隔周期
然后我们是将这个task提交到了DelayQueue中,DelayQueue封装了一个PriorityQueue,它会对队列中的ScheduledFutureTask进行排序。排序时,time小的在前面。如果time相同,则比较sequenceNumber,sequenceNumber小的排前面。
ScheduledThreadPoolExecutor的任务执行步骤
1.线程1从DelayQueue获取到期的任务(ScheduledFutureTask的time大于等于当前时间)
2.线程1 执行这个任务
3.线程1修改任务的time,变更为下次将被执行的时间
4.将修改后的任务放回到DelayQueue中。
上述获取任务和添加任务都是线程安全的(使用可重入锁 ReentrantLock)
六、AsyncTask
AsyncTask是在Executor框架基础上的再封装,它实现将耗时任务移动到工作线程中执行,同时提供了方便的接口实现工作线程和主线程之间的通信。使用AsyncTask一般都会用到如下方法:
import android.os.AsyncTask; public class FullTask extends AsyncTask<Params,Progress,Result>{ @Override protected void onPreExecute() { super.onPreExecute(); } @Override protected Result doInBackground(Params... params) { return null; } @Override protected void onProgressUpdate(Progress... values) { super.onProgressUpdate(values); } @Override protected void onPostExecute(Result result) { super.onPostExecute(result); } @Override protected void onCancelled() { super.onCancelled(); } }
下面给出一个具体的例子直观地展示它的基本用法。
import android.os.AsyncTask; import java.net.URL; public class DownloadFilesTask extends AsyncTask<URL,Integer,Long>{ @Override protected Long doInBackground(URL... urls) { int count = urls.length; long totalSize =0; for(int i=0;i<count;i++){ totalSize += DownLoader.downloadFile(urls[i]); publishProgress((int)((i/(float)count)*100)); if(isCancelled()){ break; } } return totalSize; } @Override protected void onProgressUpdate(Integer... progress) { setProgressPercent(progress[0]); } @Override protected void onPostExecute(Long result) { showDialog("Downloader" + result+" bytes"); } }
上述程序模拟了一个文件下载过程,当要执行上述下载任务时,可以通过如下方式来完成:
new DownloadFileTask().execute(url1,url2,url3);
在上述程序中,doInBackground用来执行具体的下载任务并通过publishProgress方法来更新下载进度,同时还要判断下载任务是否被外界取消了。当下载任务完成时,它返回结果,即下载的总字节数。这里需要注意的是doInBackground是在线程池中执行。
而onProgressUpdate用于更新界面中下载的进度。运行在主线程中,当publishProgress方法被调用的时候,它就会被调用。当下载任务完成后,onPostExecute方法会被调用,它也是运行在主线程中。这个时候我们可以给出一些相应的提示,提醒用户下载完成。
综上所述,onPreExecute()用于开始后台任务前的UI准备。onProgressUpdate用于任务进行时的UI操作,onPostExecute用于任务完成后的UI操作。而doInBackground则用于后台任务的执行。
注意点:
1.AsyncTask的类必须在主线程中加载。
2.AsyncTask的对象必须在主线程中创建。
3.execute方法必须在UI线程中调用
4.不要在程序直接调用onPreExecute()、onProgressUpdate()、onPostExecute()和doInbackground()
5.AsyncTask对象只能执行一次,即只能调用一次execute方法
6.在android3.0开始,execute()方法采用一个线程串行执行任务,而executeOnExecutor()方法可以并行执行任务。
下面结合源码,我们简单了解一下AsyncTask的原理。
我们首先看它的构造函数:
public AsyncTask() { mWorker = new WorkerRunnable<Params, Result>() { public Result call() throws Exception { mTaskInvoked.set(true); Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); //noinspection unchecked Result result = doInBackground(mParams); Binder.flushPendingCommands(); return postResult(result); } }; mFuture = new FutureTask<Result>(mWorker) { @Override protected void done() { try { postResultIfNotInvoked(get()); } catch (InterruptedException e) { android.util.Log.w(LOG_TAG, e); } catch (ExecutionException e) { throw new RuntimeException("An error occurred while executing doInBackground()", e.getCause()); } catch (CancellationException e) { postResultIfNotInvoked(null); } } }; }
这个构造函数将我们传入的Params和Result先封装成了一个WorkerRunnable,再将其传入FutureTask中。这边它返回的是postResult方法,查看这个方法
private Result postResult(Result result) { @SuppressWarnings("unchecked") Message message = getHandler().obtainMessage(MESSAGE_POST_RESULT, new AsyncTaskResult<Result>(this, result)); message.sendToTarget(); return result; }
在这个方法里似乎调用了Handler,并发送了message。点开getHandler方法,最后追踪到InternalHandler类,正是它实现了执行环境从线程池到主线程的切换。,它的逻辑很常见,这边就不解释了。
private static class InternalHandler extends Handler {
public InternalHandler() {
super(Looper.getMainLooper());
}
@SuppressWarnings({"unchecked", "RawUseOfParameterizedType"})
@Override
public void handleMessage(Message msg) {
AsyncTaskResult<?> result = (AsyncTaskResult<?>) msg.obj; switch (msg.what) { case MESSAGE_POST_RESULT: // There is only one result result.mTask.finish(result.mData[0]); break; case MESSAGE_POST_PROGRESS: result.mTask.onProgressUpdate(result.mData); break; } } }
获取这个Handler对象,这边有一个简单的同步。
private static Handler getHandler() {
synchronized (AsyncTask.class) {
if (sHandler == null) {
sHandler = new InternalHandler();
}
return sHandler;
}
}
前面我们通过构造函数了解了AsyncTask如何将Params和Result进行封装,如何利用Handler将执行环境从线程池切换到主线程中。接下来我们来具体看一下AsyncTask的调用过程。我们从execute()方法入手
可以看到这边注解了execute方法必须在主线程上调用,并且这个方法接着调用了executeOnExecutor方法,传入了sDefalutExecutor,这边我们首先得知道这个参数是什么,找到这个参数。
private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR;
这个sDefalutExecutor是什么呢?查找SERIAL_EXECUTOR的初始化地方,我们看到了
public static final Executor SERIAL_EXECUTOR = new SerialExecutor(); 下面我们就可以查看这个SerialExecutor线程池内部类。
public static final Executor SERIAL_EXECUTOR = new SerialExecutor(); private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR; private static class SerialExecutor implements Executor { final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>(); Runnable mActive; public synchronized void execute(final Runnable r) { mTasks.offer(new Runnable() { public void run() { try { r.run(); } finally { scheduleNext(); } } }); if (mActive == null) { scheduleNext(); } } protected synchronized void scheduleNext() { if ((mActive = mTasks.poll()) != null) { THREAD_POOL_EXECUTOR.execute(mActive); } } }
从SerialExecutor的实现可以分析AsyncTask的串行执行的过程。首先系统会把AsyncTask的Params参数封装为FutureTask对象,这个FutrueTask对象就被充当为Runnable叫给SerialExecutor的execute方法去处理。这个方法首先会把FutureTask对象插入到任务队列mTasks中,并对其进行一定程度的封装,在后面增加了scheduleNext()方法。注意这个时候它并没有进行任务的执行(可见SerialExecutor线程池并不是用来执行任务的,而是用来任务的排队的)如果这个时候没有处理活动状态的AsyncTask任务,会调用scheduleNext()方法,来执行下一个任务。
这边我们又看到一个线程池,THREAD_POOL_EXECUTOR,这个线程池才是真正用来执行任务的。
static { ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor( CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE_SECONDS, TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory); threadPoolExecutor.allowCoreThreadTimeOut(true); THREAD_POOL_EXECUTOR = threadPoolExecutor; }
接着我们回到executeOnExecutor,
@MainThread public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec, Params... params) { if (mStatus != Status.PENDING) { switch (mStatus) { case RUNNING: throw new IllegalStateException("Cannot execute task:" + " the task is already running."); case FINISHED: throw new IllegalStateException("Cannot execute task:" + " the task has already been executed " + "(a task can be executed only once)"); } } mStatus = Status.RUNNING; onPreExecute(); mWorker.mParams = params; exec.execute(mFuture); return this; }
不难发现上面进行了两个异常抛出,这就是我们先前提到的在execute方法只能执行一次。在executeOnExecutor方法中onPreExecute()方法最早被执行,而后再调用execute进入到我们先去讲到的SerialExecutor线程池进行任务的排队,最后进入任务执行的线程池进行任务的执行。
至此,大部分结构就算理清了。
七、总结
Android平台提供了上述诸多异步处理技术,我们在进行选择的时候需要根据就提的需要而定。
主要的参考点:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。