闡述Android新增效果

谷歌的投在大獎賽的錢看來不會白花。對於所有做android的人，所有一切都違背了一般的操作方式，還是那句，很酷，但需要時間的考驗，本僅供大家學習參考。

但讓我倍感孤獨的是，不知道是沒人做異步的ContentProvider訪問，還是這個類使用太過於弱智（這個使用方法可是我摸索了半天的啊，難道我真的如此的弱@_@），抑或是大家都各有高招，從SDK到網上，沒有任何關於該類的有點用的說明。

而我又恰巧悲傷的發現，這個類其實有很多的問題，比如他吃掉異常，有錯誤時只是簡單的返回null指針（這個其實不能怪他，你可以看看這裡...）；當你傳一個null的ContentResolver進去的時候，沒有任何異常，只是莫名其妙的丟棄所有消息，使你陷入苦苦的等待而不知其因；

更憤慨的是，他的androidn傳遞竟然有Bug（難道還是我使用不對&_&），從startXX傳入的token，到onXXComplete裡面一律變成1，而文檔上明明寫著兩個是一個東西（我的解決方法是用cookIE做token，這個不會丟*_*）。不過我暫時還沒有遺棄它的打算，雖然沒人理睬，雖然有一堆問題，雖然我按圖索骥造了個新輪子，但為了節省剩下的一些無聊的工作，我決定苟且偷生了。

還是習慣性跑題了，其實，我是想通過我對這個類的無數次Debugger跟進，說說它的多線程異步處理的解決策略的。他的基本策略如下：
1. 當你實例化一個AsyncQueryHandler類時（包括其子類...），它會單件構造一個線程（後面會詳述...），這個線程裡面會構建一個消息循環。
2. 獲得該消息循環的指針，用它做參數實例化另一個Handler類，該類為內部類。至此，就有了兩個線程，各自有一個Handler來處理消息。
3. 當調用onXXX的時候，在XXX函數內部會將請求封裝成一個內部的參數類，將其作為消息的參數，將此消息發送至另一個線程。
4. 在該線程的Handler中，接受該消息，並分析傳入的參數，用初始化時傳入的ContentResolver進行XXX操作，並返回Cursor或其他返回值。
5. 構造一個消息，將上述返回值以及其他相關內容綁定在該消息上，發送回主線程。
6. 主線程默認的AsyncQueryHandler類的handleMessage方法（可自定義，但由於都是內部類，基本沒有意義...）會分析該消息，並轉發給對應的onXXXComplete方法。
7. 用戶重寫的onXXXComplete方法開始工作。

這就是它偷偷摸摸做過的事情，基本還是很好理解的。我唯一好奇的是它的線程管理方式，我猜測他是用的單件模式。第一個AsyncQueryHandler的實例化會導致創建一個線程，從此該線程成為不死老處男。

所有ContentResolver相關的工作，都由該線程統一完成。個人覺得這種解決方式很贊。本來這個線程的生命周期就很難估量，並且，當你有一個ContentProvider的請求的時候，判斷你會做更多的類似操作並不過分。

就算錯了，花費的也只是一個不死的線程（與進程同生死共存亡...），換來的卻是簡單的生命周期管理和無數次線程生死開銷的節約。同時另外一個很重要的問題，他並會涉及到單件中數據同步的問題，每個類都有各自的Handler類，彼此互不干擾，分發可以分別進行。

當多個數據請求的時候，在同一個ContentResolver上進行的可能微乎其微，這就避免了堵塞。總而言之，這套解決辦法和android的整體設計算是天作之合了。所以建議，如果你有什麼非ContentProvider操作，卻需要異步多線程執行的話，模擬一套，是個不錯的策略，當然，具體情況具體分析，生搬硬套是學不好馬列主義的。