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

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

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

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

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

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

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

7、ConversationList 的onStart中，開啟了一個異步查詢，查詢所有的會話: Java代碼 -- 1. @Override 2. protected void onStart() { 3. super.onStart(); 4. 5. ……. 6. startAsyncQuery(); startyAsyncQuery 調(diào)用了 Conversation.startQueryForAll 函數(shù)，該函數(shù)說白 了還是調(diào)用 AsyncQueryHandler.startQuery 函數(shù)： 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. } 關(guān)于如何獲取會話列表，其實就是個SQL的連表查詢，可以參見這里：獲取短信 會話列表 當查詢完后，android 回調(diào)到自己實現(xiàn)的 AsyncQueryHandler.o

9、nQueryComplete , 該函數(shù)主要就是告訴 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 的各項數(shù)據(jù)。以 上便是獲取會話

10、列表的大致流程。 接下來看看聯(lián)系人獲取的流程： adapter獲得數(shù)據(jù)后，會調(diào)用bindView來綁定數(shù)據(jù)到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 函數(shù)會先檢查 Conversation 緩存中是否有該 cursor對應(yīng)

12、的 數(shù)據(jù)，沒有的話則會從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 函數(shù)（如果是創(chuàng)建新的Conversation ,其構(gòu)造函數(shù) 中也是調(diào)用了該函數(shù)），該函數(shù)就是簡單地從cursor中g(shù)etXXXX

15、獲取各個數(shù)據(jù)， 并且，最重要的，獲取聯(lián)系人信息： 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參數(shù)為false 。 ContactList.getByIds 函數(shù)根據(jù) Conversa

16、tion 中 recipientIds 獲取出對應(yīng)的 address ,然后根據(jù)address從聯(lián)系人URI中進一步獲取聯(lián)系人信息。 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)中。該函數(shù)在canBlock為false的情況下，會push 一個異步執(zhí)行體（

18、Runnable）到一個線程中。 然后將contact返回。最終返回到adapter那一層的函數(shù)。 這個異步查詢線程，會真正地去查詢聯(lián)系人信息。在此之前，外界獲取出來的聯(lián) 系人不過是一個很簡單的信息：只有電話號碼。 adapter 的 bindView 中，緊接著: Java代碼 ch = new ConversationListI ch); 1. ConversationListItemData temData(context, conv); 2. headerView.bind(context, 3. } bind函數(shù)中很重要的操作，就是建立該會話對應(yīng)的聯(lián)系人對象的監(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); 以上過程，即展示了會話數(shù)據(jù)是如何映射到 ListView的item ,及聯(lián)系人信息是 如何與會話和listview item 建立聯(lián)系（即異步查詢，然后同步）。 值得一提的是：查詢聯(lián)系人信息都是在bindView時發(fā)生，當一個listview 被顯 示出來后，未顯示的item是不會被

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