Android的构成基石————四大组件

Activity

Activity在应用中的表现就是一个用户界面，加载指定的布局文件来展示各种UI。应用启动时会加载一个默认的Activity，这个Activity在AndroidManifest.xml中会被设置为如下intent-filter：

<intent-filter>      <action android:name="android.intent.action.MAIN'/>      <category android:name="android.intent.category.LAUNCHER"/></intent-filter>

提到Activity不得不说生命周期

• onCreate() 在Activity第一次被创建时调用，通常会在这个函数中完成初始化操作，如设置布局，初始化视图，绑定事件等
• onStart()这个函数在Activity的onCreate()函数之后被调用，此时Activity还处在不可见状态，它的下一个状态就是Activity变得可见的时候，也就是这个函数在Activity可见之前被调用
• onResume() 这个函数在Activity()变为可见的时候调用，执行完onResume()之后,Activity就会请求AMS渲染它所管理的视图。此时Activity一定位于返回栈的栈顶，并且处于运行状态
• onPause() 这个函数在系统准备去启动或者恢复另一个Activity时调用，也就是Activity即将从可见状态变为不可见时。通常会在这个函数中将一些消耗CPU的资源释放掉，以及保存一些关键数据
• onStop() 这个函数在Activity完全不可见的时候调用。它和onPause()函数的主要区别是，如果新启动的Activity是一个对话框式的Activity，那么onPause()函数会得到执行，而onStop()函数并不会执行
• onDestroy() 这个函数是在Activity被销毁之前调用，之后Activity的状态变为销毁状态
• onRestart() 这个函数是由停止状态重新变为运行状态之前调用，也就是Activity被重新启动了

当Activity被意外终止时，系统会调用onSaveInstanceState来保存当前Activity的状态。这个动作在onStop()方法之前，和onPause()方法没有前后时序之分。需要强调一点，这个方法只有在意外终止时调用，正常状态下不会。当Activity重新创建后系统会调用onRestoreInstanceState，并且把Activity销毁时onSaveInstanceState方法所保存的Bundle对象作为参数同时传递给onRestoreInstanceState和onCreate方法

Activity的四种启动模式

每个应用程序都是由一个或者多个Activity组成，因此，Android内部使用通过回退栈来管理Activity实例。栈是先进后出的集合，对于Android来说，当前显示的Activity就在栈顶，当用户点击后退键或者点击应用上的返回按钮，系统就会将栈顶的Activity出栈，此时原来栈顶下的Activity就会变为栈顶显示到设备上。用户可以在AndroidManifext.xml注册Activity时设置它的启动模式，例如：

<activity         android:name=".MyActivity"         android:launchMode="singleTask"         android:lable="@string/app_name"</activity>

• standard模式
  这是Activity的标准启动模式，也是Activity的默认启动模式。这种模式下启动的Activity可以多次实例化，即在同一个任务栈可以存在多个Activity实例，每个实例都会处理一个Intent对象。
• singleTop模式
  如果一个以singleTop模式启动的Activity的实例已经存于栈顶，那么当再启动这个Activity时，不会去创建新实例。如果不在栈顶，就会去创建一个新实例压入栈顶。
• singletask
  singleTask模式是常用的启动模式，如果一个Activity设置了该启动模式，那么在一个任务栈中只能有一个该Activity实例。如果任务栈中没有该Activity，会创建一个实例压入栈顶。如果已经存在并且不在栈顶，那么系统就会销毁处在该Activity上的所有Activity，让该Activity处在栈顶，同时回调该Activity的onNewIntent()函数。
• singleInstance
  设置了singleInstance模式的Activity会在一个独立的任务中开启，并且这个新的任务中有且只有这一个实例，也就是说被该实力启动的其他Activity会自动运行于另一个任务中。当再次启动该实例时，会重用已存在的任务和实例。并且会调用该实例的onNewIntent()函数，将Intent实例传递到该实例中。

Service

Service是Android中实现程序后台运行的解决方案，Service默认并不会运行在子线程，它也不运行在一个独立的进程中，它同样执行在UI线程中，因此，不要在Service中执行耗时的操作，除非在Service中创建了子线程完成耗时操作。Service的运行不依赖于任何用户界面，即使程序被切换到后台或者用户打开了另外一个应用程序，Service依然能够正常运行。当某个应用程序进程被杀掉了，所有依赖于该进程的Service也会停止

Service的生命周期相对于Activity来说简单的多，只有3个，分别为onCreate、onStartCommand和onDestroy。一旦在项目的任何位置调用了Context的startService()函数，相应服务就会起来，首次创建是会调用onCreate函数，然后回调onStartCommand，服务启动之后一直保持运行，直到调用stopService()和stopSelf()函数。虽然每调用一次startService函数，onStartCommand就会执行一次，但是每个服务只会存在一个实例。当然Service和Activity一样都需要在AndroidManifest.xml中注册

IntentService

IntentService将用户的请求执行在一个子线程中，用户只需要覆写onHandleIntent函数，并且在该函数中完成自己的耗时任务，值得一提的是在任务执行完毕之后IntentService会调用stopSelf自我销毁，因此，它适用于完成一些短期的耗时任务。

运行在前台的Service

Service默认是运行在后台的，因此它的优先级比较低，当系统内存不足的时候容易被回收。为此，我们可以将Service运行在前台

Broadcast

Broadcast是一种广泛运用的、在应用程序之间传输信息的机制，Android中的广播与传统意义上的广播类似，一个广播可以有任意个接收者。广播机制是一个典型的发布-订阅模式，也就是观察者模式。广播机制的最大特点就是发送方并不关心接收方是否接到数据，也不关心接收方如何处理数据，通过这样的形式来达到接、收双方的完全解耦合。

普通广播

普通广播完全是异步的，通过Context的sendBroadcast()函数来发送，消息传递的效率比较高，并且所有receivers的执行顺序不确定。缺点是：接收者不能讲处理结果传递给下一个接收者，并且无法终止广播Intent的传播，直到没有与之匹配的广播接收器为止。
我们需要先注册一个广播接收器，如下：

public class NewBroadcastReceiver extends BroadcastReceiver{      @Override      public void onReceive(Context context, Intent intent){          Log.d("TAG","hello world");      }}

第二步是注册广播，分为两种注册形式，一种是静态注册，形式与Activity和Service类似。动态注册的示例如下：

private void registerNewBroadcast(){      registerRecceiver(new NewBroadcastReceiver(),new IntentFilter(HELLO_ACTION));}

如果是在Activity或者Fragment中动态注册的，记得在onDestroy()中注销该广播。发送广播的代码如下：

private void sendNormalBroadcast(){     sendBroadcast(new Intent(HELLO_ACTION));}

然后就会在广播中的onReceive函数，在该函数中执行相关操作。

有序广播

有序广播通过Context.sendOrderedBroadcast()来发送，所有的广播按照优先级顺序依次执行，广播接收器的优先级通过receiver的intent-filter中的android:priority属性来设置，数值越大优先级越高。当广播接收器接收到广播后，可以使用setResult()函数来结果传给下一个广播接收器接，然后通过getResult()函数来取得上个广播接收器返回的结果，并且可以使用abortBroadcast()函数来让系统丢弃该广播，使该广播不再传送到别的广播接收器接。

本地广播

不想介绍了

sticky广播

不想介绍了

ContentProvider

ContentProvider在Android中的作用是对外数据共享，也就是说可以通过ContentProvider把应用中的数据共享给其他应用访问，其他应用也可以通过ContentProvider对应用中的数据进行增删改查。使用ContentProvider对外共享数据的好处是，统一了数据的访问方式，它实际上是对SQliteOpenHelper的进一步封装，通过Uri映射来判断选择需要操作数据库中的哪个表，并且进行增删改查处理。
首先要了解一下Uri，Uri代表了要操作的数据表的绝对路径，Uri主要包含了两部分，一是需要操作的ContentProvider，二是对ContentProvider中哪个数据表进行操作。Uri的格式由以下几部分组成：Schema，authority，path，id。ContentProvider的Schema已经由Android固定设置为content://,Authority用于唯一标识这个ContentProvider，外部调用者可以根据这个标识来找到它。这里的path就是要操作的数据库表，最后的id是可选字段如所有联系人的Uri：content://contacts/people,某个联系人的Uri：content：//contacts/people/5,这个5就是联系人的id。具体的例子就不多写了。