android系統(tǒng)自帶短信程序源碼部分分析

《android系統(tǒng)自帶短信程序源碼部分分析》由會員分享，可在線閱讀，更多相關《android系統(tǒng)自帶短信程序源碼部分分析（7頁珍藏版）》請在裝配圖網上搜索。

1、系統(tǒng)自帶短信程序源碼部分分析 文章分類：移動開發(fā) 這里并不打算對整個短信源碼進行分析，完全是看了某部分代碼后的自我總結。 我從GIT上clone 了 Conversation （即短信程序）的所有源碼，結果編譯不過。 不過這對分析它的源碼并不造成太大的阻礙。 這里主要對短信主界面的數據和 UI的交互角度進行分析，因為我自己寫的短信 程序在加入獲取聯系人頭像功能后，程序啟動時花費的查詢時間太長。雖然我也 覺得系統(tǒng)默認的短信程序，甚至 HandcentSMS啟動時間都不是很快。（大概是 我的機器性能太差） 一、代碼結構 Conversation 中整體結構主要包括 com.androi

2、d.mms.data 和 com.android.mms.ui,如名字所示，大概就是數據處理部分和 UI部分。數據部 分主要是獲取/緩存聯系人信息、獲取/緩存會話信息等。 ConversationList 類是程序的主activity ,派生于ListActivity ,就是一個大 的列表。此外： ConversationListAdapter 是這個 ListView 的 adapter，派生于 CursorAdapter ; ConversationListItem 是一個自定義的 ViewGroup,派生于 RelativeLayout , 用于表示會話列表的每一個item C

3、onversation表示一個會話數據；Contact表示一個聯系人；ContactList 維護 一個聯系人列表； RecipientIdCache用于開線程讀取一個特殊的表，該表映射會話數據到聯系人 信息，也就是通過Recipient就可以獲取聯系人信息。 二、UI結構 這里的UI主要就是 ConversationList/ConversationListAdapter/ConversationListItem 三者之 間的交互。 在 layout 中，conversation_list_item.xml 作為這個 ListView （ConversationList ）的

4、item 定義，直接使用了 ConversationListItem 這個 view : Java代碼 1. 這個自定義item最重要的工作，就是將會話數據綁定到 UI控件上，例如 QuickContactBadge。在ListView 的使用中，要綁定數據，還有個方法就是自寫 adapter ,在構造adapter時就傳入所有數據。但是如你所見，這種方法需要先 讀取出所有的數據。 而這個系統(tǒng)自帶的短信程序，則沒有一次讀入。這個自定義 item還有個功能就 是，作為一條聯系人信息的更新監(jiān)聽器。 讀取聯系人信息是非常慢的，因為會涉 及到幾個表的查詢。在構造這個item時，程序在另一個線程中異步讀取聯系人 信息，而item只

6、有一個聯系人的簡要信息（電話號碼）。當聯系人讀出來后， 再通知它的監(jiān)聽器，也就是這個item ,然后更新UI顯示。 ConversationListAdapter 中只實現了 bindView 和 newView這兩個函數，此外, 它作為 listView 的 AbsListView.RecyclerListener ,還實現了 onMovedToScrapHeap 數。 關于RecyclerListener ,這里有篇文章從源碼級角度分析了下,大概意思就是 ListView 在處理item時，有個緩存機制。 三、數據與UI的映射 這部分才是重要的分析部分，也是我需要學習的部分。

7、ConversationList 的onStart中，開啟了一個異步查詢，查詢所有的會話: Java代碼 -- 1. @Override 2. protected void onStart() { 3. super.onStart(); 4. 5. ……. 6. startAsyncQuery(); startyAsyncQuery 調用了 Conversation.startQueryForAll 函數，該函數說白 了還是調用 AsyncQueryHandler.startQuery 函數： Java代碼 1. public static void startQueryF

8、orAll(AsyncQueryHandler handl er, int token) { 2. handler.cancelOperation(token); 3. handler.startQuery(token, null, sAllThreadsUri, 4. ALL_THREADS_PROJECTIONull, null, Conversations.DEFAULT_SORT_ORDER); 5. } 關于如何獲取會話列表，其實就是個SQL的連表查詢，可以參見這里：獲取短信 會話列表 當查詢完后，android 回調到自己實現的 AsyncQueryHandler.o

9、nQueryComplete , 該函數主要就是告訴 adapter , we have done!: Java代碼 1. @Override 2. protected void onQueryComplete(int token, Object cookie, Cursor cursor) { 3. switch (token) { 4. case THREAD_LIST_QUERY_TOKEN: 5. mListAdapter.changeCursor(cursor); 一旦adapter獲得了一個cursor后，就會主動去取得listview 的各項數據。以 上便是獲取會話

10、列表的大致流程。 接下來看看聯系人獲取的流程： adapter獲得數據后，會調用bindView來綁定數據到UI的item : Java代碼 - 1. @Override 2. public void bindView(View view, Context context, Cursor cursor) { 3. if (!(view instanceof ConversationListItem)) { 4. Log.e(TAG, "Unexpected bound view: " + vi ew); 5. return; 6. } 7. 8. Conversatio

11、nListItem headerView = (ConversationListI tem) view; 9. Conversation conv = Conversation.from(context, curs or); 10. 11. ConversationListItemData ch = new ConversationListI temData(context, conv); 12. headerView.bind(context, ch); 13. } Conversation.from 函數會先檢查 Conversation 緩存中是否有該 cursor對應

12、的 數據，沒有的話則會從cursor中?。? Java代碼 1. public static Conversation from(Context context, Cursor c ursor) { 2. // First look in the cache for the Conversation and return that one. That way, all the 3. // people that are looking at the cached copy will get updated when fillFromCursor() is 4. // called

13、 with this cursor. 5. long threadId = cursor.getLong(ID); 6. if (threadId > 0) { 7. Conversation conv = Cache.get(threadId); 8. if (conv != null) { 9. f川FromCursor(context, conv, cursor, false); // update the existing conv in-place 10. return conv; 11. } 12. } 13. Conversation conv = new C

14、onversation(context, curs or, false); 14. try { 15. Cache.put(conv); 16. } catch (IllegalStateException e) { 17. LogTag.error("Tried to add duplicate Conver sation to Cache"); 18. } 19. return conv; 20. } 然后主要是fillFromCursor 函數（如果是創(chuàng)建新的Conversation ,其構造函數 中也是調用了該函數），該函數就是簡單地從cursor中getXXXX

15、獲取各個數據， 并且，最重要的，獲取聯系人信息： Java代碼 1. private Conversation 2. 3. 4. ... 5. s(recipientIds, static void fillFromCursor(Context context, conv, Cursor c, boolean allowQuery) { ContactList recipients = ContactList.getById allowQuery); 注意這里allowQuery參數為false 。 ContactList.getByIds 函數根據 Conversa

16、tion 中 recipientIds 獲取出對應的 address ,然后根據address從聯系人URI中進一步獲取聯系人信息。 Java代碼 1. public static ContactList getByIds(String spaceSepIds, boo lean canBlock) { 2. ContactList list = new ContactList(); 3. for (RecipientIdCache.Entry entry : RecipientIdCach e.getAddresses(spaceSepIds)) { 4. if (entry !

17、= null && !TextUtils.isEmpty(en try.number)) { 5. Contact contact = Contact.get(entry. number, canBlock); 6. contact.setRecipientId(entry.id); 7. list.add(contact); 8. } 9. } 10. return list; 11. } 最終的 contact 被生成于 Contact.get(entry.number, canBlock)中。該函數在canBlock為false的情況下，會push 一個異步執(zhí)行體（

18、Runnable）到一個線程中。 然后將contact返回。最終返回到adapter那一層的函數。 這個異步查詢線程，會真正地去查詢聯系人信息。在此之前，外界獲取出來的聯 系人不過是一個很簡單的信息：只有電話號碼。 adapter 的 bindView 中，緊接著: Java代碼 ch = new ConversationListI ch); 1. ConversationListItemData temData(context, conv); 2. headerView.bind(context, 3. } bind函數中很重要的操作，就是建立該會話對應的聯系人對象的監(jiān)聽:

19、 Java代碼 1. ContactList contacts = ch.getContacts(); 2. 3. if (DEBUG) Log.v(TAG, "bind: contacts.addListeners " + t his); 4. Contact.addListener(this); 以上過程，即展示了會話數據是如何映射到 ListView的item ,及聯系人信息是 如何與會話和listview item 建立聯系（即異步查詢，然后同步）。 值得一提的是：查詢聯系人信息都是在bindView時發(fā)生，當一個listview 被顯 示出來后，未顯示的item是不會被

20、觸發(fā)bind的，也就是說：在listview 顯示 時，不會觸發(fā)查詢整個會話對應的所有聯系人，只有顯示出來的 item才會涉及 到查詢聯系人。 基于以上，我寫了一個測試程序。結果似乎很好，就像系統(tǒng)自帶的短信程序一樣。 啟動速度依然不算快。問題的所在，似乎并不在于查詢時間花費的很長。listview 倒是早就顯示出來了（看見了程序標題），但是 items卻要花些時間才能顯示。 而且，我的測試程序更為惡心的是，listview 在上下滾動時，會顯得有點卡。 經過一番折騰，發(fā)現是bindView里花的時間過長，后來加了 Conversation的緩 存，甚至去掉了日志，依然有點卡。不知道有否高手幫我解決下。 測試例子見附件。 1.10.2011 update 之前例子程序中 ListView 上下滾動時，會顯得有點卡。本來都放棄不管了，結 果今天打開 eclipse 時莫名其妙就想起這事：也許應該用 ListActivity ！結果 一改，還真不卡了。注：系統(tǒng)的短信程序用的就是 ListActivity 。