instant run的目标：尽可能多的剔除不必要的步骤，然后提升必要步骤的速度。
在实践中，这意味着：
- 只对代码改变部分做构建和部署
- 不重新安装应用
- 不重启应用
- 不重启activity
场景：适用于多数的简单改变（包括一些方法实现的修改，或者变量值修改）
温拔插：activity需要被重启才能看到所需更改。
场景：典型的情况是代码修改涉及到了资源文件，即resources。
冷拔插：app需要被重启（但是仍然不需要重新安装）
场景：任何涉及结构性变化的，比如：修改了继承规则、修改了方法签名等
2.3 Instant Run运行原理
在有Instant Run的环境下：一个新的App Server类会被注入到App中，与Bytecode instrumentation协同监控代码的变化。
同时会有一个新的Application类，它注入了一个自定义类加载器（Class Loader）,同时该Application类会启动我们所需的新注入的App Server。于是，Manifest会被修改来确保我们的应用能使用这个新的Application类。（这里不必担心自己继承定义了Application类，Instant Run添加的这个新Application类会代理我们自定义的Application类）
至此，Instant Run已经可以跑起来了，在我们使用的时候，它会通过决策，合理运用冷温热拔插来协助我们大量地缩短构建程序的时间。
在Instant Run运行之前，Android Studio会检查是否能连接到App Server中。并且确保这个App Server是Android Studio所需要的。这同样能确保该应用正处在前台，因为目前是不支持多台设备多程序同时执行。
2.5 热拔插
因为原来版本的类都装载在运行中的程序了，Gradle已经Transfrom了“Update”版本（Gradle修改class的原理，请戳Transfrom-API），以便它们有效地覆盖那些预先存在的类。然后，App Server使用自定义类加载器加载这些已转换的更新类。看看下面原理图：
目前来说，任何资源文件的修改都会导致重新打包再发送到APP。但是，google的开发团队正在致力于开发一个增量包，这个增量包只会包装修改过的资源文件并能部署到当前APP上。
注意：温拔插涉及到的资源文件修改，在manifest上是无效的（这里的无效是指不会启动Instant Run），因为，manifest的值是在APK安装的时候被读取，所以想要manifest下资源的修改生效，还需要触发一个完整的应用构建和部署。总结起来：如果你修改了manifest相关的资源文件，还是需要面临和以前一样的龟速构建。
应用部署的时候，会把工程拆分成十个部分，每部分都拥有自己的.dex文件，然后所有的类会根据包名被分配给相应的.dex文件。当冷拔插开启时，修改过的类所对应的.dex文件，会重组生成新的.dex文件，然后再部署到设备上。
之所以能这么做，是依赖于Android的ART模式，它能允许加载多个.dex文件。ART模式在android4.4（API-19）中加入，但是Dalvik依然是首选，到了android5.0（API-21），ART模式才成为系统默认首选，所以Instant Run只能运行在API-21及其以上版本，至于低版本的话，会重新构建整个应用（下文会提及低版本解决思路）
Instant Run是被Android Studio控制的。所以我们只能通过IDE来启动它，如果通过设备来启动应用，Instant Run会出现异常情况。
更多的技巧，请点这里，然而多数是没什么用，不需要记住的。
- 如果应用的minSdkVersion小于21，可能多数的Instant Run功能会挂掉，这里提供一个解决方法，通过product flavor建立一个minSdkVersion大于21的新分支，用来debug。
- Instant Run目前只能在主进程里运行，如果应用是多进程的，类似微信，把webView抽出来单独一个进程，那热、温拔插会被降级为冷拔插。
- 在Windows下，Windows Defender Real-Time Protection可能会导致Instant Run挂掉，可用通过添加白名单列表解决，具体操作自行Google
- 暂时不支持Jack compiler，Instrumentation Tests，或者同时部署到多台设备。
- 设置：Instant Run是默认开启的。设置路径：Preferences -> Build,Execution,Deployment -> Instant Run
- 使用：和往常一模一样，只是你会发觉速度飙升，变快了。
