各种集合,各种点

说出ArrayList,Vector, LinkedList的存储性能和特性

ArrayList和Vector都是使用数组方式存储数据，此数组元素数大于实际存储的数据以便增加和插入元素，

它们都允许直接按序号索引元素，但是插入元素要涉及数组元素移动等内存操作，所以索引数据快而插入

数据慢，Vector由于使用了synchronized方法（线程安全），通常性能上较ArrayList差，而LinkedList

使用双向链表实现存储，按序号索引数据需要进行前向或后向遍历，但是插入数据时只需要记录本项的前

后项即可，所以插入速度较快。

HashMap和Hashtable的区别。

    HashMap是Hashtable的轻量级实现（非线程安全的实现），他们都完成了Map接口，主要区别在于HashMap允许空（null）键值（key）,由于非线程安全，效率上可能高于Hashtable。

HashMap允许将null作为一个entry的key或者value，而Hashtable不允许。

HashMap把Hashtable的contains方法去掉了，改成containsvalue和containsKey。因为contains方法容易让人引起误解。

Hashtable继承自Dictionary类，而HashMap是Java1.2引进的Map interface的一个实现。

最大的不同是，Hashtable的方法是Synchronize的，而HashMap不是，在多个线程访问Hashtable时，不需要自己为它的方法实现同步，而HashMap 就必须为之提供外同步。

Hashtable和HashMap采用的hash/rehash算法都大概一样，所以性能不会有很大的差异。

List, Set, Map是否继承自Collection接口?

List，Set是，Map不是

Set里的元素是不能重复的，那么用什么方法来区分重复与否呢? 是用==还是equals()? 它们有何区别?

Set里的元素是不能重复的，那么用iterator()方法来区分重复与否。equals()是判读两个Set是否相等。

equals()和==方法决定引用值是否指向同一对象equals()在类中被覆盖，为的是当两个分离的对象的内容和类型相配的话，返回真值。

你所知道的集合类都有哪些？主要方法？

最常用的集合类是 List 和 Map。 List 的具体实现包括 ArrayList 和 Vector，它们是可变大小的列表，比较适合构建、存储和操作任何类型对象的元素列表。 List 适用于按数值索引访问元素的情形。

Map 提供了一个更通用的元素存储方法。 Map 集合类用于存储元素对（称作"键"和"值"），其中每个键映射到一个值。

 

请介绍下ContentProvider是如何实现数据共享的。

在Android 应用程序之间数据共享—-ContentResolver中，已经说明了Android

是如何实现应用程序之间数据共享的，并详细解析了如何获取其他应用程序共享

的数据。ContentProviders存储和检索数据，通过它可以让所有的应用程序访问

到，这也是应用程序之间唯一共享数据的方法。那么如何将应用程序的数据暴露

出去？

通过以前文章的学习，知道ContentResolver是通过ContentProvider来获取其他

与应用程序共享的数据，那么ContentResolver与ContentProvider的接口应该差

不多的。

其中ContentProvider负责

•组织应用程序的数据；

•向其他应用程序提供数据；

ContentResolver则负责

•获取ContentProvider提供的数据；

•修改/添加/删除更新数据等；

ContentProvider 是如何向外界提供数据的？

Android提供了ContentProvider，一个程序可以通过实现一个ContentProvider

的抽象接口将自己的数据完全暴露出去，而且ContentProviders是以类似数据库

中表的方式将数据暴露，也就是说ContentProvider就像一个“数据库”。那么

外界获取其提供的数据，也就应该与从数据库中获取数据的操作基本一样，只不

过是采用URI来表示外界需要访问的“数据库”。至于如何从URI中识别出外界需

要的是哪个“数据库”，这就是Android底层需要做的事情了，不在此详细说。

简要分析下ContentProvider向外界提供数据操作的接口：

query(Uri, String[], String, String[], String)

insert(Uri, ContentValues)

update(Uri, ContentValues, String, String[])

delete(Uri, String, String[])

这些操作与数据库的操作基本上完全一样，在此不详细说，具体的解析可以参考

Android Sqlite解析篇中的详细说明。需要特殊说明的地方是URI：

在URI的D部分可能包含一个_ID ，这个应该出现在SQL语句中的，可以以种特殊

的方式出现，这就要求我们在提供数据的时候，需要来额外关注这个特殊的信息

。Android SDK推荐的方法是：在提供数据表字段中包含一个ID，在创建表时

INTEGER PRIMARY KEY AUTOINCREMENT标识此ID字段。

ContentProvider 是如何组织数据的？

组织数据主要包括：存储数据，读取数据，以数据库的方式暴露数据。数据的存

储需要根据设计的需求，选择合适的存储结构，首选数据库，当然也可以选择本

地其他文件，甚至可以是网络上的数据。数据的读取，以数据库的方式暴露数据

这就要求，无论数据是如何存储的，数据最后必须以数据的方式访问。

可能还有2个问题，是需要关注的。

1.ContentProvider是什么时候创建的，是谁创建的？访问某个应用程序共享的

数据，是否需要启动这个应用程序？这个问题在 Android SDK中没有明确说明，

但是从数据共享的角度出发，ContentProvider应该是Android在系统启动时就创

建了，否则就谈不上数据共享了。这就要求在AndroidManifest.XML中使用

<provider>元素明确定义。

2.可能会有多个程序同时通过ContentResolver访问一个ContentProvider，会不

会导致像数据库那样的“脏数据”？这个问题一方面需要数据库访问的同步，尤

其是数据写入的同步，在AndroidManifest.XML中定义ContentProvider的时候，

需要考虑是<provider>元素multiprocess属性的值；另外一方面Android在

ContentResolver中提供了 notifyChange()接口，在数据改变时会通知其他

ContentObserver，这个地方应该使用了观察者模式，在 ContentResolver中应

该有一些类似register，unregister的接口。

至此，已经对ContentProvider提供了比较全面的分析，至于如何创建

ContentProvider，可通过2种方法：创建一个属于你自己的ContentProvider或

者将你的数据添加到一个已经存在的ContentProvider中，当然前提是有相同数

据类型并且有写入 Content provider的权限。在Android SDK的sample中提供的

Notepad具体实例中去看源代码！

 

 

四：ContentProvider
1、ContentProvider简介
当应用继承ContentProvider类，并重写该类用于提供数据和存储数据的方法，就可以向其他应用共享其数据。虽然使用其他方法也可以对外共享数据，但数据访问方式会因数据存储的方式而不同，如：采用文件方式对外共享数据，需要进行文件操作读写数据；采用sharedpreferences共享数据，需要使用sharedpreferences API读写数据。而使用ContentProvider共享数据的好处是统一了数据访问方式。
2、Uri类简介
Uri代表了要操作的数据，Uri主要包含了两部分信息：1.需要操作的ContentProvider ，2.对ContentProvider中的什么数据进行操作，一个Uri由以下几部分组成：
1.scheme：ContentProvider（内容提供者）的scheme已经由Android所规定为：content://…
2.主机名（或Authority）：用于唯一标识这个ContentProvider，外部调用者可以根据这个标识来找到它。
3.路径（path）：可以用来表示我们要操作的数据，路径的构建应根据业务而定，如下：
要操作contact表中id为10的记录，可以构建这样的路径:/contact/10
要操作contact表中id为10的记录的name字段， contact/10/name
要操作contact表中的所有记录，可以构建这样的路径:/contact?
要操作的数据不一定来自数据库，也可以是文件等他存储方式，如下:
要操作xml文件中contact节点下的name节点，可以构建这样的路径：/contact/name
如果要把一个字符串转换成Uri，可以使用Uri类中的parse()方法，如下：
Uri uri = Uri.parse("content://com.changcheng.provider.contactprovider/contact")
3、UriMatcher、ContentUrist和ContentResolver简介
因为Uri代表了要操作的数据，所以我们很经常需要解析Uri，并从 Uri中获取数据。Android系统提供了两个用于操作Uri的工具类，分别为UriMatcher 和ContentUris 。掌握它们的使用，会便于我们的开发工作。
UriMatcher：用于匹配Uri，它的用法如下：

1.首先把你需要匹配Uri路径全部给注册上，如下：
//常量UriMatcher.NO_MATCH表示不匹配任何路径的返回码(-1)。
UriMatcher uriMatcher = new UriMatcher(UriMatcher.NO_MATCH);
//如果match()方法匹配content://com.changcheng.sqlite.provider.contactprovider /contact路径，返回匹配码为1
uriMatcher.addURI(“com.changcheng.sqlite.provider.contactprovider”, “contact”, 1);//添加需要匹配uri，如果匹配就会返回匹配码
//如果match()方法匹配 content://com.changcheng.sqlite.provider.contactprovider/contact/230路径，返回匹配码为2
uriMatcher.addURI(“com.changcheng.sqlite.provider.contactprovider”, “contact/#”, 2);//#号为通配符
2.注册完需要匹配的Uri后，就可以使用uriMatcher.match(uri)方法对输入的Uri进行匹配，如果匹配就返回匹配码，匹配码是调用 addURI()方法传入的第三个参数，假设匹配 content://com.changcheng.sqlite.provider.contactprovider/contact路径，返回的匹配码为1。
ContentUris：用于获取Uri路径后面的ID部分，它有两个比较实用的方法：
withAppendedId(uri, id)用于为路径加上ID部分
parseId(uri)方法用于从路径中获取ID部分
ContentResolver：当外部应用需要对ContentProvider中的数据进行添加、删除、修改和查询操作时，可以使用 ContentResolver 类来完成，要获取ContentResolver 对象，可以使用Activity提供的getContentResolver()方法。 ContentResolver使用insert、delete、update、query方法，来操作数据。

 

什么是Affinity

在某些情况下，Android需要知道一个Activity属于哪个Task，即使它没有被启动到一个具体的Task里。这是通过任务共用性（Affinities）完成的。任务共用性（Affinities）为这个运行一个或多个Activity的Task提供了一个独特的静态名称，默认的一个活动的任务共用性（Affinity）是实现了该Activity的.apk包的名字。

 

当开始一个没有 Intent.FLAG_ACTIVITY_NEW_TASK标志的Activity时，任务共用性affinities不会影响将会运行该新活动的 Task:它总是运行在启动它的Task里。但是，如果使用了NEW_TASK标志，那么共用性（affinity）将被用来判断是否已经存在一个有相同共用性（affinity）的Task。如果是这样，这项Task将被切换到前面而新的Activity会启动于这个Task的顶层。

 

这种特性在您必须使用NEW_TASK标志的情况下最有用，尤其是从状态栏通知或桌面快捷方式启动活动时。结果是，当用户用这种方式启动您的应用程序时，它的当前Task将被切换到前台，而且想要查看的Activity被放在最上面。

 

你可以在程序清单（Manifest）文件的应用程序application标签中为.apk包中所有的活动分配你自己的任务共用性Affinites，或者在活动标记中为各个活动进行分配。

一些说明其如何使用的例子如下：

?如果您的.apk包含多个用户可以启动的高层应用程序，那么您可能需要对用户看到的每个Activity(活动)指定不同的affinities。一个不错的命名惯例是以附加一个以冒号分隔的字符串来扩展您的.apk包名。例如，“ com.android.contacts ”.apk可以有affinities:“com.android.contacts：Dialer”和“ com.android.contacts：ContactsList”。
?如果您正在替换一个通知，快捷方式，或其他可以从外部发起的应用程序的“内部”活动，你可能需要明确设定您替代活动的taskAffinity和您准备替代的应用程序一样。例如，如果您想替换contacts详细信息视图（用户可以创建并调用快捷方式），你得把taskAffinity设置成“com.android.contacts”。

 

在前面的文章“Android四种Activity的加载模式”我们提到：Activity的加载模式受启动Activity的Intent对象中设置的Flag和manifest文件中Activity的<activity>元素的特性值交互控制。

跟 Task 有关的 manifest文件中Activity的特性值介绍

android:allowTaskReparenting
    用来标记Activity能否从启动的Task移动到有着affinity的Task（当这个Task进入到前台时）

   “true”，表示能移动，“false”，表示它必须呆在启动时呆在的那个Task里。

    如果这个特性没有被设定，设定到<application>元素上的allowTaskReparenting特性的值会应用到Activity上。默认值为“false”。

    一般来说，当Activity启动后，它就与启动它的Task关联，并且在那里耗尽它的整个生命周期。当当前的Task不再显示时，你可以使用这个特性来强制Activity移动到有着affinity的Task中。典型用法是：把一个应用程序的Activity移到另一个应用程序的主Task中。
    例如，如果 email中包含一个web页的链接，点击它就会启动一个Activity来显示这个页面。这个Activity是由Browser应用程序定义的，但是，现在它作为email Task的一部分。如果它重新宿主到Browser Task里，当Browser下一次进入到前台时，它就能被看见，并且，当email Task再次进入前台时，就看不到它了。

    Actvity的affinity是由taskAffinity特性定义的。Task的affinity是通过读取根Activity的affinity 决定。因此，根Activity总是位于相同affinity的Task里。由于启动模式为“singleTask”和“singleInstance” 的Activity只能位于Task的底部，因此，重新宿主只能限于“standard”和“singleTop”模式。

android:alwaysRetainTaskState
    用来标记Activity所在的Task的状态是否总是由系统来保持。

    “true”，表示总是；“false”，表示在某种情形下允许系统恢复Task到它的初始化状态。默认值是“false”。

    这个特性只针对Task的根Activity有意义；对其它Activity来说，忽略之。
    一般来说，特定的情形如当用户从主画面重新选择这个Task时，系统会对这个Task进行清理（从stack中删除位于根Activity之上的所有Activivity）。典型的情况，当用户有一段时间没有访问这个Task时也会这么做，例如30分钟。
    然而，当这个特性设为“true”时，用户总是能回到这个Task的最新状态，无论他们是如何启动的。这非常有用，例如，像Browser应用程序，这里有很多的状态（例如多个打开的Tab），用户不想丢失这些状态。

android:clearTaskOnLaunch
    用来标记是否从Task中清除所有的Activity，除了根Activity外（每当从主画面重新启动时）

   “true”，表示总是清除至它的根Activity，“false”表示不。默认值是“false”。

    这个特性只对启动一个新的Task的Activity（根Activity）有意义；对Task中其它的Activity忽略。
    当这个值为“true”，每次用户重新启动这个Task时，都会进入到它的根Activity中，不管这个Task最后在做些什么，也不管用户是使用 BACK还是HOME离开的。当这个值为“false”时，可能会在一些情形下（参考alwaysRetainTaskState特性）清除Task的 Activity，但不总是。
    假设，某人从主画面启动了Activity P，并从那里迁移至Activity Q。接下来用户按下HOME，然后返回Activity P。一般，用户可能见到的是Activity Q，因为它是P的Task中最后工作的内容。然而，如果P设定这个特性为“true”，当用户按下HOME并使这个Task再次进入前台时，其上的所有的 Activity(在这里是Q)都将被清除。因此，当返回到这个Task时，用户只能看到P。
    如果这个特性和allowTaskReparenting都设定为“true”，那些能重新宿主的Activity会移动到共享affinity的Task中；剩下的Activity都将被抛弃，如上所述。

android:finishOnTaskLaunch
    用来标记当用户再次启动它的Task（在主画面选择这个Task）时已经存在的Activity实例是否要关闭（结束）

   “true”，表示应该关闭，“false”表示不关闭。默认值是“false”。
    如果这个特性和allowTaskReparenting都设定为“true”，这个特性胜出。Activity的affinity忽略。这个Activity不会重新宿主，但是会销毁。

android:launchMode
    用于指示Activity如何启动。这里有四种模式，与Intent对象中的Activity Flags（FLAG_ACTIVITY_*变量）共同作用，来决定Activity如何启动来处理Intent。它们是：

    "standard"
    "singleTop"
    "singleTask"
    "singleInstance"

    默认模式是“standard”。
    前面文章：“Android四种Activity的加载模式”已经详细描述,这里就不做描述了.

android:noHistory
    用于标记当用户从Activity上离开并且它在屏幕上不再可见时Activity是否从Activity stack中清除并结束（调用finish()方法）——“true”，表示它应该关闭，“false”，表示不需要。默认值是“false”。
    “true”值意味着Activity不会留下历史痕迹。因为它不会在Activity stack的Task中保留，因此，用户不能返回它。

    比如启用界面的就可以借用这个。

android:taskAffinity
   这就是本文所描述的任务共用性。

   Activity为Task拥有的一个affinity。拥有相同的affinity的Activity理论上属于相同的Task（在用户的角度是相同的“应用程序”）。Task的affinity是由它的根Activity决定的。
   affinity决定两件事情——Activity重新宿主的Task（参考allowTaskReparenting特性）和使用FLAG_ACTIVITY_NEW_TASK标志启动的Activity宿主的Task。
    默认情况，一个应用程序中的所有Activity都拥有相同的affinity。捏可以设定这个特性来重组它们，甚至可以把不同应用程序中定义的Activity放置到相同的Task中。为了明确Activity不宿主特定的Task，设定该特性为空的字符串。
    如果这个特性没有设置，Activity将从应用程序的设定那里继承下来（参考<application>元素的taskAffinity特性）。应用程序默认的affinity的名字是<manifest>元素中设定的package名。