（三）改進篇：AsyncTask加強版

摘要： 一、前言 前文連結：深入解讀AsyncTask 上一篇文章我們介紹了AsyncTask的相關知識點，並就其存在的問題做了深入的探討。 AsyncTask總的來說實現簡單，構思精巧，還是有不少地方值得借鑑的； 但因其保守的設計，在通用性方面有較大侷限。 不過，有侷限，才有...

一、前言

前文連結：深入解讀AsyncTask

上一篇文章我們介紹了AsyncTask的相關知識點，並就其存在的問題做了深入的探討。

AsyncTask總的來說實現簡單，構思精巧，還是有不少地方值得借鑑的；

但因其保守的設計，在通用性方面有較大侷限。

不過，有侷限，才有突破。

接下來，我們將結合APP開發中的使用場景，探討如何設計一個更強的非同步任務框架。

二、任務排程

前文提到，AsyncTask主要做了兩項工作：流程控制和任務排程。

其中任務排程方面主要依賴於兩個Executor：ThreadPoolExecutor 和 SerialExecutor 。

對於ThreadPoolExecutor而言，如果workQueue是容量較大的的佇列，則基本上coreSize就是併發視窗（可以併發執行的執行緒數量）。

coreSize太小，CPU利用率不高，吞吐率低，不適用於IO密集型任務（比如網路請求）；

coreSize太大，如果執行的是計算密集型任務，執行緒切換頻繁，CPU計算飽和（影響UI執行緒運算）。

所以，我們先從任務排程入手，解決“利用率/吞吐率”兩難的問題。

同時探索一下在任務排程方面，還有什麼可以完善的。

2.1 併發控制

如果做到既支援CPU的高利用率，又支援任務的高吞吐率呢？

用兩個執行緒池嗎？

倒是可以，但兩個執行緒池會各自維護執行緒，彼此不能複用。

說到複用，AsyncTask給我們提供了一種思路：

先定義一個執行緒池 THREAD_POOL_EXECUTOR ，並行任務可以呼叫此Executor來執行；

封裝SerialExecutor，加了一個任務佇列，控制加入的任務序列執行，但是最終任務還是執行在 THREAD_POOL_EXECUTOR 上。

於是，呼叫者可以選擇序列或者並行，且是在同一個執行緒池中排程的，執行緒可以複用。

就此思路，我們可以仿照SerialExecutor，線上程池ThreadPoolExecutor之上，封裝一個Executor來控制併發，同時建立不同併發視窗的Executor。

簡單地說，就是給水池接不同的水管，不同的水管口徑可以不一樣。

在造管道之前，我們先準備一些其他工具。

前面的SerialExecutor的程式碼中，有兩個重要的構成部分：

1、Runnable的包裝器（雖然是匿名的）；

2、下一個任務的觸發器（雖然只是個方法）。

我們把這兩部分都抽象出來：

interface Trigger {
fun next()
}

class RunnableWrapper constructor(
private val r: Runnable,
private val trigger: Trigger) : Runnable {
override fun run() {
try {
r.run()
} finally {
trigger.next()
}
}
}

讀者可能會有疑問：抽個RunnableWrapper 也就算了，一個方法也要抽出來？要不要這麼形式化啊？

Take it easy, 下一節我們會看到，抽出來是有原因的。

現在我們先看下如何建造這條“管道”，既然比作“管道”，且命名為PipeExecutor吧。

class PipeExecutor @JvmOverloads constructor(
windowSize: Int,
private val capacity: Int = -1,
private val rejectedHandler: RejectedExecutionHandler = defaultHandler) : TaskExecutor {

private val tasks = PriorityQueue<RunnableWrapper>()
private val windowSize: Int = if (windowSize > 0) windowSize else 1
private var count = 0

private val trigger : Trigger = object : Trigger {
override fun next() {
scheduleNext()
}
}

override fun execute(r: Runnable) {
schedule(RunnableWrapper(r, trigger), Priority.NORMAL)
}

fun execute(r: Runnable, priority: Int) {
schedule(RunnableWrapper(r, trigger), priority)
}

@Synchronized
internal fun scheduleNext() {
count--
if (count < windowSize) {
startTask(tasks.poll())
}
}

@Synchronized
internal fun schedule(r: RunnableWrapper, priority: Int) {
if (capacity > 0 && tasks.size() >= capacity) {
rejectedHandler.rejectedExecution(r, TaskCenter.poolExecutor)
}
if (count < windowSize || priority == Priority.IMMEDIATE) {
startTask(r)
} else {
tasks.offer(r, priority)
}
}

private fun startTask(active: Runnable?) {
if (active != null) {
count++
// poolExecutor 是 ThreadPoolExecutor
TaskCenter.poolExecutor.execute(active)
}
}
}

解析一下程式碼中的引數和變數：

• tasks ：任務緩衝區
• count ：正在執行的任務的數量
• windowSize ：併發視窗，控制Executor的併發
• capacity ：任務緩衝區容量，小於等於0時為不限容量，超過容量觸發rejectedHandler
• rejectedHandler ：預設為AbortPolicy(丟擲異常）
• priority ：排程優先順序

object Priority {
const val IMMEDIATE = Integer.MAX_VALUE
const val HIGH = 1
const val NORMAL = 0
const val LOW = -1
}

當count>=windowSize時，priority高者先被排程；

優先順序相同的任務，遵循先進先出（FIFO）的排程規則；

priority=IMMEDIATE會跳過緩衝區直接進入執行緒池。

需要注意的是，排程優先順序不同於執行緒優先順序，執行緒優先順序更底層一些。

比如AsyncTask的doInBackground()中就呼叫了：

Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)

這可以使得後臺執行緒的執行緒優先順序低於UI執行緒。

以下是PipeExecutor的流程圖：

使用時，可以例項化多個PipeExecutor，他們各自根據引數排程自己的任務佇列，而所有任務最終都是在同一個執行緒池中執行。

比方說可以建立windowSize小一點的PipeExecutor，用於計算密集型任務；

也可以建立windowSize大一點的PipeExecutor，用於IO密集型任務；

還可以使windowSize=1，用於序列執行。

事實上，如果poolExecutor的配置像這樣的話：

new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());

PipeExecutor可以實現SingleThreadPool、FixedThreadPool 和 CachedThreadPool 一樣的功能；

而且所有PipeExecutor的例項可以複用執行緒池的執行緒。

最後，有一個疑問：

如果一個水管的流速剛好能處理的話，兩個水管同時進水豈不是滿得更快？

事實上，終端的任務通常是分散的，比方說觸發某個事件（比如開啟頁面），然後做一波任務。

所以兩個水管同時滿負載的情況應該是比較少的。

有一個場景可能會有大量任務：APP啟動的時候。

此時可以根據任務的輕重緩急合理安排，能序列的序列，能推遲的推遲，儘量避免“洪峰”。

2.2 任務去重

這一節可能相對難理解一點，不過我會想辦法儘量表述清楚一些的。

“任務去重”估計讀者沒(怎麼)聽過，就當是筆者提的一個新概念吧，如有雷同，純屬巧合。

要說去重，首先要定義重複：

做任務其實就是做計算，其模式可以表示為 R=f (X) ；

如果任務A和任務B都是計算 R=f (X) ， 且 X 相等，那麼我們說A和B是“重複任務”。

兩個任務的計算是等價的，我們可以通過“去重”來節約運算。

什麼時候會出現“重複任務”呢？

舉兩個例子：

一、資料更新，重新整理頁面

假設一個頁面的資料項(R)有多個數據源(X=[x1,x2…xn]), 即R=f(x1,x2…xn);

任何一個數據源更新， R都要重新計算。

通常“資料更新->計算資料->重新整理介面” 會採用“釋出訂閱模式”：

資料來源更新發送事件，接收到事件，啟動任務計算R。

假如x1,x2…xn短時間內相繼更新了資料，傳送了事件e1,e2...en，然後會幾乎同時啟動N個任務計算R。

• 如果任務並行，N個執行緒併發計算R=f(x1,x2…xn)，浪費計算資源，更不用說多執行緒問題的複雜性了；
  所以這樣的任務最好不要併發執行。
• 如果任務序列，若R的計算比價耗時，第一個任務還沒計算完，又來了n-1個任務。
  其實所有的任務都是計算R=f(x1,x2…xn)，對於後面的n-1個任務而言，是等價的。
  因為在第一個任務還在計算的時候，x1,x2…xn都更新完了，沒有再更新了，
  所以對於後面的任務X是一樣的，當然 R=f(X) 也是一樣的了，這就是“重複任務”。
  當然，對應的方法就是： 對於後面的任務，只保留一個就好了 。

除了這個方案，我們來看下其他方案：

1. 丟棄後面所有的任務。
   如果第一個任務在讀取資料X之後x2...xn才更新，那第一個任務的(x1,x2…xn)和後面的任務就不一樣；
   如果直接丟棄後面的任務，很顯然，R得不到正確更新。
2. 取消之前的任務，直接計算後面的任務。
   首先，即使任務可以取消（馬上停止），x2取消第一個任務，x3取消第二個任務……則介面遲遲得不到更新。
   最重要的是，任務不是說取消就取消的。
   上一篇有討論，Thread.stop()不安全， interrupt()只能中斷wait(), sleep()等，對計算型任務是中斷不了的。
3. 過濾事件, 接收到了其中一個事件, 則一定時間內對e1,e2...en都不響應。
   這個可操作性更差，而且結果和丟棄後面所有的任務一樣，R得不到正確更新。

其實不僅有多個數據的情況需要去重，即使是單個數據源，也是一樣的，只是舉例多個數據源能更好地體現。

二、圖片載入

這個例子比上一個簡單很多：多個ImageView需要載入同一張圖片。

這其實也出現了“重複任務”，因為是同一張圖片，所以 R=f(X) 等價。

和那個例子不同的是，這裡有多個目標(Target)。

如果說前面的例子是 R->T 的話，這裡則是 {R->T1, R->T2 ... R->Tn} 。

去重策略有所相同，也有所不同。

相同之處是：序列；

不同之處是：不能丟棄任務（不然有的ImageView得不到更新）。

• 序列的話不會慢嗎？
  不會，因為圖片載入通常都有快取策略，第一個任務解碼圖片之後，放入快取，後面的任務讀取快取即可。
• 如果是不同的圖片呢？
  嗯，關鍵就在這： 相同的任務序列，不同的任務並行 。
• 怎麼看任務是不是“相同的任務”？
  這就是需要給任務一個“標籤(tag)”, tag相同則為相同的任務。
  比方說下載任務的話可以將url作為tag。

任務去重的實現如下：

class LaneExecutor(private val executor: PipeExecutor,
private val discard: Boolean = false) : TaskExecutor {
// 正在排程的任務
private val scheduledTasks = HashMap<String, Runnable>()
// 丟棄模式下等待的任務
private val waitingTasks by lazy { HashMap<String, TaskWrapper>() }
// 非丟棄模式下等待的任務
private val waitingQueues by lazy { HashMap<String, CircularQueue<TaskWrapper>>() }

private class TaskWrapper(val r: Runnable, val priority: Int)

private inner class LaneTrigger(val tag : String) : Trigger{
override fun next() {
executor.scheduleNext()
scheduleNext(tag)
}
}

private fun start(r: Runnable, tag: String, priority: Int) {
scheduledTasks[tag] = r
executor.schedule(RunnableWrapper(r, LaneTrigger(tag)), priority)
}

@Synchronized
fun scheduleNext(tag: String) {
scheduledTasks.remove(tag)
if (discard) {
waitingTasks.remove(tag)?.let { start(it.r, tag, it.priority) }
} else {
waitingQueues[tag]?.let { queue ->
val wrapper = queue.poll()
if (wrapper == null) {
// 如果佇列清空了，則順便把佇列從HashMap移除，不然HashMap只增不減
waitingQueues.remove(tag)
} else {
start(wrapper.r, tag, wrapper.priority)
}
}
}
}

@Synchronized
fun execute(tag: String, r: Runnable, priority: Int = Priority.NORMAL) {
if (tag.isEmpty()) {
executor.execute(r, priority)
} else if (!scheduledTasks.containsKey(tag)) {
start(r, tag, priority)
} else if (discard) {
if (waitingTasks.containsKey(tag)) {
// 丟棄模式下，如果有相同的任務在等待，則丟棄傳進來的任務
// 而如果傳進來的又是 Futures(實現了Runnable), 則順便呼叫其cancel()方法
if (r is Future<*>) {
r.cancel(false)
}
} else {
waitingTasks[tag] = TaskWrapper(r, priority)
}
} else {
// 非丟棄模式下，每個tag都有一個無界佇列可以快取任務
val queue = waitingQueues[tag]
?: CircularQueue<TaskWrapper>().apply { waitingQueues[tag] = this }
queue.offer(TaskWrapper(r, priority))
}
}
}

建構函式有兩個引數：

executor：PipeExecutor的例項。

discard：當discard=true時，只留一個等待的任務; 否則, 不丟棄任務 。

LaneExecutor的實現和PipeExecutor有些相似的，兩者都有緩衝任務的容器，而執行流程上，

大體都是走了 “execute -> start -> 轉發給另一個Executor -> 執行結束 -> scheduleNext ” 這樣一個流程。

區別在於，LaneExecutor由於要“標識任務”，所以有一個 tag 引數貫穿整個流程，連容器都是以tag為key的HashMap。

還有就是， LaneTrigger 實現了 Trigger , 把tag封裝到類中, 因為這裡的next需要用到tag。

如果沒有封裝Trigger，就需要tag傳給RunnableWrapper，這樣就汙染RunnableWrapper了。

RunnableWrapper同時也被PipeExecutor依賴，而PipeExecutor又不需要tag。

因此，雖然只有一個方法，也封裝到介面中。

關於組合和繼承，普遍的觀點是組合優先於繼承。

所以在設計LaneExecutor時，用PipeExecutor作為成員而非繼承於PipeExecutor。

LaneExecutor自己實現任務去重，然後將任務轉發給PipeExecutor。

他們的關係示意圖如下( 分兩種模式，分別對應前面提到的兩種場景）：

洋蔥似地一層包一層，顯然也是裝飾者模式。

這樣的實現估計大家在用各種 InputStream 和 OutputStream 時已經領略了。

總體上看，

LaneExecutor負責任務去重；

PipeExecutor負責任務併發控制和排程優先順序；

ThreadPoolExecutor負責分配執行緒來執行任務。

還有就是，為什麼命名為LaneExecutor呢？

Lane有車道的意思（泳道也是這個詞），看示意圖，是不是有點像車道？

總結一下LaneExecutor的特點：

• 相同的任務序列，不同的任務並行
• discard=true, 序列的任務，各自(按tag分組）最多隻能有一個任務等待，再有提交會被丟棄；
• discard=false, 每個tag分組都有一個無界佇列緩衝，不會丟棄任務。

從另一個角度看，這種discard=false的模式，

給同類的任務加tag，就可以使得同類任務“序列執行”，相當於 PipeExecutor(1)。

2.3 統一定義Executor

當專案複雜度到了一定程度，如果沒有明確的公共定義，可能會出現各種冗餘物件，比如快取和Executor。

分散的Executor無法較好地控制併發；

如果各自建立的是ThreadPoolExecutor，則還要加上一條：降低執行緒複用。

故此，可以集中定義Executor，各模組統一呼叫。

程式碼如下：

object TaskCenter {
private val cpuCount = Runtime.getRuntime().availableProcessors()
// ... 定義threadFactory， 程式碼省略

internal val poolExecutor: ThreadPoolExecutor = ThreadPoolExecutor(
0, 256,
60L, TimeUnit.SECONDS,
SynchronousQueue(),
threadFactory)

// 常規的任務排程器，可控制任務併發，支援任務優先順序
val io = PipeExecutor(20, 512)
val computation = PipeExecutor(Math.min(Math.max(2, cpuCount), 4), 512)

// 帶去重策略的 Executor，可用於資料重新整理等任務
val laneIO = LaneExecutor(io, true)
val laneCP = LaneExecutor(computation, true)

// 相同的tag的任務會被序列執行，相當於序列的Executor
// 可用於寫日誌，上報app資訊等任務
val serial = LaneExecutor(PipeExecutor(Math.min(Math.max(2, cpuCount), 4), 1024))
}

以上設定主要參考AsyncTask的執行緒池引數，以及阿里開發手冊“併發處理”的一些說明：

簡單地說就是不允許maximumPoolSize=Integer.MAX_VALUE，也不允許佇列容量為Integer.MAX_VALUE。

所以TaskCenter的poolExecutor的maximumPoolSize設定為256，PipeExecutor的任務緩衝容量也設定了有限的值。

• TaskCenter中的PipeExecutor的windowSize都不大，
  所以如果不在TaskCenter外建立windowSize太大的Executor，用Priority.IMMEDIATE的情況也比較少的話，不會導致執行緒過多。
• 任務緩衝容量capacity=512通常情況下也足夠了，但是執行中真的出了意外，比如某個迴圈建立了超量的任務，
  則會執行RejectedExecutionHandler，而預設defaultHandler是AbortPolicy，也就是丟擲RejectedExecutionException。
  事實上如果真的在執行中發生了意料之外的情況，確實應該拋RuntimeException（RejectedExecutionException就是其中一種）。
  如果預見到有可能會建立很多工，可以在TaskCenter之外自定義capacity大一點的PipeExecutor。

poolExecutor的佇列用的是SynchronousQueue，SynchronousQueue是阻塞佇列，其特點是:

如果沒有執行緒在等著取(poll/take)佇列的元素, 則offer返回false(裝不進）；

如果有執行緒在等，則可以放進去，而一放進去就會被執行緒取走。

• 執行緒池中用SynchronousQueue，效果為任務放入即被執行，這樣的話相當於不控制任務併發了；
  所以我們用PipeExecutor來控制併發，poolExecutor負責只用負責維護執行緒就好了。
• poolExecutor不需要控制併發的話，coreSize也設定為0就好了，
  這樣的話，一段時間（60s）沒有任務執行，執行緒可以銷燬。
  為什麼不留一些執行緒存活？AsyncTask不也coreSize>0麼？
  AsyncTask佇列為LinkedBlockingQueue，所以coreSize主要作用是控制併發；
  其threadPoolExecutor呼叫了allowCoreThreadTimeOut(true)，沒有任務執行的話也是會銷燬執行緒的。

三、拓展AsyncTask

上一章我們花了大量的篇幅講述任務排程的種種細節，構造了相對完善的Executor（系列）。

這一章我們將結合前面的工作，以AsyncTask為藍本，實現一個更強大的非同步任務框架。

通過繼承AsyncTask無法做到我們預想的效果，所以沒辦法，只能重新寫一個了，反正程式碼也不多。

雖然是重新寫，但原來的絕大部分實現和API都會得到保留。

當然名字也要另起一個，不然就和真正的AsyncTask衝突了；

且命名為 UITask ，因為和純粹的執行緒不同，這個非同步框架還要和UI執行緒互動。

3.1 替換Executor

前面實現的PipeExecutor和LaneExecutor，可以用到UITask中。

實現如下：

abstract class UITask<Params, Progress, Result>{
private val mFullName: String = this.javaClass.name
private var mPriority = Priority.NORMAL
private val mTag: String by lazy { generateTag() }

protected open fun generateTag(): String {
return mFullName
}

protected open val executor: TaskExecutor
get() = TaskCenter.laneIO

fun execute(vararg params: Params) {
if (executor is LaneExecutor) {
(executor as LaneExecutor).execute(mTag, mFuture, mPriority)
} else {
(executor as PipeExecutor).execute(mFuture, mPriority)
}
}

fun priority(priority: Int): UITask<Params, Progress, Result> {
var p = priority
if (priority != Priority.IMMEDIATE) {
if (priority > Priority.HIGH) {
p = Priority.HIGH
} else if (priority < Priority.LOW) {
p = Priority.LOW
}
}
mPriority = p
return this
}
}

抽去了其他程式碼，只保留和Executor相關的。

以上程式碼中有關鍵的幾點：

• executor為TaskExecutor，也就是PipeExecutor和LaneExecutor其中一種；
  預設為TaskCenter.laneIO，因為日常使用中用於資料載入的比較多；
  聲明瞭"open", 也是就可以通過override來設定需要的TaskExecutor。
• 預設以全限定名為tag, 當然也可以通過重寫generateTag()來自定義tag。
• 優先順序若非 Priority.IMMEDIATE，會被控制在Priority.LOW和Priority.HIGH之間。

基本要素湊齊，PipeExecutor的併發控制和排程優先順序，LaneExecutor的任務去重也都整合進來了，

剩下的就看如何靈活運用了。

3.2 生命週期

上一篇文章我們提到AsyncTask的問題，其中一個就是在Activity銷燬時不會自動取消，當然也可以做到，只是寫起來麻煩。

那麼我們就在UITask封裝一些程式碼，使其可以觀察Activity/Fragment的生命週期。

說到觀察，很自然地就想到了“觀察者模式”來實現。

關係圖如下：

UITask為觀察者，Activity/Fragment為被觀察者。

因為是多對多的關係，所以需要兩個資料結構：一個SparseArray（Map也可以）一個列表。

SparseArray的key為被觀察者的identityHashCode， value為觀察者（UITask）列表。

當被觀察者需要通知事件的時候，再次獲取被觀察者的identityHashCode，索引到對應觀察者列表，遍歷之。

具體實現如下：

object LifeEvent {
const val DESTROY = 0
const val SHOW = 1
const val HIDE = 2
}

interface LifeListener {
fun onEvent(event: Int)
}

object LifecycleManager {
private val holders = SparseArray<Holder>()

fun register(hostHash: Int, listener: LifeListener?) {
var holder: Holder? = holders.get(hostHash)
if (holder == null) {
holder = Holder()
holders.put(hostHash, holder)
}
holder.add(listener)
}

fun unregister(hostHash: Int, listener: LifeListener?) {
holders.get(hostHash)?.remove(listener)
}

fun notify(host: Any?, event: Int) {
val hostHash = System.identityHashCode(host)
val index = holders.indexOfKey(hostHash)
if (index >= 0) {
val holder = holders.valueAt(index).apply {}
if (event == LifeEvent.DESTROY) {
holders.removeAt(index)
}
holder.notify(event)
}
}
}

需要注意的是，LifecycleManager不是直接持有被觀察者的引用，而是持有其ID（identityHashCode）。

identityHashCode不是hashCode, 它能夠標識一個物件。

如果沒有identityHashCode，我們也可以給被觀察者分配ID序列，但是那樣侵入性會更大一些。

這樣的實現，只需在Activity/Fragment的對應回撥中呼叫一下LifecycleManager.notify(this, event)即可。

另外我們還注意到，LifeEvent除了DESTROY事件外，還有SHOW和HIDE。

觀察Activity/Fragment的可見和隱藏是何意圖？接下來馬上揭曉。

abstract class UITask<Params, Progress, Result> : LifeListener {
private var mHostHash = 0

fun host(host: Any): UITask<Params, Progress, Result> {
mHostHash = System.identityHashCode(host)
LifecycleManager.register(mHostHash, this)
return this
}

private fun detachHost() {
LifecycleManager.unregister(mHostHash, this)
}

override fun onEvent(event: Int) {
if (event == LifeEvent.DESTROY) {
if (!isCancelled && status != Status.FINISHED) {
// no need to call detachHost for host destroy
mHostHash = 0
cancel(true)
}
} else if (event == LifeEvent.SHOW) {
changePriority(+1)
} else if (event == LifeEvent.HIDE) {
changePriority(-1)
}
}

private fun changePriority(increment: Int) {
if (mPriority != Priority.IMMEDIATE) {
mPriority = executor.changePriority(mFuture, mPriority, increment)
}
}
}

• host(Any)方法用於註冊觀察者，也就是構建host和Task的關係。
  為什麼命名為host呢？因為Task通常是在Activity/Fragment中建立（不然我們也不用大費周章折騰生命週期了），
  這時候我們稱Activity/Fragment為“宿主(host)”。
• detachHost() 為私有方法，因為這個方法是在UITask執行完成的時候被呼叫的（內部呼叫）。
• onEvent(Int)函式關注三個事件，前面也提到，除了DESTROY之外，還關注SHOW和HIDE，
  主要是在Activity/Fragment的可見狀態改變時調整排程優先順序。

調整優先順序有什麼用呢？ 下面先看兩張圖感受一下。

為了凸顯效果，我們把載入任務的併發量控制為1（序列）。

第一張是不會自動調整優先順序的，完全的先進先出：

可以看到，切換到第二個頁面，由於上一頁的任務還沒執行完，

所以要一直等到上一頁的任務都完成了才輪到第二個頁面載入。

很顯然這樣體驗不太好。

接下來我們看下動態調整優先順序是什麼效果：

切換到第二個頁面之後，第一個頁面的任務的“排程優先順序”被降低了，所以會優先載入第二個頁面的圖片；

再次切換回第一個頁面，第二個頁面的優先順序被降低，第一個頁面的優先順序恢復，所以優先載入第一個頁面的圖片。

那可否進入第二個頁面的時暫停第一個頁面的任務？

比方說使用者在第二個頁面停留很久，第二個頁面的任務都完成了，然後切換回第一個頁面，發現只有部分圖片（其他被暫停了）。

而如果只是調整優先順序，則第二個頁面的任務都執行完之後，會接著執行第一個頁面的任務，返回第一個頁面時就能夠看到所有圖片了。

這就好比趕車，讓其他人給插個隊，OK，但是不能不給別人排隊了吧~

四、用法

4.1 常規用法

override fun onCreate(savedInstanceState: Bundle?) {
// ...
TestTask()
.priority(Priority.IMMEDIATE)
.host(this)
.execute("hello")
}

private inner class TestTask: UITask<String, Integer, String>(){
override fun generateTag(): String {
// 一般情況下不需要重寫這個函式，這裡只是為了演示
return "custom tag"
}

override fun onPreExecute() {
result_tv.text = "running"
}

override fun doInBackground(vararg params: String): String? {
for (i in 0..100 step 2) {
Thread.sleep(10)
publishProgress(Integer(i))
}
return "result is：" + params[0].toUpperCase()
}

override fun onProgressUpdate(vararg values: Integer) {
val progress = values[0]
progress_bar.progress = progress.toInt()
progress_tv.text = "$progress%"
}

override fun onPostExecute(result: String?) {
result_tv.text = result
}

override fun onCancelled() {
showTips("Task cancel ")
}
}

UITask和AsyncTask用法是類似的, 只是多了一些API：

• 因為生命需要觀察Activity的生命週期，所以需要呼叫host()，傳入當前Activity
• 可以設定任務優先順序
• 有必要時可以重寫generateTag來自定義任務的tag

UITask相比AsyncTask，雖然外表看起來區別不大，但核心卻有質的改變：

1、更靈活的併發控制

2、支援排程優先順序

3、支援任務去重

4、支援生命週期（onDestroy時取消任務，自動調整優先順序）

其中第1點和第4點解決了AsyncTask所存在的問題：

靈活的併發控制，增強了通用性；

支援生命週期，使得任務可以隨Activity銷燬而銷燬，從而也解決了因為生命週期比Activity長導致的記憶體洩漏問題。

至於自動調整優先順序，任務去重等，算是提供了新特性吧。

這些特性，在筆者的另一個開源專案中都用上了。

文章連結： 如何實現一個圖片載入框架

4.2 Executor

當然，專案中不僅僅是UITask，TaskCenter，以及各種Executor, 都是可以單獨使用的。

比方說只是想簡單地執行任務，不需要和UI互動，也可以直接使用Executor：

TaskCenter.io.execute{
// do something
}

TaskCenter.laneIO.execute("laneIO", {
// do something
})

val serialExecutor = PipeExecutor(1)
serialExecutor.execute{
// do something
}

TaskCenter.serial.execute ("your tag", {
// do something
})

4.3 For RxJava

有的文章拿AsyncTask和RxJava做比較，一個300行程式碼的框架和一個2M的框架，其實也沒有太多可比性。

如果說AsyncTask是自行車，“加強版”是摩托車，則RxJava就是汽車（RxJava除了非同步還有更多的內涵）。

各有各的靈魂，不好說誰好誰不好，需看具體場景。

當然，這個“加強版”的初衷是打造更好的非同步任務框架，不是替代RxJava。

而且，雖然摩托車和汽車有較大差異，但取摩托車的汽油來跑汽車也是可以的：

object TaskSchedulers {
val io: Scheduler by lazy { Schedulers.from(TaskCenter.io) }
val computation: Scheduler by lazy { Schedulers.from(TaskCenter.computation) }
val single by lazy { Schedulers.from(PipeExecutor(1)) }
}

Observable.range(1, 8)
.subscribeOn(TaskSchedulers.computation)
.subscribe { Log.d(tag, "number:$it") }

很多開源專案都設計了API來使用外部的Executor，這樣有一個好處：

各種任務都在一個執行緒池上執行任務，可複用彼此建立的執行緒。

4.4 彩蛋

喜歡冰糖葫蘆一樣的鏈式呼叫？

override fun onCreate(savedInstanceState: Bundle?) {
// ...
val task = ChainTask<Double, Int, String>()
task.tag("ChainTest")
.preExecute { result_tv.text = "running" }
.background { params ->
for (i in 0..100 step 2) {
Thread.sleep(10)
task.publishProgress(i)
}
"result is：" + (params[0] * 100)
}
.progressUpdate { values ->
val progress = values[0]
progress_bar.progress = progress
progress_tv.text = "$progress%"
}
.postExecute { result_tv.text = it }
.cancel { showTips("ChainTask cancel ") }
.priority(Priority.IMMEDIATE)
.host(this)
.execute(3.14)
}

至於ChainTask是怎麼實現的，本文就不多做介紹了，且留給讀者自行思考；

或者下載專案， 裡面有具體的實現。

五、下載

implementation 'com.horizon.task:task:1.0.4'

相關程式碼已上傳GitHub,

專案地址： https://github.com/No89757/Task