笔记（十五）——四大组件与Fragment碎片

——个人平时笔记，看到的同学欢迎指正错误，文中多处摘录于各大博主与书籍精华

生命周期时间：Activity 5秒，Service 取决于系统回收杀死的时间，BoradcastReceiver 10秒，ContentProvider 注册创建即存在直到应用被卸载

1、Activity是一种展示型组件。Activity的启动由Intent触发，其中Intent可以分为显式Intent和隐式Intent，显式Intent可以明确地指向一个Activity组件，隐式Intent则指向一个或多个目标Activity组件。

activity生命周期

在需要使用Activity的Context的情况下，尽量使用ApplicationContext替代，这样可以避免Activity被回收时还被其他外部引用而导致无法回收，造成内存溢出。

Activity四种启动模式：

1.standard:标准模式，也是默认模式。每次启动一次activity都会创建一个新的activity实例，加入任务栈中。
2.singleTop:栈顶复用模式。如果要启动的新activity已经位于任务栈栈顶，则会复用该activity不会生成新的activity实例，并且会回调onNewIntent()方法
3.singleTask:栈内复用模式。如果要启动的新activity已经存在于在当前任务栈栈中，则会踢出位于它同一栈顶的其他activity，直至要启动的activity位于当前栈顶，并且会回调onNewIntent()方法
4.singleInstance:单一实例模式。它具有singleTask所有的特性。当前模式的activity只能单独的位于一个任务栈中，如果已经存在于一个任务栈中，则会复用，并且会回调onNewIntent()方法

异常状态时数据保存：
Activity的 onSaveInstanceState() 和 onRestoreInstanceState()并不是生命周期方法，它们不同于 onCreate()、onPause()等生命周期方法，它们并不一定会被触发。当应用遇到意外情况（如：内存不足、用户直接按Home键）由系统销毁一个Activity时，onSaveInstanceState() 会被调用。但是当用户主动去销毁一个Activity时，例如在应用中按返回键，onSaveInstanceState()就不会被调用。因为在这种情况下，用户的行为决定了不需要保存Activity的状态。通常onSaveInstanceState()只适合用于保存一些临时性的状态。

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

2、Service是一种计算型组件，用于在后台执行一系列计算任务。Service组件有两种状态：启动状态和绑定状态。Service的这两种启动状态是可以共存的。
启动状态时：Service组件可以在后台执行计算，但是它本身是运行在主线程中的，因此耗时的后台计算仍然需要在单独的线程中去完成。结束该Service也只需要调用一次stopService。
绑定状态时：同样也可在后台执行计算，但是处于这种状态时外界可以很方便地和Service组件进行通信。多次使用bindService绑定同一个Service时，Service的onBind方法只会执行一次，手动调用unbindService()后解绑。

Service生命周期

生命周期说明：

• onCreate()：首次创建服务时，系统将调用此方法。如果服务已在运行，则不会调用此方法，该方法只调用一次。
• onStartCommand()：当另一个组件通过调用startService()请求启动服务时，系统将调用此方法。
• onDestroy()：当服务不再使用且将被销毁时，系统将调用此方法。
• onBind()：当另一个组件通过调用bindService()与服务绑定时，系统将调用此方法。
• onUnbind()：当另一个组件通过调用unbindService()与服务解绑时，系统将调用此方法。
• onRebind()：当旧的组件与服务解绑后，另一个新的组件与服务绑定，onUnbind()返回true时，系统将调用此方法。

生命周期调用
1）startService启动Service服务
单次：startService() —> onCreate() —> onStartCommand()
多次：startService() —> onCreate() —> onStartCommand() —> onStartCommand()
2）停止Service服务
stopService() —> onDestroy()
1）bindService绑定Service服务
bindService() —> onCreate() —> onBind()
2）解绑Service服务
unbindService() —> onUnbind() —> onDestroy()
1）启动绑定Service服务
startService() —> onCreate() —> onStartCommand() —> bindService() —> onBind()
2）解绑停止Service服务
unbindService() —> onUnbind() —> stopService() —> onDestroy()
3）解绑绑定Service服务
unbindService() —> onUnbind(ture) —> bindService() —> onRebind()

3、BroadcastReceiver是一种消息型组件，用于在不同的组件乃至不同的应用之间传递消息。通过Context的一系列send方法来发送广播，发送和接收过程的匹配是通过广播接收者的来描述的。BroadcastReceive广播有两种方式注册：静态注册和动态注册。

• 静态注册是指在AndroidManifest中注册的广播，这种广播在应用安装时会被系统解析，此种形式的广播不需要应用启动就可以收到相应的广播。

• 动态注册广播需要通过Context.registerReceiver()来实现，并且在不需要的时候要通过Context.unRegisterReceiver()来解除广播，否则容易造成内存泄漏。此种形态的广播必须要应用启动才能注册并接收广播，因为应用不启动就无法注册广播，无法注册广播就无法收到相应的广播。

• 普通广播的发送
  Context类提供两个方法可以用于发送普通广播，差别是第二个设置权限：
  sendBroadcast(Intent intent);
  sendBroadcast(Intent intent, String receiverPermission);
  发给特定的用户：
  sendBroadcastAsUser(Intent intent, UserHandle user);
  sendBroadcastAsUser(Intent intent, UserHandle user, String receiverPermission);

• 有序广播的发送
  有序广播会按照处理器的不同优先级来区分的，高优先级的处理器会优先截获这个消息，并且可以将这个消息删除。
  有序广播因为要处理消息的处理结果，所以要复杂一些。
  sendOrderedBroadcast(Intent intent, String receiverPermission, BroadcastReceiver resultReceiver, Handler scheduler, int initialCode, String initialData, Bundle initialExtras);
  如果只是想让广播可以按优先级来收取，并不在意处理的结果，可以用下面的版本：
  sendOrderedBroadcast(Intent intent, String receiverPermission);
  同样，在多用户环境下，也可以选择给指定用户发广播：
  sendOrderedBroadcastAsUser(Intent intent, UserHandle user, String receiverPermission, BroadcastReceiver resultReceiver, Handler scheduler, int initialCode, String initialData, Bundle initialExtras);

• 粘性广播（安卓5.0即API 21开始废除了）
  粘性消息在发送后就一直存在于系统的消息容器里面，等待对应的处理器去处理，如果暂时没有处理器处理这个消息则一直在消息容器里面处于等待状态，粘性广播的Receiver如果被销毁，那么下次重建时会自动接收到消息数据。
  不管是普通的还是有序的广播都对应有粘性的版本：
  sendStickyBroadcast(Intent intent);
  sendStickyBroadcastAsUser(Intent intent, UserHandle user);
  sendStickyOrderedBroadcast(Intent intent, BroadcastReceiver resultReceiver, Handler scheduler, int initialCode, String initialData, Bundle initialExtras);
  sendStickyOrderedBroadcastAsUser(Intent intent, UserHandle user, BroadcastReceiver resultReceiver, Handler scheduler, int initialCode, String initialData, Bundle initialExtras);

4、ContentProvider是一种数据共享型组件，用于向其他组件乃至其他应用共享数据。它的内部实现了增删改查这四种操作，在它的内部维持着一份数据集合，这个数据集合既可以通过数据库来实现，也可以采用其他任何类型来实现，比如List和Map；ContentProvider对数据集合的具体实现并没有任何要求。需要注意的是，ContentProvider内部的insert、delete、update和query方法需要处理好线程同步，因为这几个方法是在Binder线程池中被调用的，另外ContentProvider组件也不需要手动停止。ContentProvider的onCreate要先于Application的onCreate而执行，这在四大组件中是个例外。
从数据共享的角度出发，ContentProvider应该是Android在系统启动时就创建了，否则就谈不上数据共享了。
android contentResolver的使用
ContentProvider讲解与实例应用
5、Fragment碎片的生命周期

Fragment生命周期