闡述Android新增效果
谷歌的投在大獎(jiǎng)賽的錢看來(lái)不會(huì)白花。對(duì)于所有做Android的人，所有一切都違背了一般的操作方式，還是那句，很酷，但需要時(shí)間的考驗(yàn)，本僅供大家學(xué)習(xí)參考。
但讓我倍感孤獨(dú)的是，不知道是沒人做異步的ContentProvider訪問(wèn)，還是這個(gè)類使用太過(guò)于弱智（這個(gè)使用方法可是我摸索了半天的啊，難道我真的如此的弱@_@），抑或是大家都各有高招，從SDK到網(wǎng)上，沒有任何關(guān)于該類的有點(diǎn)用的說(shuō)明。
而我又恰巧悲傷的發(fā)現(xiàn)，這個(gè)類其實(shí)有很多的問(wèn)題，比如他吃掉異常，有錯(cuò)誤時(shí)只是簡(jiǎn)單的返回null指針（這個(gè)其實(shí)不能怪他，你可以看看這里...）；當(dāng)你傳一個(gè)null的ContentResolver進(jìn)去的時(shí)候，沒有任何異常，只是莫名其妙的丟棄所有消息，使你陷入苦苦的等待而不知其因；
更憤慨的是，他的Androidn傳遞竟然有Bug（難道還是我使用不對(duì)&_&），從startXX傳入的token，到onXXComplete里面一律變成1，而文檔上明明寫著兩個(gè)是一個(gè)東西（我的解決方法是用cookie做token，這個(gè)不會(huì)丟*_*）。不過(guò)我暫時(shí)還沒有遺棄它的打算，雖然沒人理睬，雖然有一堆問(wèn)題，雖然我按圖索驥造了個(gè)新輪子，但為了節(jié)省剩下的一些無(wú)聊的工作，我決定茍且偷生了。
還是習(xí)慣性跑題了，其實(shí)，我是想通過(guò)我對(duì)這個(gè)類的無(wú)數(shù)次Debugger跟進(jìn)，說(shuō)說(shuō)它的多線程異步處理的解決策略的。他的基本策略如下：
1. 當(dāng)你實(shí)例化一個(gè)AsyncQueryHandler類時(shí)（包括其子類...），它會(huì)單件構(gòu)造一個(gè)線程（后面會(huì)詳述...），這個(gè)線程里面會(huì)構(gòu)建一個(gè)消息循環(huán)。
2. 獲得該消息循環(huán)的指針，用它做參數(shù)實(shí)例化另一個(gè)Handler類，該類為內(nèi)部類。至此，就有了兩個(gè)線程，各自有一個(gè)Handler來(lái)處理消息。
3. 當(dāng)調(diào)用onXXX的時(shí)候，在XXX函數(shù)內(nèi)部會(huì)將請(qǐng)求封裝成一個(gè)內(nèi)部的參數(shù)類，將其作為消息的參數(shù)，將此消息發(fā)送至另一個(gè)線程。
4. 在該線程的Handler中，接受該消息，并分析傳入的參數(shù)，用初始化時(shí)傳入的ContentResolver進(jìn)行XXX操作，并返回Cursor或其他返回值。
5. 構(gòu)造一個(gè)消息，將上述返回值以及其他相關(guān)內(nèi)容綁定在該消息上，發(fā)送回主線程。
6. 主線程默認(rèn)的AsyncQueryHandler類的handleMessage方法（可自定義，但由于都是內(nèi)部類，基本沒有意義...）會(huì)分析該消息，并轉(zhuǎn)發(fā)給對(duì)應(yīng)的onXXXComplete方法。
7. 用戶重寫的onXXXComplete方法開始工作。
這就是它偷偷摸摸做過(guò)的事情，基本還是很好理解的。我唯一好奇的是它的線程管理方式，我猜測(cè)他是用的單件模式。第一個(gè)AsyncQueryHandler的實(shí)例化會(huì)導(dǎo)致創(chuàng)建一個(gè)線程，從此該線程成為不死老處男。
所有ContentResolver相關(guān)的工作，都由該線程統(tǒng)一完成。個(gè)人覺得這種解決方式很贊。本來(lái)這個(gè)線程的生命周期就很難估量，并且，當(dāng)你有一個(gè)ContentProvider的請(qǐng)求的時(shí)候，判斷你會(huì)做更多的類似操作并不過(guò)分。
就算錯(cuò)了，花費(fèi)的也只是一個(gè)不死的線程（與進(jìn)程同生死共存亡...），換來(lái)的卻是簡(jiǎn)單的生命周期管理和無(wú)數(shù)次線程生死開銷的節(jié)約。同時(shí)另外一個(gè)很重要的問(wèn)題，他并會(huì)涉及到單件中數(shù)據(jù)同步的問(wèn)題，每個(gè)類都有各自的Handler類，彼此互不干擾，分發(fā)可以分別進(jìn)行。
當(dāng)多個(gè)數(shù)據(jù)請(qǐng)求的時(shí)候，在同一個(gè)ContentResolver上進(jìn)行的可能微乎其微，這就避免了堵塞。總而言之，這套解決辦法和Android的整體設(shè)計(jì)算是天作之合了。所以建議，如果你有什么非ContentProvider操作，卻需要異步多線程執(zhí)行的話，模擬一套，是個(gè)不錯(cuò)的策略，當(dāng)然，具體情況具體分析，生搬硬套是學(xué)不好馬列主義的。
【編輯推薦】
