Activity
生命周期
注意点
Activity切换时，旧Activity的onPause会先执行，然后才会启动新的Activity。即activityA跳到activityB时执行顺序为：activityA-onPause()再 activityB-onCreate()、activityB-onStart()、activityB-onResume()，最后才是activityA-onStop()。
—— 这也是为什么不建议在onPause()做重量级操作的原因。上图为正常情况下的生命周期，异常情况下的生命周期略有不同。activity在异常情况下终止的，系统调用onSaveInstanceState()来保存当前activity状态。这个方法的时机是在onStop()之前，但和onPause()没有直接但先后关系。 当activity被重新创建后，系统会调用onRestoreInstanceState()，并把在销毁时在onSaveInstanceState()中保存的Bundle对象作为参数传递给onCreate()和onRestoreInstanceState()方法。onRestoreInstanceState()调用时机是在onStart()之后。 一般可以选择在onCreate()或onRestoreInstanceState()方法中恢复数据，两者的区别是，在onCreate()需要判断Bundle参数是否为空，在onRestoreInstanceState()中则不用，因为onRestoreInstanceState()被调用那么Bundle参数必然有值，官方建议在这里恢复。
自己保存，在重写onSaveInstanceState()方法中保存
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
outState.putString("save_data","保存数据");
}
然后在onCreate()中恢复
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if(savedInstanceState!=null){
Log.e(TAG,"onCreate恢复的数据:"+savedInstanceState.get("save_data"));
}
}
需要说明的是，系统只有在activity即将被销毁并且有机会重新显示的情况才会调用onSaveInstanceState()，也即异常终止才会调用来保存和恢复数据。
（非正常情况销毁Activity的场景比较多，比如系统内存不够用，系统语言改变，屏幕方向改变等。用户主动意愿想要销毁Activity就是正常情况，这种场景很少，就两种：调用finish和带特殊启动模式的startActivity方法，其他都是非正常情况。savedInstanceState会保存到哪些数据呢？有两种：系统帮你自动保存的和你自己保存的。系统只会保存它认为有必要保存的（比方说EditText里面的内容，CheckBox的Check状态，Fragment实例等），特别注意Activity会自动保存其中的Fragment实例。一般情况下屏幕方向改变等系统配置发送改变后，activity会被重新创建，那会就会调用上面保存恢复数据的方法。但我们也可以通过给activity指定configChange属性，使得在系统配置改变时不重新创建。例如屏幕旋转，如果不想旋屏时重新创建activity，可以在xml中设定android:configChange="orientation".这是再旋屏，activity不会再重新创建，那么onSaveInstanceState()和onRestoreInstanceState()也不会再被调用，取而代之的时调用来onConfigurationChanged(),我们可以在这里做我们的处理。
再说说onDestroy，执行到这一步，一般代表activity即将要被销毁掉，不管是正常情况还是非正常情况关闭activity。一般在这里面我们会做一些资源的释放操作，以防止出现资源泄露或者依赖activity所引发的一些异常情况的发生。这里我举两个例子来说下上面说的两种情况：
异步任务引发的资源泄露，比如handler或者thread。这种情况发生的原因主要是异步任务的生命周期与activity生命周期不同步造成的，以handler中的message为例：
Handler handler = new Handler();
handler.postDelayed(new Runnable() {
@Override
public void run() {
tvContent.setText("newContent");
}
}, 2000);
handler.obtainMessage(1).sendToTarget();
不管是使用哪种形式来发送message，message都会直接或者间接引用到当前所在的activity实例对象，如果在activity finish后，还有其相关的message在主线程的消息队列中，就会导致该activity实例对象无法被GC回收，引起内存泄露。所以一般我们需要在onDestroy阶段将handler所持有的message对象从主线程的消息队列中清除。示例如下：
@Override
protected void onDestroy() {
super.onDestroy();
if (handler != null) {
handler.removeCallbacksAndMessages(null);
}
}
异步任务引发的App运行异常，这里以一个显示Dialog的场景为例：
Handler handler = new Handler();
handler.postDelayed(new Runnable() {
@Override
public void run() {
new AlertDialog.Builder(MainActivity.this).setMessage("Show Dialog").show();
}
}, 5000);
由于我们设置的是5秒后显示一个dialog，当activity在5秒内被finish后可能会导致显示dialog时App发生崩溃。
所以在这种场景下正确的做法应该是这样的：
Handler handler = new Handler();
handler.postDelayed(new Runnable() {
@Override
public void run() {
if (!MainActivity.this.isDestroyed()) {
new AlertDialog.Builder(MainActivity.this).setMessage("Show Dialog").show();
}
}
}, 5000);
Activity启动模式
- Standard标准模式
这种启动模式最常见，也是Activity的默认启动模式，每当我们需要开启一个新的Activity页面时系统都会新建一个Activity实例对象，然后开启上面说的Activity的生命周期流程之旅，onCreate->onStart->onResume。在这种模式，谁启动了这个activity，那么这个activity就运行在启动它的那个activity所在的栈中。
（所以如果用ApplicationContext去启动这种Standard模式的activity会报错，因为非activity类型的context并没有所谓的任务栈）
- SingleTop栈顶复用模式
设置该模式后，当通过startActivity启动的ActivityA已位于当前Task栈的栈顶，系统不会重新创建一个Activity实例，而是进入一个特殊的方法onNewIntent，通过此方法的参数可以取出当前请求的信息，具体流程为：onNewIntent->onResume。即onCreate()和onStart()都不会调用，因为它并没有变化。如果ActivityA存在但不在栈顶，那么ActivityA依然会重建。
- SingleTask栈内复用模式
设置该模式可以保证当前Task栈中每种Activity只会有一个实例存在，当通过startActivity启动ActivityA时：1、如果ActivityA所需的栈不存在，则先创建ActivityA所需的任务栈，然后将实例入栈；
2、如果ActivityA所需的栈存在，但栈中不存在Activity A的实例，那么创建实例并入栈；
3、如果ActivityA所需的栈存在，并且栈中存在Activity A的实例，则不再重新创建一个新的Activity实例，而是直接复用该实例，进入该Activity的onNewIntent方法，同时将位于ActivityA实例之上的所有Activity弹出Task栈并销毁。
- SingleInstance单实例模式
设置该模式可以保证该Activity所在的Task中有且仅有一个activity实例：当通过startActivity启动Activity A时，如果该Activity的实例已经存在，那么不再重新创建一个新的Activity实例，而是直接复用该实例，进入该Activity的onNewIntent方法；当Activity A不存在，则新建任务栈并创建实例入栈。这种场景出现的比较少，该Activity在整个系统只有一个实例，一般用于系统应用，并且可以被其他应用共享使用（有点类似于操作系统概念中的临界资源），比方说来电呼叫页面，在整个系统中就只能有一个，因为同一时刻只能存在一个电话呼叫。
- 在上面多次说到activity的任务栈，那么什么是activity的任务栈呢？这要从一个参数TaskAffinity，可以翻译为任务相关性，这个参数标识来一个activity所需的任务栈的名字，默认情况为应用包名，我们也可以为每个acivity单独指定TaskAffinity。
TaskAffinity属性主要和singleTask启动模式或allowTaskReparenting属性（运行activity在栈间转移）配对使用，其他情况没什么意义。1、当和singleTask启动模式配合使用，它是具有该模式的activity的目前任务栈的名字；
2、当和allowTaskReparenting属性配合使用时，会产生特殊的效果。比如，当一个应用A启动来应用B的某个activityC，如果activityC的allowTaskReparenting设为true，那么应用B被启动后，此activity会直接从应用A的任务栈转移到B的任务栈中。（本来A启动activityC，activityC应该在A的任务栈中，但B启动后，activityC会转移到B的任务栈，因为activityC本来是属于B的）
- 如何给activity指定启动模式？
- 通过AndroidMenifest.xml中指定
<activity
android:launchMode:"singletask"
>
- 通过Intent设置标志位
Intent intent = new Intent();
intent.setClass(MainActivity.this, SecondActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
两者的区别：
1、优先级不同：第二种设置标志位的优先级高；
2、限定范围不同：第一种无法直接为activity设定FLAG_ACTIVITY_CLEAR_TOP标识，而第二中无法指定singleInstance模式。
IntentFilter 匹配规则
启动activity分两种：显式调用和隐式调用。显示调用需要明确指定被启动对象的组件信息，包括包名类名，而隐式不用。显示优先级高。隐式调用需要Intent能偶匹配目标组件的IntentFilter中所设置的action、category、data等过滤信息，不匹配无法启动。
- 只有一个Intent同时匹配action类别、category类别、data类别才算完全匹配，只有完全匹配才能成功启动目标activity。
- 一个activity中可以有多个intent-filter，一个Intent只要能匹配任何一组intent-filter即可成功启动对应的activity。
- action匹配规则
action是一个字符串，系统预定来一些action，我们也可以自定义action。action的匹配规则是Intent中的action存在且必须和过滤规则中的其中一个action相同（区分大小写）
- category匹配规则
category是一个字符串，系统预定来一些category，我们也可以自定义category。category的匹配规则是：如果Intent包含category，那个所有的category都必须和过滤规则中的其中一个category相同。
如果Intent不包含category也可以匹配，因为默认会有"android:intent.category.DEFAULT"这个category，所以为了能接收隐式调用，就要在intent-filter中指定"android:intent.category.DEFAULT"这个category。
- data匹配规则
data由两部分组成，mimeType（媒体类型）和URI（URI结构：<scheme>://<host>:<port>/[<path>|<pathPrefix>|<pathPattern>], 如content://com.example.project:200/folder/etc， ）
data的匹配规则和action类似，如果过滤规则有data，那么要求Intent中必须包含data数据，并且能够完成匹配过滤规则中的某个data。URI有默认值content和file，所以如果过滤规则没有指定URI，Intent必须指定为content或者file才能匹配
注意：如果要为Intent指定完整的data，必须用setDataAndType()方法，不能分别调用setData()和setType()，因为这两个方法会互相清除对方的值。
Activity 工作过程
- Launcher通知AMS启动APP的MainActivity，也就是清单文件设置启动的Activity。
- AMS记录要启动的Activity信息，并且通知Launcher进入pause状态。
- Launcher进入pause状态后，通知AMS已经paused了，可以启动APP了。
- app未开启过，所以AMS启动新的进程，并且在新进程中创建ActivityThread对象，执行其中的main函数方法。
- app主线程启动完毕后通知AMS，并传入applicationThread以便通讯。
- AMS通知APP绑定Application并启动MainActivity。
- 启动MainActivitiy，并且创建和关联Context,最后调用onCreate方法。
根Activity启动过程
- 1、点击桌面应用图标，Launcher进程将启动Activity（MainActivity）的请求以Binder的方式发送给了AMS。
- 2、AMS接收到启动请求后，交付ActivityStarter处理Intent和Flag等信息，然后再交给ActivityStackSupervisior/ActivityStack 处理Activity进栈相关流程。同时以Socket方式请求Zygote进程fork新进程。
- 3、Zygote接收到新进程创建请求后fork出新进程。
- 4、在新进程里创建ActivityThread对象，新创建的ActivityThread就是应用的主线程，在主线程里开启Looper消息循环，开始处理创建Activity。
- 5、ActivityThread利用ClassLoader去加载Activity、创建Activity实例，并回调Activity的onCreate()方法，这样便完成了Activity的启动。
普通Activity启动过程
普通Activity的启动过程只涉及两个进程，AMS所在进程和应用程序进程。
启动Activity B -> 当前有正在显示的activity吗 -> 有就先pause() -> B的进程存在吗 -> 不存在则创建 -> B进程启动指定的Activity
Activity跟window，view之间的关系
- ==Activity在创建时会调用 attach() 方法初始化一个PhoneWindow==(继承于Window)，每一个Activity都包含了唯一一个PhoneWindow
- ==Activity通过setContentView实际上是调用的 getWindow().setContentView将View设置到PhoneWindow上==，而PhoneWindow内部是通过 WindowManager 的addView、removeView、updateViewLayout这三个方法来管理View，WindowManager本质是接口，最终由WindowManagerImpl实现。
