[开发优化] 系统自带短信程序源码部分分析

http://d-android.com/developer/thread-3931-1-1.html

http://www.eoeandroid.com/thread-75930-1-1.html

这里并不打算对整个短信源码进行分析，完全是看了某部分代码后的自我总结。我从GIT上clone了Conversation（即短信程序）的所有源码，结果编译不过。不过这对分析它的源码并不造成太大的阻碍。 

这里主要对短信主界面的数据和UI的交互角度进行分析，因为我自己写的短信程序在加入获取联系人头像功能后，程序启动时花费的查询时间太长。虽然我也觉得系统默认的短信程序，甚至HandcentSMS，启动时间都不是很快。（大概是我的机器性能太差） 

一、代码结构 

Conversation中整体结构主要包括com.android.mms.data和com.android.mms.ui，如名字所示，大概就是数据处理部分和UI部分。数据部分主要是获取/缓存联系人信息、获取/缓存会话信息等。 

ConversationList类是程序的主activity，派生于ListActivity，就是一个大的列表。此外： 
ConversationListAdapter是这个ListView的adapter，派生于CursorAdapter； 
ConversationListItem是一个自定义的ViewGroup，派生于RelativeLayout，用于表示会话列表的每一个item； 
Conversation表示一个会话数据；Contact表示一个联系人；ContactList维护一个联系人列表； 
RecipientIdCache用于开线程读取一个特殊的表，该表映射会话数据到联系人信息，也就是通过Recipient就可以获取联系人信息。 

二、UI结构 

这里的UI主要就是ConversationList/ConversationListAdapter/ConversationListItem三者之间的交互。 

在layout中，conversation_list_item.xml作为这个ListView（ConversationList）的item定义，直接使用了ConversationListItem这个view： 

Java代码 
、

<com.android.mms.ui.ConversationListItem xmlns:android="http://schemas.android.com/apk/res/android"  
    android:layout_width="match_parent"  
    android:layout_height="?android:attr/listPreferredItemHeight"  
    android:background="@drawable/conversation_item_background_unread"  
    android:paddingRight="10dip" >  

这个自定义item最重要的工作，就是将会话数据绑定到UI控件上，例如QuickContactBadge。在ListView的使用中，要绑定数据，还有个方法就是自写adapter，在构造adapter时就传入所有数据。但是如你所见，这种方法需要先读取出所有的数据。 

而这个系统自带的短信程序，则没有一次读入。这个自定义item还有个功能就是，作为一条联系人信息的更新监听器。读取联系人信息是非常慢的，因为会涉及到几个表的查询。在构造这个item时，程序在另一个线程中异步读取联系人信息，而item只有一个联系人的简要信息（电话号码）。当联系人读出来后，再通知它的监听器，也就是这个item，然后更新UI显示。 

ConversationListAdapter中只实现了bindView和newView这两个函数，此外，它作为listView的AbsListView.RecyclerListener，还实现了onMovedToScrapHeap函数。 

关于RecyclerListener，这里有篇文章从源码级角度分析了下，大概意思就是ListView在处理item时，有个缓存机制。 

三、数据与UI的映射 

这部分才是重要的分析部分，也是我需要学习的部分。 
ConversationList的onStart中，开启了一个异步查询，查询所有的会话： 

Java代码 @Override  


protected void onStart() {   
    super.onStart();   
  
     .......   
    startAsyncQuery();  

   startyAsyncQuery调用了Conversation.startQueryForAll函数，该函数说白了还是调用AsyncQueryHandler.startQuery函数： 

Java代码 

public static void startQueryForAll(AsyncQueryHandler handler, int token) {   
    handler.cancelOperation(token);   
    handler.startQuery(token, null, sAllThreadsUri,   
            ALL_THREADS_PROJECTION, null, null, Conversations.DEFAULT_SORT_ORDER);   
}  

   关于如何获取会话列表，其实就是个SQL的连表查询，可以参见这里：获取短信会话列表 

当查询完后，android回调到自己实现的AsyncQueryHandler.onQueryComplete，该函数主要就是告诉adapter，we have done!: 

Java代码 

@Override  

protected void onQueryComplete(int token, Object cookie, Cursor cursor) {   
    switch (token) {   
    case THREAD_LIST_QUERY_TOKEN:   
        mListAdapter.changeCursor(cursor);  

       一旦adapter获得了一个cursor后，就会主动去取得listview的各项数据。以上便是获取会话列表的大致流程。 

接下来看看联系人获取的流程： 
adapter获得数据后，会调用bindView来绑定数据到UI的item： 

Java代码 @Override  


public void bindView(View view, Context context, Cursor cursor) {   
    if (!(view instanceof ConversationListItem)) {   
        Log.e(TAG, "Unexpected bound view: " + view);   
        return;   
    }   
  
    ConversationListItem headerView = (ConversationListItem) view;   
    Conversation conv = Conversation.from(context, cursor);   
  
    ConversationListItemData ch = new ConversationListItemData(context, conv);   
    headerView.bind(context, ch);   
}  

    Conversation.from函数会先检查Conversation缓存中是否有该cursor对应的数据，没有的话则会从cursor中取： 

Java代码 

public static Conversation from(Context context, Cursor cursor) {   
    // First look in the cache for the Conversation and return that one. That way, all the   
    // people that are looking at the cached copy will get updated when fillFromCursor() is   
    // called with this cursor.   
    long threadId = cursor.getLong(ID);   
    if (threadId > 0) {   
        Conversation conv = Cache.get(threadId);   
        if (conv != null) {   
            fillFromCursor(context, conv, cursor, false);   // update the existing conv in-place   
            return conv;   
        }   
    }   
    Conversation conv = new Conversation(context, cursor, false);   
    try {   
        Cache.put(conv);   
    } catch (IllegalStateException e) {   
        LogTag.error("Tried to add duplicate Conversation to Cache");   
    }   
    return conv;   
}  

   然后主要是fillFromCursor函数（如果是创建新的Conversation，其构造函数中也是调用了该函数），该函数就是简单地从cursor中getXXXX获取各个数据，并且，最重要的，获取联系人信息： 

Java代码     private static void fillFromCursor(Context context, Conversation conv,   

                                       Cursor c, boolean allowQuery) {   
  
...   
        ContactList recipients = ContactList.getByIds(recipientIds, allowQuery);  

    注意这里allowQuery参数为false。 

ContactList.getByIds函数根据Conversation中recipientIds获取出对应的address，然后根据address从联系人URI中进一步获取联系人信息。 

Java代码 public static ContactList getByIds(String spaceSepIds, boolean canBlock) {   

    ContactList list = new ContactList();   
    for (RecipientIdCache.Entry entry : RecipientIdCache.getAddresses(spaceSepIds)) {   
        if (entry != null && !TextUtils.isEmpty(entry.number)) {   
            Contact contact = Contact.get(entry.number, canBlock);   
            contact.setRecipientId(entry.id);   
            list.add(contact);   
        }   
    }   
    return list;   
}  

   最终的contact被生成于Contact.get(entry.number, canBlock)中。该函数在canBlock为false的情况下，会push一个异步执行体(Runnable)到一个线程中。然后将contact返回。最终返回到adapter那一层的函数。 

这个异步查询线程，会真正地去查询联系人信息。在此之前，外界获取出来的联系人不过是一个很简单的信息：只有电话号码。 

adapter的bindView中，紧接着： 
Java代码     ConversationListItemData ch = new ConversationListItemData(context, conv);   

    headerView.bind(context, ch);   
}  

        bind函数中很重要的操作，就是建立该会话对应的联系人对象的监听： 

Java代码 

ContactList contacts = ch.getContacts();   
  

if (DEBUG) Log.v(TAG, "bind: contacts.addListeners " + this);   
Contact.addListener(this);  

       以上过程，即展示了会话数据是如何映射到ListView的item，及联系人信息是如何与会话和listview item建立联系（即异步查询，然后同步）。 


值得一提的是：查询联系人信息都是在bindView时发生，当一个listview被显示出来后，未显示的item是不会被触发bind的，也就是说：在listview显示时，不会触发查询整个会话对应的所有联系人，只有显示出来的item才会涉及到查询联系人。 



基于以上，我写了一个测试程序。结果似乎很好，就像系统自带的短信程序一样。启动速度依然不算快。问题的所在，似乎并不在于查询时间花费的很长。listview倒是早就显示出来了（看见了程序标题），但是items却要花些时间才能显示。 

而且，我的测试程序更为恶心的是，listview在上下滚动时，会显得有点卡。经过一番折腾，发现是bindView里花的时间过长，后来加了Conversation的缓存，甚至去掉了日志，依然有点卡。不知道有否高手帮我解决下。 

测试例子见附件。 


1.10.2011 update 

之前例子程序中ListView上下滚动时，会显得有点卡。本来都放弃不管了，结果今天打开eclipse时莫名其妙就想起这事：也许应该用ListActivity！结果一改，还真不卡了。注：系统的短信程序用的就是ListActivity。