转载:
初出茅庐 手动打包
怎么手动打包
项目写完了,现在需要把应用上传到市场,问题出现—怎么把代码变成.apk(Android的可安装文件)。
1. 创建签名文件2. 填写好签名参数3. 生成APK注意:签名的密码和密匙的密码注意保管,不要忘了,签名文件别泄漏了,也别搞丢了为什么要打包
我最开始就有这个疑问,我们的代码不是点了下运行按钮就直接安装到手机上了吗,我们在在项目Project目录的build/outputs/apk
目录下可以找到刚刚新鲜生成的app-debug.apk.直接把这个上传给市场不就行了吗。
渐入佳境 渠道打包
OK,我们已经解决了第一步—怎么打包。上传上去后,市场反馈发现我们的App写得太棒了,这时候老大让赶快多上些平台,主流的平台、非主流的平台都要放上去。
那么问题来了,为了方便统计各个平台的安装情况,配合运营推广,需要统计各个平台的安装情况。分渠道打包
不错,我们需要用到分渠道打包,那么我们需要解决两个问题
1. 怎么区分各个平台的标识2. 怎么每次版本更新都生成几十个包、几百个包第一个简单,用过友盟打包的同学肯定不陌生这段代码 1 | <code class = "hljs haskell" ><meta-data android:name= "UMENG_CHANNEL" android:value= "Channel_ID" ></meta-data></code> |
value里面填的就是各个平台的值,比如填写uc、yyb(应用宝)、360、baidu替换掉Channel_ID
,App安装好,可以读取这个值然后传给后台,从而实现区分各个平台的安装需求。
build.gradle
为 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | <code class = "hljs livecodeserver" >apply plugin: 'com.android.application' android { signingConfigs { config { keyAlias 'maker' keyPassword '1234make' storeFile file( '/Users/Nevermore/AndroidStudioProjects/Blog/jks/makeapp.jks' ) storePassword 'make1234' } } compileSdkVersion 23 buildToolsVersion "23.0.3" defaultConfig { applicationId "com.example.makeapp" minSdkVersion 15 targetSdkVersion 23 versionCode 1 versionName "1.0" } buildTypes { debug { minifyEnabled false debuggable true } release { minifyEnabled true proguardFiles getDefaultProguardFile( 'proguard-android.txt' ), 'proguard-rules.pro' signingConfig signingConfigs.config debuggable false } } productFlavors { uc { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "uc" ] } _360 { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "360" ] } baidu { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "baidu" ] } yyb { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "yyb" ] } } } dependencies { compile fileTree(dir: 'libs' , include: [ '*.jar' ]) testCompile 'junit:junit:4.12' compile 'com.android.support:appcompat-v7:23.3.0' }</code> |
我们需要配置:
signingConfigs
这是刚才我们新建的密匙信息 buildTypes
打包类型,包括了Debug和ReleaseproductFlavors
打包渠道就在这儿配置咯 同时在AndroidManifest里面加上,渠道标识
1 2 3 4 5 | <code class = "hljs r" ><manifest package = "example.com.makeapk" xmlns:android= "" > <meta-data android:name= "UMENG_CHANNEL" android:value= "${UMENG_CHANNEL_VALUE}" > ...省略 </meta-data></manifest></code> |
3 现在还有个问题—代码写完了怎么生成渠道包呢
OK,在命令行输入gradlew assembleRelease
,表示生成所有Release包,生成的包在build\outputs\apk
目录下,如果你要生成指定的包(uc|360|baidu),指定的版本(Release|Debug),右边的Gradle Project
可以帮到你4. 删除多余的 unaligned.apk
执行完-gradlew assembleRelease
,发现一个问题,生成的不仅有我们需要的包,unaligned.apk
类型的Apk也输出来了unaligned.apk
是还没执行对齐命令的包,是中间形态,这个需要删除,没必要不知道为什么Gradle没有帮我们删了这没啥用的玩意儿,问题是我们也不想一个一个的手动删除。好吧,写了一个脚本命令,在输出文件夹的命令行执行如下: 1 | <code class = "hljs lasso" > find . -name "*-unaligned.apk" | xargs rm -rf</code> |
5 优化gradle代码
刚才写的代码 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | <code class = "hljs perl" > productFlavors { uc { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "uc" ] } _360 { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "360" ] } baidu { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "baidu" ] } yyb { manifestPlaceholders = [UMENG_CHANNEL_VALUE: "yyb" ] } }</code> |
有些冗余,修改下减少我们的代码量
1 2 3 4 5 6 7 8 9 | <code class = "hljs avrasm" > productFlavors { uc {} _360 {} baidu {} yyb {} } productFlavors.all { flavor -> flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name] }</code> |
是不是美观多了
6.Gradle
对新人来说语法有学习曲线,能不能再容易一点咱们有工具啊,打开顶部Build选择红色部分,里面的编辑框可以帮助我们更快的熟悉Gradle来看看代码和编辑框的具体关系吧7. 打包太多,需要清理一下 炉火纯青 恐弄快打
直接修改渠道号
想想,如果只是打渠道包的话,没有必要对整个项目进行编译,来生成渠道号。
如果能直接修改apk的渠道号,而不需要再重新签名能节省不少打包的时间。幸运的是我们找到了这种方法。直接解压apk,解压后的根目录会有一个META-INF目录。如果在META-INF目录内添加空文件,可以不用重新签名应用。因此,通过为不同渠道的应用添加不同的空文件,可以唯一标识一个渠道。采用这种方式,每打一个渠道包只需复制一个apk,在META-INF中添加一个使用渠道号命名的空文件即可。这种打包方式速度非常快,900多个渠道不到一分钟就能打完。没错,这就是美团的打包策略使用方式:
使用本工具,Android程序员仅需将ChannelUtil.java放入到工程里使用,以后打包的事情就不用自己动手了。安装个Python环境,运行一下MultiChannelBuildTool.py,谁都可以打包了!毕竟实践是检验真理的唯一标准:拷贝一个,我们刚刚生成的app-uc-release.apk
到项目目录
果然厉害,1S就出来这么多包。
反编译看看,包打得对不对
命令行 1 | <code class = "hljs avrasm" >apktool d xxx.apk</code> |
打开目录,首先确认我们生成的XML里面的标识符
然后看到,美团极速打包方案也完成
但是,使用Gradle生成4个渠道,我们花了 26.5秒
人家 只花了目测 1s
1分钟900个包果然不是梦
Build Variants(构建变种版本)
待续…
登峰造极 打包安全
待续…