Open alwaystest opened 7 years ago
标签（空格分隔）： Android
首先Instant Run是不会启动Proguard来做代码压缩的。
Android Plugin for Gradle V2.0 以上提供了一个叫build-in shrinker的东西来替代Proguard来做代码压缩。
build-in shrinker
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 才受支持。
如果您的项目面向旧版 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的关系:
使用build-in shrinker和Proguard压缩过代码后，移除的方法数是不一样的。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以下的手动测试？
猜测：
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方法数却不一样呢？
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
好不容易才理解他的意思，Instant Run支持应用和SdkVersion的关系:
使用
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以下的手动测试？
猜测：
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方法数却不一样呢？