之前使用的是Gradle中定义productFlavors进行多渠道打包，其实在最开始接触的时候就知道有极速打包这个方案，只不过当时项目中有Tinker,抓紧上线就没使用，趁工作间隙研究研究发现，这根本就是两种方案，而且真的是很快，并且Tinker也不用那么麻烦。
packer-ng-plugin
目前所了解的最快的打包方案，并且Tinker也鼓励使用这种方式，github主页上介绍100个渠道包只用10秒，github地址在这里，官方的接入说明已经很详细了，这里就不过多说一些都知道的东西，说一些我在接入过程中遇到的小问题。
- markets.txt的位置：如果是放在Project根目录下，就是和setting.gradle平级的话，那么对应的就是
java -Pmarket=markets.txt,如果是在Module的目录下，就是和Module的build.gradle平级的话，那么对应的就是java -Pmarket={module名}/markets.txt。 - 打包的Gradle命令：官方介绍的是：
java ./gradlew -Pmarket=markets.txt clean apkRelease
但是我在使用的时候发现，根本不好使，我是直接使用的Studio中的Terminal，并且也是在Project目录下，之后自己尝试后发现，可以将java ./gradlew改为java gradle,之后再次尝试编译，发现报错，说build中的AndroidManifest.xml文件不能删除，之后将clean去掉之后再运行，成功在Project的build中找到对应的渠道包。如果要更改渠道包生成的名，可以看官方说明。 - Tinker:在Tinker的多渠道打包中指明了，可以使用这种方式，并且这种方式比productFlavors更加适合tinker,因为并没有改变代码文件。所以不用根据每一个渠道包去生成对应的补丁包，其实每一个渠道包的代码是一样的。
- 不要忘记在signingConfig的release中配置
v2SigningEnabled false，至于怎么判断是否需要写这句，百度。结论
- 亲测，Tinker加packer-ng-plugin是可以的，并且没有改变渠道信息。
- 亲测，速度确实快好多。
- 为什么，比如同样有100个渠道，之前的那种方式，会重复打100个包，编译期改变Manifest中的渠道信息，之后重新打包。现在的方式是将markets.txt中的文件写到zip文件中，相当于打一个包，复制一下，改其中一个文件，重复一百次，本质上是打一个包，而之前的是打100个包，这就是问什么会快的原因。
