【文章內(nèi)容簡介】 線程，各自有一個Handler來處理消息。，在XXX函數(shù)內(nèi)部會將請求封裝成一個內(nèi)部的參數(shù)類，將其作為消息的參數(shù)，將此消息發(fā)送至另一個線程。，接受該消息，并分析傳入的參數(shù)，用初始化時傳入的ContentResolver進行XXX操作，并返回Cursor或其他返回值。，將上述返回值以及其他相關(guān)內(nèi)容綁定在該消息上，發(fā)送回主線程。（可自定義，但由于都是內(nèi)部類，基本沒有意義...）會分析該消息，并轉(zhuǎn)發(fā)給對應(yīng)的onXXXComplete方法。這就是它偷偷摸摸做過的事情，基本還是很好理解的。我唯一好奇的是它的線程管理方式，我猜測他是用的單件模式。第一個AsyncQueryHandler的實例化會導(dǎo)致創(chuàng)建一個線程，從此該線程成為不死老處男，所有的ContentResolver相關(guān)的工作，都由該線程統(tǒng)一完成。個人覺得這種解決方式很贊。本來這個線程的生命周期就很難估量，并且，當你有一個ContentProvider的請求的時候，判斷你會做更多的類似操作并不過分。就算錯了，花費的也只是一個不死的線程（與進程同生死共存亡...），換來的卻是簡單的生命周期管理和無數(shù)次線程生死開銷的節(jié)約。同時另外一個很重要的問題，他并會涉及到單件中數(shù)據(jù)同步的問題，每個類都有各自的Handler類，彼此互不干擾，分發(fā)可以分別進行。當多個數(shù)據(jù)請求的時候，在同一個ContentResolver上進行的可能微乎其微，這就避免了堵塞。總而言之，這套解決辦法和Android的整體設(shè)計算是天作之合了。所以建議，如果你有什么非ContentProvider操作，卻需要異步多線程執(zhí)行的話，模擬一套，是個不錯的策略，當然，具體情況具體分析，生搬硬套是學不好馬列主義的。Android的界面顯示同樣也是基于控件的。通常是用View（包括ViewGroup）控件配上XML的樣式來做的。具體細節(jié)不想說了，可以參考 Samples里的ApiDemos/View，和View的Doc，以及Implementing a UI這篇Doc。其他還有很多，感覺算是SDK講述的最多的內(nèi)容。從控件的使用上，和網(wǎng)頁的設(shè)計類似，盡量用parent_width之類的抽象長度，用Theme來做風格，抽取所有的字串等信息做本地化設(shè)計。相關(guān)內(nèi)容參看Implementing a UI就好。一類比較重要的是數(shù)據(jù)綁定控件。一個支持數(shù)據(jù)綁定的控件，比如ListView。可以通過一個 ListAdapter綁定到一個數(shù)據(jù)源上。ListAdapter是一個抽象類，主要的實現(xiàn)類包括SimpleAdapter和 SimpleCursorAdapter。前者是綁定一個靜態(tài)的Array，后者是綁定一個動態(tài)的Cursor。Cursor前面說過，是一個指向數(shù)據(jù)源的隨機迭代器，將View綁定到Cursor通常要設(shè)置這樣幾個參數(shù)。一個是每一行的樣式，稱作Row Layout，其實就是一個普通的Layout的XML文件。還有就是一個列和現(xiàn)實控件的對應(yīng)關(guān)系。那個控件顯示哪個列的值，這是需要配置的。為了定制一個良好的數(shù)據(jù)顯示控件，最簡單你可以定制很PP的Row Layout，復(fù)雜一點就是可以重載綁定控件View，或者是適配器ListAdapter。如果是一個數(shù)據(jù)顯示密集的應(yīng)用，且你對UI有些追求，這個工作估計是必不可少的。一個主要用于顯示數(shù)據(jù)內(nèi)容的Activity，可以選擇派生自ListActivity。它提供了一個具有ListView 的Layout，還有simple_list_item_1, simple_list_item_2, two_line_list_item等默認的Row Layout，還有一些比較不錯的API，和可供響應(yīng)選擇Item的事件?？梢詽M足你比較基礎(chǔ)的需求。如果你覺得只有一個ListView的界面太突兀，你可以為這個ListActivity指定一個Layout，需要注意的是，你需要提供一個id為@android:id/list的ListView控件，避免Activity在內(nèi)部偷偷尋找該控件的時候失敗。除了這些要求，做好UI還有注意易用性和效率?？旖萱I是一個比較不錯的選擇，在 Activity中調(diào)用setDefaultkeyMode(SHORTCUT_DEFAULT_KEYS)，可以開啟快捷鍵模式，然后你可以將菜單綁定到指定快捷鍵上就OK了。個人覺得Tip也是一個比較重要的東西，但目前觀察看來，這個東西只能夠自己提供了。界面的動態(tài)性有時候是不可避免的，比如說菜單就是一個需要經(jīng)常根據(jù)光標位置提供不同的選項。這個東西Android很人道的考慮到了，你可以參看NodeList這個Sample。它采取的應(yīng)該是一個靜態(tài)模擬動態(tài)的方式，這樣有助于提高速度。你也可以利用ViewInflate，動態(tài)從一個XML創(chuàng)建一個控件。成本據(jù)Doc說很大，不到萬不得已不要使用。在前面寫Android的ContentProvider時候，可以看到那是基于觀察者模式的一個消息傳遞方法。每一個Cursor、ContentResolver做為一個小的注冊中心，相關(guān)觀察者可以在這個中心注冊，更新消息由注冊中心分發(fā)給各個觀察者。而在MFC或Winform中，都會形成一個消息網(wǎng)，讓消息在網(wǎng)中流動，被各節(jié)點使用、吃掉或者在出口死掉。相比之下，我個人覺得基于Intent的Android核心消息傳遞機制是有所不同的。它應(yīng)該會有一個全局性的注冊中心，這個注冊中心是隱性的，整個Android系統(tǒng)中就那么一個。所有的消息接收者，都被隱形的注冊到這個中心。包括Activity，Service和IntentReceiver。其實說隱形注冊是不確切的，所有注冊都還是我們手動告訴注冊中心的，只是與傳統(tǒng)的方式不一樣，我們通常不是通過代碼，而是通過配置文件來做。在應(yīng)用的Manifest中，我們會為一些Activity或Service添加上Intentfilter，或在配置文件中添加項。這其實就相當于向系統(tǒng)的注冊中心，注冊了相關(guān)的Intentfilter和receiver（這個事情完全可以通過代碼來做，只是這樣就失去了修改的靈活性）。當程序有一個消息希望發(fā)出去的時候，它需要將消息封裝成一個Intent，并發(fā)送。這時候，應(yīng)該是有一個統(tǒng)一的中心（恩，有可能Android底層實現(xiàn)的時候不是，但簡單這樣看是沒問題的...）接受到這個消息，并對它進行解析、判定消息類型（這個步驟降低了耦合...），然后檢查注冊了相匹配的filter或receiver，并創(chuàng)建或喚醒接收者，將消息分發(fā)給它。這樣做有很多好處。雖然這種傳遞有的時候不如點對點的傳遞快（這有些需要速度的地方，我們看到Android會通過直接通信來做），但有時候又因為它只經(jīng)過一跳（姑且這么叫吧...），比復(fù)雜的流動又要更快。更重要的是，它耦合性低，在手機平臺這種程序組件多變的條件下使用十分適合。并且它可以很容易實現(xiàn)消息的精確或模糊匹配，彈性很大。（我個人曾想在開發(fā)一個C++二次平臺的時候引入這樣的機制，但在C++中，建立一套完整的數(shù)據(jù)marshal機制不容易，相比之下，用java來做會簡單很多...）恩，廢話說了很多，具體講講Android中Intent的使用。當你有一個消息需要傳遞，如果你明確知道你需要哪個Activity或者其他Class來響應(yīng)的話，你可以指定這個類來接受該消息，這被稱為顯性發(fā)送。你需要將Intent的class屬性設(shè)置成目標。這種情況很常見，比如startActivity的時候，會清楚當前Activity完了應(yīng)該是哪個Activity，那就明確的發(fā)送這個消息。但是，有的時候你并不確定你的消息是需要具體哪個類來執(zhí)行，而只是知道接收者該符合哪些條件。比如你只需要有一個接收者能顯示用戶所選的數(shù)據(jù)，而不想制定某個具體的方法，這時候你就需要用到隱形發(fā)送（傳統(tǒng)上，我們可能會考慮用多態(tài)，但顯然這種方式更為靈活...）。在Android中，你可以為Intent指定一個action，表示你這個指令需要處理的事情。系統(tǒng)為我們定義了很多Action類型