深入理解Android Instant Run运行机制.doc

深入理解Android Instant Run运行机制 Instant Run Instant Run，是Android studio2.0新增的一个运行机制，在你编码开发、测试或debug的时候，它都能显著减少你对当前应用的构建和部署的时间。通俗的解释就是，当你在Android Studio中改了你的代码，Instant Run可以很快的让你看到你修改的效果。而在没有Instant Run之前，你的一个小小的修改，都肯能需要几十秒甚至更长的等待才能看到修改后的效果。 传统的代码修改及编译部署流程 传统的代码修改及编译流程如下：构建整个apk → 部署app → app重启 → 重启Activity Instant Run编译和部署流程 Instant Run构建项目的流程：构建修改的部分 → 部署修改的dex或资源 → 热部署，温部署，冷部署 热拔插，温拔插，冷拔插 热拔插：代码改变被应用、投射到APP上，不需要重启应用，不需要重建当前activity。 场景：适用于多数的简单改变（包括一些方法实现的修改，或者变量值修改） **温拔插：**activity需要被重启才能看到所需更改。 场景：典型的情况是代码修改涉及到了资源文件，即resources。 **冷拔插：**app需要被重启（但是仍然不需要重新安装） 场景：任何涉及结构性变化的，比如：修改了继承规则、修改了方法签名等。 首次运行Instant Run，Gradle执行过程 一个新的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所需要的。这同样能确保该应用正处在前台。 热拔插 Android Studio monitors： 运行着Gradle任务来生成增量.dex文件（这个dex文件是对应着开发中的修改类） Android Studio会提取这些.dex文件发送到App Server，然后部署到App App Server会不断监听是否需要重写类文件，如果需要，任务会被立马执行。新的更改便能立即被响应。我们可以通过打断点的方式来查看。 温拔插 温拔插需要重启Activity，因为资源文件是在Activity创建时加载，所以必须重启Activity来重载资源文件。 目前来说，任何资源文件的修改都会导致重新打包再发送到APP。但是，google的开发团队正在致力于开发一个增量包，这个增量包只会包装修改过的资源文件并能部署到当前APP上。 所以温拔插实际上只能应对少数的情况，它并不能应付应用在架构、结构上的变化。 注：温拔插涉及到的资源文件修改，在manifest上是无效的（这里的无效是指不会启动Instant Run），因为，manifest的值是在APK安装的时候被读取，所以想要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一些注意点 Instant Run是被Android Studio控制的。所以我们只能通过IDE来启动它，如果通过设备来启动应用，Instant Run会出现异常情况。在使用Instant Run来启动Android app的时候，应注意以下几点： 如果应用的minSdkVersion小