系统自带短信程序源码部分分析

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

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

[b]一、代码结构[/b]

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就可以获取联系人信息。

[b]二、UI结构[/b]

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

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

[code]
<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" >
[/code]

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

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

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

关于RecyclerListener，这里[url=http://liyan3ban.blog.163.com/blog/static/130459062009102364015288/]有篇文章[/url]从源码级角度分析了下，大概意思就是ListView在处理item时，有个缓存机制。

[b]三、数据与UI的映射[/b]

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

[code]
@Override
protected void onStart() {
super.onStart();

.......
startAsyncQuery();
[/code]

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

[code]
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);
}
[/code]

关于如何获取会话列表，其实就是个SQL的连表查询，可以参见这里：[url=http://kevinlynx.iteye.com/blog/857633]获取短信会话列表[/url]

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

[code]
@Override
protected void onQueryComplete(int token, Object cookie, Cursor cursor) {
switch (token) {
case THREAD_LIST_QUERY_TOKEN:
mListAdapter.changeCursor(cursor);
[/code]

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

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

[code]
@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);
}
[/code]

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

[code]
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;
}

[/code]

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

[code]
private static void fillFromCursor(Context context, Conversation conv,
Cursor c, boolean allowQuery) {

...
ContactList recipients = ContactList.getByIds(recipientIds, allowQuery);
[/code]

注意这里allowQuery参数为false。

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

[code]
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;
}
[/code]

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

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

adapter的bindView中，紧接着：
[code]
ConversationListItemData ch = new ConversationListItemData(context, conv);
headerView.bind(context, ch);
}
[/code]

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

[code]
ContactList contacts = ch.getContacts();

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

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

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


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

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

测试例子见附件。

[color=red]
1.10.2011 update

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