Instant Run 和代码压缩

[alwaystest]

Instant Run 和代码压缩

标签（空格分隔）： Android

---

首先Instant Run是不会启动Proguard来做代码压缩的。

Android Plugin for Gradle V2.0 以上提供了一个叫build-in shrinker的东西来替代Proguard来做代码压缩。

build-in shrinker 是可以与Instant Run来协同合作压缩代码量（方法数）的。

https://developer.android.com/studio/run/index.html

如果您的项目面向旧版 Dalvik 可执行文件分包（即，使用 multiDexEnabled true 和 minSdkVersion 20 或更低版本配置 build.gradle）配置并且您将其部署到运行 Android 4.4（API 级别 20）或更低版本系统的目标设备上，Android Studio 会停用 Instant Run。

使用 Android Plugin for Gradle 版本 2.0.0 或更高版本，以及在应用的模块级别 build.gradle 文件中将 minSdkVersion 设置为 15 或以上时，Instant Run 才受支持。

好不容易才理解他的意思，Instant Run支持应用和SdkVersion的关系:

1. minSdkVersion >= 15 && multiDexEnabled == false
2. minSdkVersion >= 21 (multiDexEnabled默认已经是True了)

使用build-in shrinker和Proguard压缩过代码后，移除的方法数是不一样的。Proguard会多移除一些方法。

Instant Run不单单指热更Application，增量编译也算Instant Run，比如Android4.4以下的Instant Run表现为部署完整的APK，也就是重装。但是第一次编译之后，后面的编译还是很快的。

Android5.0以上的系统可以不必考虑64K问题。 Android5.0以下启用Instant Run，可以使用build-in shrinker来暂缓64K问题的到来。 如果Android5.0以下使用build-in shrinker，优化过混淆规则，依然64K，要么使用Android5.0以上的设备调试，使用Proguard发布。要么关闭Instant Run，使用Proguard压缩代码。 如果Proguard都压制不了64K，最后再开启MultiDex。 实在不行的话，学学苹果，抛弃5.0以下的用户。促使用户更新设备，实现GDP保6稳5，优化Android生态环境。

当然，我观摩过支付宝的APK，是使用了MultiDex的。不知道这种情况是怎么进行5.0以下的手动测试？

猜测：

• 测试全部自动化。不需要人工介入，所以不需要考虑Instant Run能不能节省时间。
• 开发调试使用5.0以上的设备。开启Instant Run加速，或者使用别的增量编译的Plugin，提高编译速度。
• 5.0以下的设备兼容性全部依赖自动化测试。如果出了问题，再单独调试对应的设备。

~~build->build APK 运行的是assembleXXX，使用Proguard压缩代码。而Run在assembleXXX之前还运行了几个命令，使用Instant Run的话使用build-in shrinker压缩代码。gradle还没时间仔细研究，不知道哪里指定了Instant Run和代码压缩器。~~

build->build APK 生成的APK的方法数要比直接Run生成的APK方法数少，不知道原因，又看了一下outputs文件夹，buildType指定了使用build-in shrinker的话，build APK没有生成mapping文件夹，所以这里也是用的build-in shrinker？但是为什么Run和build APK生成的APK方法数却不一样呢？