在这一系列教程的最后一篇中，我想谈谈GR的EventBus，在处理多线程异步任务时是多么简单而有效。
AsyncTask, Loader和Executor…… 拜托！
Android中有很多种执行异步操作的方法（指平行于UI线程的）。AsyncTask对于用户来说是最简单的一种机制，并且只需要少量的设置代码即可。然而，它的使用是有局限的，正如Android官方文档中所描述的：
AsyncTask被设计成为一个工具类，在它内部包含了Thread和Handler，但它本身并不是通用线程框架的一部分。AsyncTask应该尽可能地被用在执行一些较短的操作中（最多几秒）。如果你需要在线程中执行较长时间的任务，那么建议你直接使用java.util.concurrent包中提供的各种API，如Executor、 ThreadPoolExecutor以及FutureTask。
不过即便是执行短时间的操作也会带来一些问题，特别是在与Activity/Fragment生命周期有关的地方。由于AsyncTask会持续地运行下去（即使启动它们的Activity/Fragment已经被销毁了）。这样，一旦你在onPostExecute方法中试图对UI进行更新，那么最终将导致抛出一个IllegalStateException异常。
Android 3.0中引入了Loader API用来解决Activity/Fragment生命周期的问题（它们的确很有效）。Loader API被设计成向Activity/Fragment中以异步方式加载数据。尽管加载数据是一种非常常见的异步操作，但并非唯一一种需要从UI线程中分开的操作。Loader还需要在Activity/Fragment中实现另外一个监听接口。尽管这么做没有错，但我个人并不喜欢这种模式（我的意思是最终你的代码中会包含许多的回调函数，导致代码的可读性变得很差）。最后，Activity和Fragment也并非唯一需要对异步操作分线程的地方。例如如果在Service里，你就不能访问LoaderManager，所以最终你还是得使用AsyncTask或者java.util.concurrent。
java.util.concurrent包很不错，我在Android和非Android项目中都可以使用。不过使用时需要对其进行多一点儿配置和管理，不象AsyncTask那么简单。你需要对ExecutorService进行初始化，管理和监视它的生命周期，并且可能需要跟一些Future对象打交道。
只要使用恰当，AsyncTask、 Loader和Executor都是非常有效的。但在复杂应用中，需要为每个任务选择合适的工具，最终你可能三种都会用到。这样你就得维护三种不同的处理并发的框架代码。
Green Robot来帮忙了！
GR的EventBus中内置了一个非常棒的并发处理机制。在监听类中，你可以实现4种不同类型的处理方法。当一个匹配事件被发送过来时，EventBus会根据不同的并发模型将事件发送到相应的处理方法中：
- onEvent(T event)：运行在和被发送事件相同的线程中。
- onEventMainThread(T event)：运行在主（UI）线程中，不管事件从哪个线程中被发送过来。
- onEventAsync(T event)：运行在单独的线程中，即非UI线程，也非发送事件的线程。
- onEventBackgroundThread(T event)：如果发送事件的线程不是UI线程，则运行在该线程中。如果发送事件的是UI线程，则它运行在由EventBus维护的一个单独的线程中。多个事件会同步地被这个单独的后台线程所处理。
这些方法功能强大而且使用简单。例如有一个比较耗时的操作（可能是网络调用，大量数据处理等），这一操作需要由UI上的行为来触发，并且当操作执行完毕后还需对UI进行更新。在这个例子中，UI行为即按钮点击，按钮在activity中，耗时操作在service中。我们可以按下面的方式来实现：
Java
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
SomeActivity.java: ... @Inject EventBus bus; ... @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); ... button.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { eventBus.post(new DoOperationEvent()); } }); } @Override protected void onResume() { super.onResume(); bus.register(this); } @Override protected void onPause() { bus.unregister(this); super.onPause(); } public void onEventMainThread(OperationCompleteEvent event) { Toast.makeText(this, "Operation complete!", Toast.LENGTH_SHORT).show(); } ... SomeService.java: ... @Inject EventBus bus; ... @Override protected void onCreate() { super.onCreate(); bus.register(this); } @Override protected void onDestroy() { bus.unregister(this); super.onDestroy(); } public void onEventAsync(DoOperationEvent event){ // DO SOMETHING LONG-RUNNING HERE eventBus.post(new OperationCompleteEvent()); } ... |
尽管这个例子比较简单，但它却非常简明扼要地说明了问题。这里即不需要实现监听接口，也不会出现类似生命周期之类的问题（由于activity只能在它存在的时候才能接收到OperationCompleteEvent事件）。除此之外，如果发生了配置改变（旋转屏幕）或其他什么原因导致activity在两次事件发生之间被销毁并重建，最终仍可以接收到OperationCompleteEvent事件。
此外，我们也可以容易地想到一些其它用法。比如，如果需要将更新进度发出去，你只需另外实现一个封装了进度值的事件类，然后将其发送出去即可。或者，如果你想让其它一些事件（不管是相同还是不同类型）不被并行处理（同步执行），你可以选择使用onEventBackgroundThread。
依赖Bus
实例化EventBus最简单的方法就是通过EventBus.getDefault()。然而，在EventBusBuilder类（通过EventBus.builder()获得）中还包含了另外一些有用的配置方法。特别是在本文中提到过的使用你自己的ExecutorService。缺省情况下EventBus通过Executors.newCachedThreadPool()创建自己的ExecutorService，在大多数情况下都已满足你的需要。然而，有时你可能仍然想要显示地控制EventBus所使用的线程数量，这种情况下你就可以象下面这样初始化EventBus：
Java
|
1 |
EventBus.builder().executorService(Executors.newFixedTheadPool(NUM_THREADS)).installDefaultEventBus(); |
在EventBusBuilder中另外一些可供配置的是一些和异常处理的有关的控制，以及一个是否允许事件类被继承的控制开关。这些内容超出了本文所讨论的范围，但我还是建议你仔细去研究一番。GR可能并没有把这些内容都写在文档里，但如果你读一读EventBusBuilder和EventBus的源代码，相信你会很容易理解它们的。
全能程序员交流QQ群290551701，聚集很多互联网精英,技术总监,架构师,项目经理!开源技术研究,欢迎业内人士,大牛及新手有志于从事IT行业人员进入!