在android开发中,有两条很重要的编程准则

  • 不要堵塞ui线程
  • 不要在非ui线程操作ui控件

开发者必须这两个遵守单线程模型的准则,将耗时的逻辑转移到非ui线程进行,得出计算结果后,通知ui线程进行数据的展现。本文介绍一下android的异步编程。

android线程模型

同hotspot vm一样,在daivlk vm中,采取的是1:1线程模型,每一个android thread对应一个Native Linux thread;linux内核通过cfs(completely fair scheduler)来进行线程调度,在cfs中着影响一个线程时间分配的因素有两个:

  • thread priority
  • thread group

thread group

线程的thread group是动态改变的,在android framework层面,android的应用有5个等级,分别是

  • foreground process
  • visible process
  • service process
  • backgroud process
  • empty process

它们的thread group如图,
Alt pic

在实际的分配中,系统会将90%的cpu时间分配给foregroud thread group, 如果某个应用处于foreground或visible level,那么它创建的所有thread都属于foreground group。 当应用的可见状态被改变时,例如按home健被切入到后台运用,应用从foregroud process变成了backgroud process,应用对应的的thread group也切换到了backgroud group

thread priority

线程的优先级通过Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)设置;

线程分类

在一个android应用中,存在三种类型的线程:

  • UIThread,即工作主线程
  • Binder Thread:与其他进程进行binder通信的线程,通过一个线程池进行维护; 每个进程维护了一个线程池用于与其他进程的通信,binder thread隐藏在后台,开发者一般不需要关心;

  • backgroud thread,即后台线程;

注意每一个后台线程都是UIThread的子线程,意味着他的线程优先级和ui thread是完全相同的,同时由于他们处在同一个thread group中,那么linux内核对ui线程和后台线程一视同仁;

dalvik有一个最大线程个数的限制,但不意味着应用可以随意生成低于这个限制值的线程个数;由于linux内核平等的对待ui线程和后台线程,一旦滥用后台,当ui线程不能抢占到足够的cpu时间片时,也抛出anr异常;另一方面,由于thread是gc mark的root,过多的线程也会对gc造成影响。

Thread&&Executor

Thread和Executor都是jdk原生的异步机制,不再赘述。在使用时,原生的Thread的存在两个缺陷:

  • 不可复用,线程的创建、销毁都需要时间开销以及空间开销
  • 无原生的cancel机制,你需要额外的工作去管理的thread生命周期

而Executor线程池,解决Thread不可复用,减少thread的重复创建。

HandlerThread

HandlerThread是Thread的子类,内部封装了Message/Looper,Message/Looper是一个顺序执行的队列,开发者可以利用这一特性进行异步逻辑之间的组合及交互,因此非常适合做一个状态机:最典型的例子即条码处理库zxing,摄像头扫描过程中每一个状态都通过Message同步给了ui线程;同样使用HandlerThread,另一个使用度非常高的android-async-http则是一个典型的反例,async-http是一个异步网络库,它以callback作为数据协同的方式,导致的结果是代码充斥了不可读的callback嵌套callback。

适用场景
  • 需要一个长期运行的thread
  • 顺序执行的消息loop
    • 避免多个按钮同时点击
    • 状态机
    • 细粒度的消息控制

AsyncTask

AsyncTask是android中最常用的并发机制,api非常简洁,开发者只需简单的继承AsyncTask即可完成异步逻辑以及数据协同, 数据的协同,内部通过Handler/Message进行,异步逻辑doInBackground则利用Executor完成。 必须要了解是,AysncTask是一个全局行为,在不同的组件中创建Asynctask,最终的执行都会在同一个Executor中:

Alt pic

作为最常用的异步编程解决方案,AsyncTask也是被批评最多的异步机制,原因是其在不同android版本中的不同表现, 在1.6版本之前,AsyncTask的Executor是一个单线程,所有AsyncTaskd都是顺序执行; 在1.6到3.0版本中,Executor维护了一个最多线程池并发执行 android版本发展到3.0后,默认的线程修改成了单线程task,同时提供了一个executeOneExecutor api支持多个并行task, 但这不表示的在3.x版本之后,你的task是默认一定是顺序执行的,它还受taregetSdkVersion的影响,AcitivityThread.java中有这样一段代码

// If the app is Honeycomb MR1 or earlier, switch its AsyncTask
// implementation to use the pool executor.  Normally, we use the
// serialized executor as the default. This has to happen in the
// main thread so the main looper is set right.
if (data.appInfo.targetSdkVersion <= android.os.Build.VERSION_CODES.HONEYCOMB_MR1) {
     AsyncTask.setDefaultExecutor(AsyncTask.THREAD_POOL_EXECUTOR);
}

如果targetSDKVersion低于3.2版本,AsyncTask是并行执行的,否则将会被顺序执行,考虑不同版本的表现,在使用AsyncTask时需要规避task之间有依赖执行顺序的逻辑;

另一个经常被批评的点是AsyncTask的全局行为,在组件中使用Asynctask时,经常会将他定义在一个匿名的内部类,这时候一个潜在的内存泄漏就产生了,由于Asynctask的生命周期可能比它关联的组件对象长,导致其关联的组件无法被回收,幸运的是,asynctask提供了cancel机制。在组件生命周期结束后及时调用cancel api,在asynctask未被执行时,可以将asynctask从队列去除;cancel api有一个mayInterruptIfRunning参数:cancel(true) == cancel(false)+interrpt

IntentService

IntentService为Service的子类,其内部实现包含了一个HandlerThread,它兼具了service/message looper/hanlder的优势,android官方文档将其列为后台任务的最佳实践(http://developer.android.com/training/best-background.html)

不同与Service,当一个intent被提交,系统会将intent提交到HandlerThread中顺序执行,而非在ui线程执行; IntentService中工作队列不能被打断,必须等待所有的intent被处理完成之后,intentservcie自动关闭;官方建议通过broadcast机制来进行协同,避免产生耦合;

Loader/AsyncQueryHandler

将Loader和AsyncQueryHandler放在一起,主要是因为他们api适合做为数据加载的接口 区别在与Loader内部利用AsyncTask,AsyncQueryHandler使用ThreadHandler Loader机制在api 11中引入,通过support包的方式支持已有版本,两者都支持:

  • 后台加载数据
  • 数据改变时候的回调
  • 生命周期自动管理

延伸阅读

一些现有的解决方案

  • rxandroid:函数式响应框架,rxjava的android版本,主要贡献者是JakeWharton大神,提供了异步逻辑的组合、过滤,不过目前暂不适合在生产环境使用,建议关注

  • android anotation:如名,基于java注解,提供了一个简化的线程模型,提供编程效率

  • EventBus:基于生产/消费者模型的优雅实现

Comments