本文基于Android4.4.2浅析Contacts及相关模块的功能实现，以及的操作。
本篇博文主要分析contacts，后续会分析contactsProvider。
联系人模块主要记录用户的联系人数据，方便用户快捷的操作和使用，主要包括本机联系人和Sim卡联系人。
本机联系人主要存储在手机内部存储空间，平台上是通过数据库进行存储，使用ContentProvider组件封装，提供复杂的字段用于表示联系人数据，并提供用户快捷的操作，比如增加，删除，修改，查询等等。
Sim卡联系人主要存储在Sim卡内部存储文件，包括adn、fdn、sdn。主要提供简单的字段用于表示联系人数据。并通过IccProvider提供的接口进行数据的增加、删除、修改、查询操作。
联系人Contacts应用主要包括3个部分：
1. Contacts主要响应用户的请求和交互，数据显示。
2. ContactsProvider继承自Android四大组件之一的ContentProvider组件，封装了对底层数据库contact2.db的添删改查。
3. SQLite在底层物理性地存储了联系人数据。
主要交互流程如下图：
Contacts模块的主要7块功能：
3.1，联系人数据的显示：
1，联系人列表显示：
简要说明：
* PeopleActivity类负责联系人列表的显示。
* PeopleActivity包含4个Fragment，每个Fragment包含一个ListView。
* 各个Fragment中ListView的Adapter（BaseAdapter的子类）负责将数据填充到ListView。
* 各个Fragment的Loader类（CursorLoader的子类）负责加载数据。
* 实现LoadertManager接口负责管理这些CursorLoader。
为什么使用Loader？
1. Loaders确保所有的cursor操作是异步的，从而排除了UI线程中堵塞的可能性。
2. 当通过LoaderManager来管理，Loaders还可以在activity实例中保持当前的cursor数据，也就是不需要重新查询（比如，当因为横竖屏切换需要重新启动activity时）。
3. 当数据改变时，Loaders可以自动检测底层数据的更新和重新检索。
数据加载流程概览：
流程具体分析：
先上图：
进入Contacts应用，程序的主入口Activity是。
进入方法：
此方法创建视图和Fragments，进入此方法：
发现创建了3个Fragment，分别是 收藏联系人列表、所有联系人列表、群组列表。
进入：
发现的祖父类是：
首先分析此基类：
发现此基类实现了接口，实现了该接口3个重要的抽象方法：
该类同时提供了重要的抽象方法：
这意味着,子类可以按需求创造自己的适配器Adapter类,完成各个子界面Listview的数据显示，如3.1节图1所示。
然后回到类：
在执行之前，会执行父类的一些方法，顺序如下：
中设置当前的实现类。
加载联系人列表数据的过程中，这个类是。
之后执行方法。
进入的方法：
发现在这里创建了：
可以知道创建的ListAdapter类型是
并返回到类。
执行完方法之后，
执行的方法。
进入的方法：
首先获取了ListView用以填充联系人数据，然后设置了适配器，但是此时适配器中的数据是空的，直到后面才会加载数据更新uI。
在方法执行完之后，在uI可见之前回调执行的方法。
进入的方法：
首先注册了一个的子类监听数据变化。
然后执行方法，目测这应当就是开始加载数据的方法了！
进入的方法：
这个类持有一个对象，用来存储数据。
持有的，类代表了当前需要加载的，可以理解为一个联系人集合，比如说本地联系人、Google联系人……这里我们假设只加载本地联系人数据，所以partitionCount=1。
从这里我们可以做出猜测：
联系人数据不是想象中的分页（每次N条联系人数据）加载，也不是说一次性全部加载，而是一个账户一个账户加载联系人数据，加载完毕一个账户就在uI刷新并显示数据。
进入的方法：
进入此方法：
这个方法是实现类的方法，参照文档解释：
这个方法会新建/重启一个当前LoaderManager中的Loader，将回调方法注册给他，并开始加载数据。也就是说会回调LoaderManager的onCreateLoader()方法。
StartsWPS office电脑版下载的地方的方法 a new or restarts an existing android.content.Loader in this manager, registers the callbacks to it, and (if the activity/fragment is currently started) starts loading it
进入LoadManager接口的实现类：LoaderManagerImpl 的restartLoader方法内部：
进入的方法，位于的祖父类中：
发现在此方法中，首先调用方法创建了。
然后通过方法配置的方法的查询参数，也就是配置SQL中select查询语句的参数。
这也同时意味着，类的子类们可以重写方法以提供适合自身的，重写方法为配置合适的参数，适配各种自定义的查询获取数据。
观察方法在类中实现：
直接返回了的数据加载器：
这就是的实现类（数据加载器）。
然后再看一下类是如何加载数据的呢？
发现它继承自，而又继承自
在关键的方法中：
异步调用了的方法：
通过这个方法，实现了对联系人数据的查询,返回数据。并绑定了数据监听器。
那么问题来了
的这些参数那里指定的呢？
方法在类中实现，实现了对参数的配置：
可以看到，配置了主要的几个参数：，，，。
这些参数用于最后和交互的方法方法中……
最终查询的是：
发现的服务类似一个网站，就是网址，而请求数据的方式类似使用方式获取数据。
最后通过构建的查询语句是这样的：
可以发现最后通过实现的查询，并不是直接查询相关的表（表、表，表……），而是直接查询视图，因为这样会有更加高的效率。
这也就意味着如果想给联系人数据库新增一个字段供界面使用，仅修改对应的表结构是不行，还要修改对应的视图才能得到想要的效果。
查询完毕后，回调的方法，完成对Ui界面的更新：
接着进入方法：
进入这个方法：
发现在这里改变了的数据集，并发出通知数据已经改变，UI进行更新。
至此，默认联系人数据的显示分析到此结束。
其他的数据填充基本仍然类似此流程，所不同的只是各自的、、以及配置的参数（uri，projection,selection,args,order……）有所不同。
可以参考下表：
FragmentAdapterCursorLoaderDefaultContactBrowseListFragment(默认联系人列表)DefaultContactListAdapterProfileAndContactsLoaderContactTitleListFragment(收藏联系人列表)ContactTileAdapterContactTileLoaderFactory StarredLoaderContactTitleFrequentFragment(常用联系人列表)ContactTitleAdapterContactTileLoaderFactoryFrequentLoader GroupBrowseListFragment(群组列表)GroupBrowseLIstAdapterGroupListLoaderGroupDetailFragment(指定ID群组的联系人列表)GroupMemberTileAdapterGroupMemberLoaderContactDetailFragment(指定ID联系人信息)ViewAdapterContactLoader
2，联系人详细信息数据的显示：
关键类：
原理类似列表显示，如下简要说明：
* 类创建了一个实现接口的对象，数据类型指定为。负责创建、管理。
* 得到当前用户选择的联系人，配置对应的。
* 后台数据查询分完毕后，回调的方法，并将数据以的数据类型返回，然后回调的方法。
* 方法中，新开一个线程，通过类的设置数据，刷新。
3.2，联系人数据的编辑和存储：
1，编辑界面相关：
联系人数据所属的账号不同，加载的UI也是不同的，比如Sim卡联系人一般只有name，phone num，但是本地账号联系人可能就会有email，address，website等信息……
联系人数据UI的加载是通过代码动态加载的，而不是xml文件写死的。
那么问题来了，
新建联系人的界面是如何设计？
先进入新建联系人界面：
主界面中点击新建联系人Button，触发方法中的
分支：
执行
startActivity启动Intent，Intent的Action设置为
找到匹配此Action的Activity：
的布局文件：
的方法中找到布局：
在xml文件中找到这个布局：
只包含一个Fragment：。程序解析Xml文件到这里就会执行类。
进入的方法：
找到：
于是确认的根布局就是一个id为的LinearLayout。
想到上一步的语句：
所以关键就在于，接下来在代码中为这个线性布局动态添加地了什么UI，而这些UI才是真正显示的东西。
的方法执行完毕之后，会调用方法：
上面代码首先取出了当前Account信息，数据信息。封装为一个对象，作为方法的参数。之前我们分析过，编辑界面和账户是高度相关的，所以对UI的动态操作必然和Account对象相关。进入方法。
看一下中的到底对界面干了什么！！
方法中调用了:
关键代码：
发现暂时还是没有对界面做什么事情，任然处于酝酿阶段……
首先使用传入的Accout对象创建一个对象，然后使用对象构建了一个对象，接着就将对象放入 对象中。
类：raw contacts数据表内的一条数据，表示一个联系人某一特定帐户的信息。存储Data表中一些数据行（电话号码、Email、地址……）的集合及一些其他的信息。
他的存储结构为：
类：包含对象（即一个联系人某一特定帐户的信息），并具有记录修改的功能。
类：内部的存储结构是，可以理解为 单个联系人所有账户的数据集合。
然后调用了法。
关键代码如下：
可以看到，这个LinearLayout添加的View是editor，而editor是一个自定义的视图，布局是。
找到布局，发现该布局包含新建联系人页面所有的UI：
那么问题来了：中间的那部分布局（电话、地址……）去哪儿了？
搜索有可能包含这些内容的线性布局，发现在类中初始化为：
那么只需要看代码中对mFields添加了什么uI！
回到之前的方法， 对象从xml中解析完成后，执行了方法：
进入类，找到方法：
手机账户下的类型如下：
the mimeType isvnd.android.cursor.item/name
the mimeType is#displayName
the mimeType is#phoneticName
the mimeType isvnd.android.cursor.item/photo
the mimeType isvnd.android.cursor.item/phone_v2
the mimeType isvnd.android.cursor.item/email_v2
the mimeType isvnd.android.cursor.item/postal-address_v2
the mimeType isvnd.android.cursor.item/nickname
the mimeType isvnd.android.cursor.item/organization
the mimeType isvnd.android.cursor.item/note
the mimeType isvnd.android.cursor.item/im
the mimeType isvnd.android.cursor.item/sip_address
the mimeType isvnd.android.cursor.item/group_membership
the mimeType isvnd.android.cursor.item/website
发现遍历了当前账号类型中所有可能的数据类型（DataKind），
创建了相关的自定义视图对象，
再将对象添加到中显示，
这个正是之前在类中初始化的线性布局：
到这里，基本可以确定，中间部分（也就是除了Name、Photo 和底部的添加字段Button之外的部分），就是通过这个动态的根据当前账户类型添加编辑的条目来填充的。
首先观察一下的布局文件：
加载完xml文件之后，会执行方法：
把Xml文件中三个主要的部分 wps的的官网最新的下载的地址是多少都得到了，接下来重点就是观察代码中对他们做了什么。
在第12步中，加载完xml文件之后，执行的方法：
将对象传递给了类的方法：
进入类的方法：
先进行局部变量的赋值。
然后进入到方法：
在这个方法中，对集合中所有Mime类型的集合（类型）进行遍历，而后将每一个 对象
作为参数调用了也就是创建各个种类的方法，根据对象创建相应的！
简单说，就是创建中存在的类型的。
当然……这还都只是猜测，需要进入方法确认。
进入方法：
第13步初始化的对象（也就是那个被猜测应该是放的线性布局）在这里被使用！
联系上下文，实际上此时对象是类的对象，进入的方法，看看他是如何根据对象创建的：
注释基本解释了如何通过一个（理解为键值对集合）对象创建布局中的所有。
至此，联系人编辑界面的显示原理基本分析完成。
2，数据存储相关
对联系人数据的操作基本流程：
WPS office官网最新的下载的入口
以新增联系人为例：
基本流程图如下：
总结这个流程：
1. 展开编辑界面视图，同时创建相应的RawContactDeltaList对象mState。
2. 将用户输入的联系人信息实时地保存到mState对象中。
3. 用户点击保存按钮，在服务中启动新线程，根据mState中的对象构建ContentProviderOperation数组（理解为构建Sql语句）。
4. 将ContentProviderOperation数组交给ContentResolver处理（理解为执行Sql语句），操作数据库。
代码详细逻辑分析：
第一步，从界面封装数据： 对象
1. 联系人编辑界面，输入完毕后点击Save按钮，触发类的方法：重要代码如下：
可以看到存储新建联系人是通过的方法开始的，重要的是其中第二个参数是 对象，显然这是从的各个控件返回到的数据，那问题就是这个是如何组织数据的呢？？？？
wps office的免费版的下载网站是什么
首先应该搞清楚这个是什么类的对象。
是类的对象，先分析一下这个类是什么数据结构：
类：内部的存储结构是，可以理解为 单个联系人所有账户的数据集合。
类：包含对象（即一个联系人某一特定帐户的信息）。
类：数据表内的一条数据。存储Data表中一些数据行的集合及一些其他的信息，表示一个联系人某一特定帐户的信息。
所以他的存储结构为：
：类似的键值对数据结构，是一个。用来存储data表的数据，key为类型。
从联系人编辑界面开始：
在Fragment可见之前会执行方法：
方法内调用：
进入此方法：
发现他遍历了集合
将每一个对象作为参数传入类的方法。
实际上如果只是保存单个账户的联系人信息，这里内的对象只会有一个。
进入类的此方法：
可以发现，首先遍历了当前用户账户所有的可能条目种类，
然后又将对象传递给了类的方法：
先进行局部变量的赋值，然后进入到方法：
在这个方法中，又对集合中所有类型的集合（类型）进行遍历，而后将每一个 对象作为参数调用了(也就是创建各个种类的EditText)方法，根据entry对象创建相应的！
进入方法：
联系上下文，实际上此时对象是类，进入的方法，看看他是如何根据entry对象创建EditText的：
注释基本解释了如何通过一个（理解为HashMap）对象entry创建布局中的所有。
：
Ui中每一个绑定了监听器，当EditTest内容发生改变时回调方法：进入此方法：
的方法：
发现这个方法将中用户输入的字符串实时地放到这个以当前 为key的键值对中。
回顾到第5步中：类中的for循环遍历操作：是集合的一个对象，因此也就是说：当用户编辑的同时，也改变了集合。
以上，就是的中第二个关键参数对象的由来。
第二步，将数据封装为数组，并提交：
这个对象很重要，因为当用户点击保存Button时，
就会启动的方法，开始保存联系人的操作：
1， 进入此方法：
第二个参数就是上文中分析的，可以看到放到了Intent中传递，key是EXTRA_CONTENT_VALUES，后面会通过Intent传递这个对象（已经实现parcelable接口）。
2， 完成上述操作之后，在中会调用启动：
此Service继承自，在单独的Thread执行联系人的添删改查(耗时)操作。
在启动之后，在中对Intent的action进行匹配：
3， 可以发现对存储联系人匹配的分支调用了的方法：
4， 首先取出Intent中传递过来的，执行构造数组。
那么这段程序的的迷惑之处在于数组是怎么通过一个
对象构建的？
5， 进入的方法：
在for循环中遍历了this对象，也就是对象，取出了其中所有的对象，如果只是保存到一个账户，这里的对象只会有一个。
然后调用，是一个空对象，并且此时是空对象。
6， 进入的方法：
有两层for循环，完成了对数组的构建。
外层的循环对象包含了被保存的联系人所有的数据，本身的数据结构是，
此时的数据类似这样：
可以观察到，的key是类型，value是对应的值组成的。
7， 最终在内层循环调用了的方法，参数：
这里用到了的内部类，那类是什么？
简单说来就是为数组的构建提供服务的。
一个对象构建的基本流程就是这样的：
* 创建builder对象
* 按照ContentValues构建Builder的参数
* 最后调用的方法返回一个对象！
Builder简介：
Used to add parameters to a ContentProviderOperation. The Builder is first created by calling ContentProviderOperation.newInsert(android.net.Uri),
ContentProviderOperation.newUpdate(android.net.Uri),
ContentProviderOperation.newDelete(android.net.Uri)
or ContentProviderOperation.newAssertQuery(Uri).
The withXXX methods can then be used to add parameters to the builder. See the specific methods to find for which Builder type each is allowed. Call build to create the ContentProviderOperation once all the parameters have been supplied.
8， 然后看方法体内执行：
可以看到执行了的静态方法：，完成了对的创建，然后使用完成了对添加的参数。
9， 方法返回后回到第六步：
发现构建对象并在其中配置参数之后，马上执行了方法。
10， 进入方法：
经过以上分析，
经过层层遍历，完成了数组的构造，
这时候构建完毕的数组是类似这样的：
11， 程序返回到第3步
最初的类：
回到方法，将构造完毕数组作为参数，调了用的
提交修改……
基本流程就是到这里就OK了，接下去就是与数据库的操作了。
与ContactsProvider2、数据库的交互
1， 之后深入Contacts的数据操作层：
然后追溯的方法：
2， 根据参数，可以知道方法返回的是，所以之后调用了的方法：
3， 调用了父类中的方法：
4， 发现最终执行了方法：
我们执行的新增联系人操作，也就是Insert操作。
5， 因此进入Insert分支，调用了的方法：
6， 追踪到方法：
实现了对URI的匹配，确定执行对哪个数据库的进行插入操作，如果uri是对Data表的操作：
7， 最后方法实现了对底层数据库的直接操作：
至此，一个联系人的插入操作分析完毕。
添删改查操作的基本流程都类似。
值得注意的是删除联系人并不是真正的删除联系人数据。
用户在联系人列表选择联系人的删除，本地联系人url匹配只是删除表中的数据，标记表的字段为1，而表的数据并没有发生变化。url匹配删除Sim卡联系人或者同步联系人时删除，会直接删除表的数据，并触发触发器，将表，表，表的数据全部删除。
当用户进入到联系人编辑界面，删除某个数据。也就是只对联系人的data数据进行删除，而联系人数据未发生变化，这样会根据删除内容获得数组。最后会调用函数进行数据更新。
调用函数过程中，会读取数组，而数组的每一条记录都会带有一个URI，通过匹配，找到对应的表进行删除操作。操作成功后得到返回结果。
最后根据类型数据，获得不同的，进行数据的删除。
3.3，Sim联系人数据的整合
实时获得Sim卡的状态，对Sim上的联系人导入到本地数据库，或者将本地数据中Sim卡联系人删除。数据库Contacts表和raw_Contacts表表 wps电脑版下载的地址在哪里中有字段indicate_phone_or_sim_contact表示是否为Sim卡联系人，并区分出Sim1，Sim2上的联系人。
Mtk平台中实现了开机自动导入SIm卡联系人数据的功能。
1，Sim卡联系人数据的显示：
由类负责显示Sim卡中的联系人数据,并与用户交互。负责与Sim卡交互,继承自，而继承自。
如何交互Sim卡数据？
这里主要是简单应用层的操作，屏蔽了sim卡内部复杂的操作。
使用一个继承自的类封装了异步查询操作：
AsyncHandler类的定义
说明：A helper class to help make handling asynchronous ContentResolver queries easier.
ContentResolver异步查询操作的帮助类，其实它同样可以处理增删改。
AsyncQueryHandler的作用
查询其API便可知，它担供：
这四个操作，并提供相对应的方法，以供操作完数据库后进行其它的操作，这四个 方法都是抽象方法，可以在子类中实现想要的操作，在本例中是使用QueryHandler类实现了这几个方法，查询完毕后将数据填充到中。
为什么要使用AsyncQueryHandler
当然也可以使用ContentProvider去操作数据库。这在数据量很小的时候是没有问题的，但是如果数据量大了，可能导致ＵＩ线程发生ANR事件。当然你也可以写个Handler去做这些操作，只是你每次使用ContentProvider时都要再写个Handler，必然降低了效率。
因此API提供了一个操作数据库的通用方法。
如何使用AsyncQueryHandler
指定需要查询的数据的URI，与ContentResolver的query方法中的参数并无太大区别。
本例中查询Sim卡联系人数据的的uri是:
然后调用查询方法：
2，开机自动导入Sim卡联系人：
先上流程图：
具体分析：
1. 注册一个检测开机广播事件，被触发之后启动。
2. 继承组件，主要实例化了对象，注册了监听器。接受到发送过来的处理之后，调用的方法。
3. 的方法根据传递过来的，在方法中创建相应的，比如、、、。可以观察到有导入SIm卡数据、移除Sim卡数据、编辑Sim卡数据、删除Sim卡数据。
4. 本次操作为导入SIm卡联系人，所以创建的Processor为，发现其基类为，实现了接口，因此类可以理解为的，其方法是线程执行体。
5. 的方法实现了什么功能？首先调用的方法，指定为SIm卡联系人数据的，并进行查询操作（通过匹配可以得知这里调用的其实是类），得到联系人数据游标对象。这一步完成了Sim卡联系人数据的读取。
6. 然后再执行方法，构建数组，通过的方法批量提交对的操作，也就是对数据库的操作，。这一步完成了Sim卡联系人数据写入到Sqlite。
7. 那么，这个线程池是什么时候启动的呢？在第三步的方法之后，将创建的添加到，监听器会执行方法执行被添加的其内部机制在线程池中执行类。
3，telephony中IccProvider浅析：
预备知识：
Sim卡中存储的号码的类型：
ADN: Abbreviated dialing number, 就是常规的用户号码，用户可以存储/删除。
FDN：Fixed dialer number，固定拨号，固定拨号功能让您设置话机的使用限制，当您开启固定拨号功能后，您只可以拨打存储的固定拨号列表中的号码。固定号码表存放在SIM卡中。能否使用固定拨号功能取决于SIM卡类型以及网络商是否提供此功能。
SDN：Service dialing number，系统拨叫号码，网络服务拨号，固化的用户不能编辑。
从以上的描述，可以看到，一般情况下访问SIM卡联系人数据就是访问ADN。
时序图：
上述第二节，第五步执行的方法时，根据可以得知匹配的是：
在的方法中，会执行方法。
在中，要先得到一个对象：
发现这个对象是用AIDL接口来获取到的，
那么 究竟获取了一个什么实体对象呢？
先不着急找到这个实体对象，
发现程序之后在中调用的实体类的方法：
这是通过AIDL接口实现的方法调用，最终是调用到了实体类的方法.
那么可以知道，这个实体类首先必然存在方法，这个实体类的对象是通过来获取的，那么找到的地方就可以发现它了。
全局搜索后，发现类符合需求：在他的构造函数中执行了方法，而且存在方法，
wps官网下载的网址是多少(金山wps官网手机版下载安装)
判断类就是上文中的实体类。
类继承了，
在它的构造函数中执行了方法：
方法传入参数为当前类的对象，
因此，在
是获得的就是类的对象。
那么在前面第3步提到的类中方法实际就调用到了类的方法。
在方法中，执行：
看到这个方法名就可以知道，这个方法是获取Sim卡内Adn类型联系人数据的方法。
类中实现了方法
在方法中，执行：
是类的对象
7. ：
在类中实现了方法，
中，执行：
这里实例化一个类的对象，并且调用该对象的方法
进入
在类中实现了方法，
在方法中，执行：
是类的对象，实际上是它的子类的对象，继承关系是：继承自继承自
9. 进入
在类中实现了方法，
在方法中，执行：
联系上下文，是类的对象，是的缩写,即无线接口通信层。
之后涉及的东西比较底层……以后再慢慢分析……
经过与底层数据的交互，
可以在类的方法返回得到Sim卡Adn联系人数据数据。返回的方法:
发现遍历了中的数据，放到对象中，最后返回这个对象，也就是返回给了最初调用的方法返回的对象。
4，Sim卡联系人的手动导入导出：
导入的基本流程与开机导入Sim卡联系人类似，同样是先query得到SIM卡联系人数据，然后写入联系人数据库，不再做分析。
导出流程就是反过来……
华为的需求：手机联系人详情界面增加一个导出到卡1/卡2/Exchange账户的optionMenu。
具体做的时候完全可以走SIm卡联系人导入导出的流程，只需要指定导入导出数据的uri即可。
3.4，SD卡备份/恢复联系人
SD卡导入导出主要是通过vCard的形式，存储到sd卡或者从sd卡读取指定的vCard文件并进行解析。
1，从Sd卡恢复/import联系人数据
从Sd卡导入联系人主要流程：wps官网最新的下载地方是什么
1. 联系人主界面响应选项菜单的事件。
2. 弹出Import/Export对话框中选择Import，启动导入界面.
3. 最终通过启动服务。
4. 启动来进行将Vcard文件从外部Sd卡复制到手机内部存储，然后构建数组，该数组封装了被导入Vcard文件的信息。
5. 通过调用 的通知导入VCard。
6. 启动线程，通过实现的一个Vcard文件解析类类，第4步构建的数组作为参数，依次导入VCard中的每个联系人（方法)。
7. 在处理导入的过程中，会把过程状态通知给，后者负责更新通知状态栏中的信息。
visio时序图如下：
2，联系人数据导出到Sd卡
联系人导出到Sd卡与导入流程类似，略。
3.5，联系人搜索：
在Contacts应用内搜索联系人， 主要步骤：
1. 在主界面点击联系人搜索按钮，触发方法。
2. 调用来启动异步更新数据。
3. 在的回调接口创建、配置，包括查询的等，此阶段配置的uri参数为。
4. 启动后调用的方法，
匹配的uri为的分支。
5. 在的方法中拼接Sql语句，并调用Sqlite的底层语句查询。
6. 完成查询后回调的刷新UI。
visio时序图如下：
搜索tan字符串的时候，sql语句为：
发现其实最后经过sqlite语句的拼接，查询的是视图。
android联系人的搜索机制如下：
当新建了一个联系人的时候，例如名字为：【abcd】，那么会在raw_contacts表的对应数据中的display_name显示【abcd】，同时在insert的时候会在name_lookup表中存储进去一个normallized_name字段，这个字段是根据名字【abcd】转换成的16进制码，使用的方法是NameNormalize.normalize()方法。
在查询的时候使用的是ContactsProvider2里面的query方法，当输入查询条件时【a】，会使用NameNormalize.normalize()方法将【a】转换成16进制码，然后再进入name_lookup中去查询对应的raw_contacts_id,从而对应出contact显示在界面上。
也就是说，google 的查询并不是根据display_name来进行的，而是通过转换的normallized_name来进行匹配查询，在NameNormalizer.文件中定义了normalize方法，这个方法是进行转换的方法，对于数字和字母，做了直接转换的处
理，对于一些特殊字符做了特别的处理，举例如下：
如果输入的是【,】【.】那么google会将这种字符当作分隔符，即输入【a,b,c.d】的话，名字就是【a,b,c.d】，在处理这个名字的时候首先按照【,】【.】来进行分割，分割成【a】【b】【c】【d】后再转换成lookup条件，那么此时在查询的时候输入了【a】，匹配到【a,b,c.d】，再输入【,】时，系统会认为输入的是分隔符，那么会认为用户想要查询结果的基础上再次进行查询，也就是常说的在搜索结果中继续查询，所以此时再输入【a】的时候系统就会认为是在上一次的结果中（【a,b,c.d】）再此查询【a】，那么还是可以匹配到【a,b,c.d】，所以造成了下面的现象：
1.输入【a,a】/【a,c】/【d,d】/…..
2.查询出结果【a,b,c.d】.
而对于一些其他的特殊字符(非数字，非字符)，如【@】【_】等等，在转换的时候会自动将这些字符过滤掉，但却保留了分割的特性，即
出现了如下的现象：
1.保存联系人名称为【first@second#three】
2.输入条件【firstsecond】,结果为：【first@second#three】
3.输入条件【three,second】,结果为：【first@second#three】（因为保留的分割特性）
4.输入条件【first@se】,无结果（因为转换时去掉了字符@）
上述即为google default对于查询的机制，关于转换的代码可以在NameNormalizer.java中进行分析。
3.6，Google联系人同步
通过添加Google帐号，并开启同步，则会将Gmail中联系人同步到本地数据库，也可以将本地联系人同步到Gmail中。而且也支持Exchange服务帐号同步。
3.7，其他零碎功能：
1，联系人分享
关键类：
：联系人详细信息显示界面。
：被包含于Aty中的Fragment。
：控制布局，填充数据。
* 在联系人详细信息界面，选择分享。
* 得到当前联系人的uri
* 设置Intent属性、携带指定联系的uri：
创建Intent选择器：蓝牙/email/Nfc/其他应用……
跳转到用户选择的分享联系人方式的应用（蓝牙/Nfc/Email/其他应用……），联系人数据通过intent传递。
2，桌面快捷方式和文件夹
3，联系人字符分组、字母表导航效果实现机制：
关键问题：需要知道联系人名字的首字母。
把中文转换为拼音字符，这样就可以实现排序，按照字母导航的效果。
发现在表中：
发现Android已经在Sqlite中自动实现了 汉字-拼音 转换功能，直接读取这个列的数据就可以。
1，得到联系人数据，并按照排序，通过listview显示。
2，用户拖动滑动块时显示字母提示框（A_Z）。
上面的实现都比较简单，问题是sort_key是如何自动生成的？
在下，负责将汉字转化为拼音
4，联系人侧边栏字母导航条如何实现？
Android L中contact应用是没有侧边栏的，但是字母导航的数据仍然是可以读到，我们只需要搞个自定义控件，画出A-Z的字母导航条，并监测触摸事件，在Contacts中的中点击的字母位置就可以。
至此contacts应用层的分析基本结束，后面会再写数据层contactsProvider2的分析。
官网wps 的最新的下载网址是什么
