#### 1.2.1 Activity的LaunchMode
首先说一下**Activity为什么需要启动模式**。我们知道，在默认情况下，当我们多次启动同一个Activity的时候，系统会创建多个实例并把它们一一放入任务栈中，当我们单击back键，会发现这些Activity会一一回退。**任务栈是一种“后进先出”的栈结构，这个比较好理解，每按一下back键就会有一个Activity出栈，直到栈空为止，当栈中无任何Activity的时候，系统就会回收这个任务栈**。关于任务栈的系统工作原理，这里暂时不做说明，在后续章节会专门介绍任务栈。**知道了Activity的默认启动模式以后，我们可能就会发现一个问题：多次启动同一个Activity，系统重复创建多个实例，这样不是很傻吗？这样的确有点傻，Android在设计的时候不可能不考虑到这个问题，所以它提供了启动模式来修改系统的默认行为。目前有四种启动模式：standard、singleTop、singleTask和singleInstance**，下面先介绍各种启动模式的含义：
* （1）**standard：标准模式**，这也是**系统的默认模式。每次启动一个Activity都会重新创建一个新的实例，不管这个实例是否已经存在**。被创建的实例的生命周期符合典型情况下Activity的生命周期，如上节描述，它的onCreate、onStart、onResume都会被调用。这是一种典型的多实例实现，**一个任务栈中可以有多个Activity实例，每个Activity实例也可以属于不同的任务栈。在这种模式下，谁启动了这个Activity，那么这个Activity就运行在启动它的那个Activity所在的栈中。比如Activity A启动了Activity B（B是标准模式），那么B就会进入到A所在的栈中**。不知道读者是否注意到，当我们用ApplicationContext去启动standard模式的Activity的时候会报错，错误如下：
```
E/AndroidRuntime(674): android.util.AndroidRuntimeException: Calling
startActivity from outside of an Activity context requires the
FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?
```
相信这句话读者一定不陌生，这是因为**standard模式的Activity默认会进入启动它的Activity所属的任务栈中**，但是由于**非Activity类型的Context（如ApplicationContext）并没有所谓的任务栈**，所以这就有问题了。**解决这个问题的方法是为待启动Activity指定FLAG_ACTIVITY_NEW_TASK标记位（通过[使用intent标记位](https://developer.android.google.cn/guide/components/activities/tasks-and-back-stack#IntentFlagsForTasks)， `intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);`
），这样启动的时候就会为它创建一个新的任务栈，这个时候待启动Activity实际上是以singleTask模式启动的**，读者可以仔细体会。
* （2）**singleTop：栈顶复用模式**。在这种模式下，**如果新Activity已经位于任务栈的栈顶，那么此Activity不会被重新创建，同时它的onNewIntent方法会被回调，通过此方法的参数我们可以取出当前请求的信息。需要注意的是，这个Activity的onCreate、onStart不会被系统调用，因为它并没有发生改变。如果新Activity的实例已存在但不是位于栈顶，那么新Activity仍然会重新重建**。举个例子，假设目前栈内的情况为ABCD，其中ABCD为四个Activity, A位于栈底，D位于栈顶，这个时候假设要再次启动D，如果D的启动模式为singleTop，那么栈内的情况仍然为ABCD；如果D的启动模式为standard，那么由于D被重新创建，导致栈内的情况就变为ABCDD。
* （3）**singleTask：栈内复用模式**。这是一种**单实例模式**，在这种模式下，**只要Activity在一个栈中存在，那么多次启动此Activity都不会重新创建实例**，和singleTop一样，系统也会回调其onNewIntent。具体一点，**当一个具有singleTask模式的Activity请求启动后，比如Activity A，系统首先会寻找是否存在A想要的任务栈，如果不存在，就重新创建一个任务栈，然后创建A的实例后把A放到栈中。如果存在A所需的任务栈，这时要看A是否在栈中有实例存在，如果有实例存在，那么系统就会把A调到栈顶并调用它的onNewIntent方法，如果实例不存在，就创建A的实例并把A压入栈中**。举几个例子：
* 比如目前任务栈S1中的情况为ABC，这个时候Activity D以singleTask模式请求启动，其所需要的任务栈为S2，由于S2和D的实例均不存在，所以系统会先创建任务栈S2，然后再创建D的实例并将其入栈到S2。
* 另外一种情况，假设D所需的任务栈为S1，其他情况如上面例子1所示，那么由于S1已经存在，所以系统会直接创建D的实例并将其入栈到S1。
* **如果D所需的任务栈为S1，并且当前任务栈S1的情况为ADBC，根据栈内复用的原则，此时D不会重新创建，系统会把D切换到栈顶并调用其onNewIntent方法，同时由于singleTask默认具有clearTop的效果，会导致栈内所有在D上面的Activity全部出栈，于是最终S1中的情况为AD**。这一点比较特殊，在后面还会对此种情况详细地分析。
通过上述3个例子，读者应该能比较清晰地理解singleTask的含义了。
* （4）**singleInstance：单实例模式**。这是一种**加强的singleTask模式**，它除了具有singleTask模式的所有特性外，还加强了一点，那就是**具有此种模式的Activity只能单独地位于一个任务栈中，换句话说，比如Activity A是singleInstance模式，当A启动后，系统会为它创建一个新的任务栈，然后A独自在这个新的任务栈中，由于栈内复用的特性，后续的请求均不会创建新的Activity，除非这个独特的任务栈被系统销毁了**。
>[info]注意：对于一般App尽量少用singleTask和 singleInstance模式，可能会影响用户体验。
上面介绍了几种启动模式，这里需要指出一种情况，我们*假设目前有2个任务栈，前台任务栈的情况为AB，而后台任务栈的情况为CD，这里假设CD的启动模式均为singleTask。现在请求启动D，那么整个后台任务栈都会被切换到前台，这个时候整个后退列表变成了ABCD。当用户按back键的时候，列表中的Activity会一一出栈，如图1-7所示。如果不是请求启动D而是启动C，那么情况就不一样了，请看图1-8，具体原因在本节后面会再进行详细分析*。
:-: 
图1-7 任务栈示例1
:-: 
图1-8 任务栈示例2
另外一个问题是，在singleTask启动模式中，多次提到某个Activity所需的任务栈，**什么是Activity所需要的任务栈呢**？这要从一个参数说起：**TaskAffinity**，可以翻译为**任务相关性**。这个参数**标识了一个Activity所需要的任务栈的名字，默认情况下，所有Activity所需的任务栈的名字为应用的包名。当然，我们可以为每个Activity都单独指定[TaskAffinity](https://developer.android.google.cn/guide/topics/manifest/activity-element#aff)属性，这个属性值必须不能和包名相同，否则就相当于没有指定。TaskAffinity属性主要和singleTask启动模式或者allowTaskReparenting属性配对使用，在其他情况下没有意义。另外，任务栈分为前台任务栈和后台任务栈，后台任务栈中的Activity位于暂停状态，用户可以通过切换将后台任务栈再次调到前台**。
**当TaskAffinity和singleTask启动模式配对使用的时候，它是具有该模式的Activity的目前任务栈的名字，待启动的Activity会运行在名字和TaskAffinity相同的任务栈中**。
**当TaskAffinity和allowTaskReparenting结合的时候，这种情况比较复杂，会产生特殊的效果。当一个应用A启动了应用B的某个Activity后，如果这个Activity的allowTaskReparenting属性为true的话，那么当应用B被启动后，此Activity会直接从应用A的任务栈转移到应用B的任务栈中。这还是很抽象，再具体点，比如现在有2个应用A和B, A启动了B的一个Activity C，然后按Home键回到桌面，然后再单击B的桌面图标，这个时候并不是启动了B的主Activity，而是重新显示了已经被应用A启动的Activity C，或者说，C从A的任务栈转移到了B的任务栈中。可以这么理解，由于A启动了C，这个时候C只能运行在A的任务栈中，但是C属于B应用，正常情况下，它的TaskAffinity值肯定不可能和A的任务栈相同（因为包名不同）。所以，当B被启动后，B会创建自己的任务栈，这个时候系统发现C原本所想要的任务栈已经被创建了，所以就把C从A的任务栈中转移过来了**。这种情况读者可以写个例子测试一下，这里就不做示例了。
如何**给Activity指定启动模式**呢？有**两种方法**，第一种是**通过[AndroidMenifest为Activity指定](https://developer.android.google.cn/guide/components/activities/tasks-and-back-stack#ManifestForTasks)启动模式**，如下所示。
<activity
android:name="com.ryg.chapter_1.SecondActivity"
android:configChanges="screenLayout"
android:launchMode="singleTask"
android:label="@string/app_name" />
另一种情况是**通过[在Intent中设置标志位](https://developer.android.google.cn/guide/components/activities/tasks-and-back-stack#IntentFlagsForTasks)来为Activity指定启动模式**，比如：
Intent intent = new Intent();
intent.setClass(MainActivity.this, SecondActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
这两种方式都可以为Activity指定启动模式，但是二者还是有区别的。
* 首先，优先级上，第二种方式的优先级要高于第一种，当两种同时存在时，以第二种方式即[在Intent中设置标志位](https://developer.android.google.cn/guide/components/activities/tasks-and-back-stack#IntentFlagsForTasks)为准；
* 其次，上述**两种方式在限定范围上有所不同**，比如，第一种方式无法直接为Activity设定FLAG_ACTIVITY_CLEAR_TOP标识，而第二种方式无法为Activity指定singleInstance模式。
关于Intent中为Activity指定的各种标记位，在下面的小节中会继续介绍。下面通过一个例子来体验启动模式的使用效果。还是前面的例子，这里我们**把MainActivity的启动模式设为singleTask，然后重复启动它，看看是否会重复创建**，代码修改如下：
<activity
android:name="com.ryg.chapter_1.MainActivity"
android:configChanges="orientation|screenSize"
android:label="@string/app_name"
android:launchMode="singleTask" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
@Override
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
Log.d(TAG, "onNewIntent, time=" + intent.getLongExtra("time", 0));
}
findViewById(R.id.button1).setOnClickListener(new OnClickListener() {
@Override
public void onClick(View v) {
Intent intent = new Intent();
intent.setClass(MainActivity.this, MainActivity.class);
intent.putExtra("time", System.currentTimeMillis());
startActivity(intent);
}
});
根据上述修改，我们做如下操作，连续单击三次按钮启动3次MainActivity，算上原本的MainActvity的实例，正常情况下，任务栈中应该有4个MainActivity的实例，但是我们为其指定了singleTask模式，现在来看一看到底有何不同。
执行`adb shell dumpsys activity`命令：
ACTIVITY MANAGER ACTIVITIES (dumpsys activity activities)
Main stack:
TaskRecord{41350dc8 #9 A com.ryg.chapter_1}
Intent { cmp=com.ryg.chapter_1/.MainActivity (has extras) }
Hist #1: ActivityRecord{412cc188 com.ryg.chapter_1/.MainActivity}
Intent { act=android.intent.action.MAIN cat=[android.intent.
category.LAUNCHER] flg=0x
0 cmp=com.ryg.chapter_1/.MainActivity bnds=[160,235][240,335] }
ProcessRecord{411e6898634:com.ryg.chapter_1/10052}
TaskRecord{4125abc8 #2 A com.android.launcher}
Intent { act=android.intent.action.MAIN cat=[android.intent.category.
HOME] flg=0x10000000
m.android.launcher/com.android.launcher2.Launcher }
Hist #0: ActivityRecord{412381f8 com.android.launcher/com.android.
launcher2.Launcher}
Intent { act=android.intent.action.MAIN cat=[android.intent.
category.HOME] flg=0x1000
p=com.android.launcher/com.android.launcher2.Launcher }
ProcessRecord{411d24c8214:com.android.launcher/10013}
Running activities (most recent first):
TaskRecord{41350dc8 #9 A com.ryg.chapter_1}
Run #1: ActivityRecord{412cc188 com.ryg.chapter_1/.MainActivity}
TaskRecord{4125abc8 #2 A com.android.launcher}
Run #0: ActivityRecord{412381f8 com.android.launcher/com.android.
launcher2.Launcher}
mResumedActivity: ActivityRecord{412cc188 com.ryg.chapter_1/.MainActivity}
mFocusedActivity: ActivityRecord{412cc188 com.ryg.chapter_1/.MainActivity}
Recent tasks:
＊ Recent #0: TaskRecord{41350dc8 #9 A com.ryg.chapter_1}
＊ Recent #1: TaskRecord{4125abc8 #2 A com.android.launcher}
＊ Recent #2: TaskRecord{412b60a0 #5 A com.estrongs.android.pop.app.
InstallMonitorActivity}
从上面导出的Activity信息可以看出，**尽管启动了4次MainActivity，但是它始终只有一个实例在任务栈中．从图1-9的log可以看出，Activity的确没有重新创建，只是暂停了一下，然后调用了onNewIntent，接着调用onResume就又继续了**。
:-: 
图1-9 系统日志
现在我们**去掉singleTask，再来对比一下，还是同样的操作，单击三次按钮启动MainActivity三次**。
执行`adb shell dumpsys activity`命令：
ACTIVITY MANAGER ACTIVITIES (dumpsys activity activities)
Main stack:
TaskRecord{41325370 #17 A com.ryg.chapter_1}
Intent { act=android.intent.action.MAIN cat=[android.intent.category.
LAUNCHER] flg=0x100000
p=com.ryg.chapter_1/.MainActivity }
Hist #4: ActivityRecord{41236968 com.ryg.chapter_1/.MainActivity}
Intent { cmp=com.ryg.chapter_1/.MainActivity (has extras) }
ProcessRecord{411e6898803:com.ryg.chapter_1/10052}
Hist #3: ActivityRecord{411f4b30 com.ryg.chapter_1/.MainActivity}
Intent { cmp=com.ryg.chapter_1/.MainActivity (has extras) }
ProcessRecord{411e6898803:com.ryg.chapter_1/10052}
Hist #2: ActivityRecord{411edcb8 com.ryg.chapter_1/.MainActivity}
Intent { cmp=com.ryg.chapter_1/.MainActivity (has extras) }
ProcessRecord{411e6898803:com.ryg.chapter_1/10052}
Hist #1: ActivityRecord{411e7588 com.ryg.chapter_1/.MainActivity}
Intent { act=android.intent.action.MAIN cat=[android.intent.category.
LAUNCHER] flg=0x10
0 cmp=com.ryg.chapter_1/.MainActivity }
ProcessRecord{411e6898803:com.ryg.chapter_1/10052}
TaskRecord{4125abc8 #2 A com.android.launcher}
Intent { act=android.intent.action.MAIN cat=[android.intent.category.
HOME] flg=0x10000000 c
m.android.launcher/com.android.launcher2.Launcher }
Hist #0: ActivityRecord{412381f8 com.android.launcher/com.android.
launcher2.Launcher}
Intent { act=android.intent.action.MAIN cat=[android.intent.cate-
gory.HOME] flg=0x100000
p=com.android.launcher/com.android.launcher2.Launcher }
ProcessRecord{411d24c8214:com.android.launcher/10013}
Running activities (most recent first):
TaskRecord{41325370 #17 A com.ryg.chapter_1}
Run #4: ActivityRecord{41236968 com.ryg.chapter_1/.MainActivity}
Run #3: ActivityRecord{411f4b30 com.ryg.chapter_1/.MainActivity}
Run #2: ActivityRecord{411edcb8 com.ryg.chapter_1/.MainActivity}
Run #1: ActivityRecord{411e7588 com.ryg.chapter_1/.MainActivity}
TaskRecord{4125abc8 #2 A com.android.launcher}
Run #0: ActivityRecord{412381f8 com.android.launcher/com.android.
launcher2.Launcher}
mResumedActivity: ActivityRecord{41236968 com.ryg.chapter_1/.MainAc-
tivity}
mFocusedActivity: ActivityRecord{41236968 com.ryg.chapter_1/.MainAc-
tivity}
Recent tasks:
＊ Recent #0: TaskRecord{41325370 #17 A com.ryg.chapter_1}
＊ Recent #1: TaskRecord{4125abc8 #2 A com.android.launcher}
＊ Recent #2: TaskRecord{412c8d58 #16 A com.estrongs.android.pop.app.
InstallMonitorActivity}
上面的导出信息很多，我们可以有选择地看，比如就看Running activities (most recent first)这一块，如下所示。
Running activities (most recent first):
TaskRecord{41325370 #17 A com.ryg.chapter_1}
Run #4: ActivityRecord{41236968 com.ryg.chapter_1/.MainActivity}
Run #3: ActivityRecord{411f4b30 com.ryg.chapter_1/.MainActivity}
Run #2: ActivityRecord{411edcb8 com.ryg.chapter_1/.MainActivity}
Run #1: ActivityRecord{411e7588 com.ryg.chapter_1/.MainActivity}
TaskRecord{4125abc8 #2 A com.android.launcher}
Run #0: ActivityRecord{412381f8 com.android.launcher/com.android.
launcher2.Launcher}
我们能够得出**目前总共有2个任务栈，前台任务栈的taskAffinity值为com.ryg. chapter_1，它里面有4个Activity，后台任务栈的taskAffinity值为com.android.launcher，它里面有1个Activity，这个Activity就是桌面**。通过这种方式来分析任务栈信息就清晰多了。
:-: 
图1-7 任务栈示例1
从上面的导出信息中可以看到，在任务栈中有4个MainActivity，这也就验证了Activity的启动模式的工作方式。
上述四种启动模式，standard和singleTop都比较好理解，singleInstance由于其特殊性也好理解，但是关于singleTask有一种情况需要再说明一下。如图1-7所示，**如果在Activity B中请求的不是D而是C，那么情况如何呢？这里可以告诉读者的是，任务栈列表变成了ABC，是不是很奇怪呢？Activity D被直接出栈了**。下面我们再用实例验证看看是不是这样。首先，还是使用上面的代码，但是我们做一下修改：
<activity
android:name="com.ryg.chapter_1.MainActivity"
android:configChanges="orientation|screenSize"
android:label="@string/app_name"
android:launchMode="standard" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name="com.ryg.chapter_1.SecondActivity"
android:configChanges="screenLayout"
android:label="@string/app_name"
android:taskAffinity="com.ryg.task1"
android:launchMode="singleTask" />
<activity
android:name="com.ryg.chapter_1.ThirdActivity"
android:configChanges="screenLayout"
android:taskAffinity="com.ryg.task1"
android:label="@string/app_name"
android:launchMode="singleTask" />
我们将SecondActivity和ThirdActivity都设成singleTask并指定它们的taskAffinity属性为“com.ryg.task1”，**注意这个taskAffinity属性的值为字符串，且中间必须含有包名分隔符“.”**。然后做如下操作，*在MainActivity中单击按钮启动SecondActivity，在SecondActivity中单击按钮启动ThirdActivity，在ThirdActivity中单击按钮又启动MainActivity，最后再在MainActivity中单击按钮启动SecondActivity，**然后再按2次back键**，然后看到的是哪个Activity？答案是回到桌面*。是不是有点摸不到头脑了？没关系，接下来我们分析这个问题。
*首先，从理论上分析这个问题，先假设MainActivity为A, SecondActivity为B，ThirdActivity为C。我们知道A为standard模式，按照规定，A的taskAffinity值继承自Application的taskAffinity，而Application默认taskAffinity为包名，所以A的taskAffinity为包名。由于我们在XML中为B和C指定了taskAffinity和启动模式，所以B和C是singleTask模式且有相同的taskAffinity值“com.ryg.task1”。A启动B的时候，按照singleTask的规则，这个时候需要为B重新创建一个任务栈“com.ryg.task1”。B再启动C，按照singleTask的规则，由于C所需的任务栈（和B为同一任务栈）已经被B创建，所以无须再创建新的任务栈，这个时候系统只是创建C的实例后将C入栈了。接着C再启动A, A是standard模式，所以系统会为它创建一个新的实例并将到加到启动它的那个Activity的任务栈，由于是C启动了A，所以A会进入C的任务栈中并位于栈顶。这个时候已经有两个任务栈了，一个是名字为包名的任务栈，里面只有A，另一个是名字为“com.ryg.task1”的任务栈，里面的Activity为BCA。接下来，A再启动B，由于B是singleTask, B需要回到任务栈的栈顶，由于栈的工作模式为“后进先出”, B想要回到栈顶，只能是CA出栈。所以，到这里就很好理解了，如果再按back键，B就出栈了，B所在的任务栈已经不存在了，这个时候只能是回到后台任务栈并把A显示出来。注意这个A是后台任务栈的A，不是“com.ryg.task1”任务栈的A，接着再继续back，就回到桌面了*。分析到这里，我们得出一条结论，**singleTask模式的Activity切换到栈顶会导致在它之上的栈内的Activity出栈**。
接着我们在实践中再次验证这个问题，还是采用dumpsys命令。我们省略中间的过程，直接看C启动A的那个状态，执行`adb shell dumpsys activity`命令，日志如下：
Running activities (most recent first):
TaskRecord{4132bd90 #12 A com.ryg.task1}
Run #4: ActivityRecord{4133fd18 com.ryg.chapter_1/.MainActivity}
Run #3: ActivityRecord{41349c58 com.ryg.chapter_1/.ThirdActivity}
Run #2: ActivityRecord{4132bab0 com.ryg.chapter_1/.SecondActivity}
TaskRecord{4125a008 #11 A com.ryg.chapter_1}
Run #1: ActivityRecord{41328c60 com.ryg.chapter_1/.MainActivity}
TaskRecord{41256440 #2 A com.android.launcher}
Run #0: ActivityRecord{41231d30 com.android.launcher/com.android.launch
er2.Launcher}
可以**清楚地看到有2个任务栈，第一个（com.ryg.chapter_1）只有A，第二个（com.ryg.task1）有BCA**，就如同我们上面分析的那样，然后再从A中启动B，再看一下日志：
Running activities (most recent first):
TaskRecord{4132bd90 #12 A com.ryg.task1}
Run #2: ActivityRecord{4132bab0 com.ryg.chapter_1/.SecondActivity}
TaskRecord{4125a008 #11 A com.ryg.chapter_1}
Run #1: ActivityRecord{41328c60 com.ryg.chapter_1/.MainActivity}
TaskRecord{41256440 #2 A com.android.launcher}
Run #0: ActivityRecord{41231d30 com.android.launcher/com.android.launch
er2.Launcher}
**可以发现在任务栈`com.ryg.task1`中只剩下B了，C、A都已经出栈了，这个时候再按back键，任务栈com.ryg.chapter_1中的A就显示出来了，如果再back就回到桌面了**。分析到这里，相信读者对Activity的启动模式已经有很深入的理解了。下面介绍Activity中常用的标志位。
- 前言
- 第1章 Activity的生命周期和启动模式
- 1.1 Activity的生命周期全面分析
- 1.1.1 典型情况下的生命周期分析
- 1.1.2 异常情况下的生命周期分析
- 1.2 Activity的启动模式
- 1.2.1 Activity的LaunchMode
- 1.2.2 Activity的Flags
- 1.3 IntentFilter的匹配规则
- 第2章 IPC机制
- 2.1 Android IPC简介
- 2.2 Android中的多进程模式
- 2.2.1 开启多进程模式
- 2.2.2 多进程模式的运行机制
- 2.3 IPC基础概念介绍
- 2.3.1 Serializable接口
- 2.3.2 Parcelable接口
- 2.3.3 Binder
- 2.4 Android中的IPC方式
- 2.4.1 使用Bundle
- 2.4.2 使用文件共享
- 2.4.3 使用Messenger
- 2.4.4 使用AIDL
- 2.4.5 使用ContentProvider
- 2.4.6 使用Socket
- 2.5 Binder连接池
- 2.6 选用合适的IPC方式
- 第3章 View的事件体系
- 3.1 View基础知识
- 3.1.1 什么是View
- 3.1.2 View的位置参数
- 3.1.3 MotionEvent和TouchSlop
- 3.1.4 VelocityTracker、GestureDetector和Scroller
- 3.2 View的滑动
- 3.2.1 使用scrollTo/scrollBy
- 3.2.2 使用动画
- 3.2.3 改变布局参数
- 3.2.4 各种滑动方式的对比
- 3.3 弹性滑动
- 3.3.1 使用Scroller7
- 3.3.2 通过动画
- 3.3.3 使用延时策略
- 3.4 View的事件分发机制
- 3.4.1 点击事件的传递规则
- 3.4.2 事件分发的源码解析
- 3.5 View的滑动冲突
- 3.5.1 常见的滑动冲突场景
- 3.5.2 滑动冲突的处理规则
- 3.5.3 滑动冲突的解决方式
- 第4章 View的工作原理
- 4.1 初识ViewRoot和DecorView
- 4.2 理解MeasureSpec
- 4.2.1 MeasureSpec
- 4.2.2 MeasureSpec和LayoutParams的对应关系
- 4.3 View的工作流程
- 4.3.1 measure过程
- 4.3.2 layout过程
- 4.3.3 draw过程
- 4.4 自定义View
- 4.4.1 自定义View的分类
- 4.4.2 自定义View须知
- 4.4.3 自定义View示例
- 4.4.4 自定义View的思想
- 第5章 理解RemoteViews
- 5.1 RemoteViews的应用
- 5.1.1 RemoteViews在通知栏上的应用
- 5.1.2 RemoteViews在桌面小部件上的应用
- 5.1.3 PendingIntent概述
- 5.2 RemoteViews的内部机制
- 5.3 RemoteViews的意义
- 第6章 Android的Drawable
- 6.1 Drawable简介
- 6.2 Drawable的分类
- 6.2.1 BitmapDrawable2
- 6.2.2 ShapeDrawable
- 6.2.3 LayerDrawable
- 6.2.4 StateListDrawable
- 6.2.5 LevelListDrawable
- 6.2.6 TransitionDrawable
- 6.2.7 InsetDrawable
- 6.2.8 ScaleDrawable
- 6.2.9 ClipDrawable
- 6.3 自定义Drawable
- 第7章 Android动画深入分析
- 7.1 View动画
- 7.1.1 View动画的种类
- 7.1.2 自定义View动画
- 7.1.3 帧动画
- 7.2 View动画的特殊使用场景
- 7.2.1 LayoutAnimation
- 7.2.2 Activity的切换效果
- 7.3 属性动画
- 7.3.1 使用属性动画
- 7.3.2 理解插值器和估值器 /
- 7.3.3 属性动画的监听器
- 7.3.4 对任意属性做动画
- 7.3.5 属性动画的工作原理
- 7.4 使用动画的注意事项
- 第8章 理解Window和WindowManager
- 8.1 Window和WindowManager
- 8.2 Window的内部机制
- 8.2.1 Window的添加过程
- 8.2.2 Window的删除过程
- 8.2.3 Window的更新过程
- 8.3 Window的创建过程
- 8.3.1 Activity的Window创建过程
- 8.3.2 Dialog的Window创建过程
- 8.3.3 Toast的Window创建过程
- 第9章 四大组件的工作过程
- 9.1 四大组件的运行状态
- 9.2 Activity的工作过程
- 9.3 Service的工作过程
- 9.3.1 Service的启动过程
- 9.3.2 Service的绑定过程
- 9.4 BroadcastReceiver的工作过程
- 9.4.1 广播的注册过程
- 9.4.2 广播的发送和接收过程
- 9.5 ContentProvider的工作过程
- 第10章 Android的消息机制
- 10.1 Android的消息机制概述
- 10.2 Android的消息机制分析
- 10.2.1 ThreadLocal的工作原理
- 10.2.2 消息队列的工作原理
- 10.2.3 Looper的工作原理
- 10.2.4 Handler的工作原理
- 10.3 主线程的消息循环
- 第11章 Android的线程和线程池
- 11.1 主线程和子线程
- 11.2 Android中的线程形态
- 11.2.1 AsyncTask
- 11.2.2 AsyncTask的工作原理
- 11.2.3 HandlerThread
- 11.2.4 IntentService
- 11.3 Android中的线程池
- 11.3.1 ThreadPoolExecutor
- 11.3.2 线程池的分类
- 第12章 Bitmap的加载和Cache
- 12.1 Bitmap的高效加载
- 12.2 Android中的缓存策略
- 12.2.1 LruCache
- 12.2.2 DiskLruCache
- 12.2.3 ImageLoader的实现446
- 12.3 ImageLoader的使用
- 12.3.1 照片墙效果
- 12.3.2 优化列表的卡顿现象
- 第13章 综合技术
- 13.1 使用CrashHandler来获取应用的crash信息
- 13.2 使用multidex来解决方法数越界
- 13.3 Android的动态加载技术
- 13.4 反编译初步
- 13.4.1 使用dex2jar和jd-gui反编译apk
- 13.4.2 使用apktool对apk进行二次打包
- 第14章 JNI和NDK编程
- 14.1 JNI的开发流程
- 14.2 NDK的开发流程
- 14.3 JNI的数据类型和类型签名
- 14.4 JNI调用Java方法的流程
- 第15章 Android性能优化
- 15.1 Android的性能优化方法
- 15.1.1 布局优化
- 15.1.2 绘制优化
- 15.1.3 内存泄露优化
- 15.1.4 响应速度优化和ANR日志分析
- 15.1.5 ListView和Bitmap优化
- 15.1.6 线程优化
- 15.1.7 一些性能优化建议
- 15.2 内存泄露分析之MAT工具
- 15.3 提高程序的可维护性