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