Android Studio 运行 Apk,不会采用最新构建的 Cocos 内容问题
每次在Cocos构建项目后,在Android Studio上点击 Run,「可能」会发现这次Run,并不会采用刚刚构建的Cocos内容!??
划重点: 「可能」
- 有些人/电脑/AndroidStudio版本 会 立即采用刚刚构建的 Cocos 内容
- 有些人/电脑/AndroidStudio版本 不会 立即采用刚刚构建的 Cocos 内容
如果这个能引起你的共鸣,那么不妨试着看下去~
Cocos & Android 构建原理
解决这个问题,我们可以先大概了解一下 Cocos & Android 的一些构建原理:
1.Cocos 构建资源会放在 Android 项目的 assets 资源目录中
2.app 运行时,读取 assets 资源目录,从而获取到 Cocos 构建后的资源
这里面,我们重点探究的是 Cocos 是怎么将构建的内容放到 Android 的 assets 资源目录中呢?
这个操作其实在构建后的 app/build.gradle
中,关键代码如下:
android.applicationVariants.all { variant ->
// delete previous files first
delete "${buildDir}/intermediates/merged_assets/${variant.dirName}"
// 复制 Cocos 资源到 Assets 目录中
variant.mergeAssets.doLast {
// ....
copy {
from "${sourceDir}/res"
into "${outputDir}/res"
}
copy {
from "${sourceDir}/subpackages"
into "${outputDir}/subpackages"
}
copy {
from "${sourceDir}/src"
into "${outputDir}/src"
}
copy {
from "${sourceDir}/jsb-adapter"
into "${outputDir}/jsb-adapter"
}
copy {
from "${sourceDir}/main.js"
from "${sourceDir}/project.json"
into outputDir
}
}
//....
}
怎么理解上面这段代码呢?
首先 Android 打包 Apk 是由 Google 开发的一套 Gradle 插件去完成打包的。实际上,每次打包会有很多构建任务,比如:编译java,编译C++等等。各个任务之间存在依赖关系,插件根据依赖关系执行对应任务,最后就生成了APK。
而其中有一个插件内置的 Android 构建任务 mergeAssets
,其目的在于将 Android 项目及各个依赖 Library 的 Assets 资源文件合并到构建缓存目录,方便最后打包。
而 Cocos 就是在 这个任务最后(variant.mergeAssets.doLast
),添加了一些复制任务,将 Cocos 的脚本资源等等内容复制到 Android Apk 的 Assets 资源目录中。
现在,你应该(必须)能很好地理解上面这段代码以及 Cocos & Android 的构建过程了~
问题成因
那么问题来了?
为什么有些人,他们构建Cocos的游戏后,在Android Studio中运行,每次都能更新 Cocos 构建后的资源,而有些人却不会更新 Cocos 构建后的资源呢?
实际上,这里用有些人不是很恰当,只是大家习惯于这样子描述问题。这个问题的差异化在于所用的引擎版本和Android构建Gradle版本,在不同人/PC上可能会采用不同Android Studio版本,不同的构建Gradle版本
。
问题代码具体为上面的此行代码
delete "${buildDir}/intermediates/merged_assets/${variant.dirName}"
这个代码的意图在于每次复制 Cocos 的资源到 assets 目录时,先删除Android之前有可能构建过的 assets 构建暂存目录,以实现每次打包都能 Copy 最新的 Cocos 构建后的内容进去。
为什么要先删除 assets 构建暂存目录呢?这里面,还得插入一个知识点。
Groovy 的 Copy 任务会自动识别本次是否应该执行复制。比如:复制文件A到一个目录两次,在第二次执行的时候,同名文件则不会复制,而是会 UP-TO-DATE 不会再执行。
因此为了避免 Cocos 二次构建后的(同名文件)内容也能在 Android Studio 中 Run 的时候也能用上,那么就需要先删除目录,让复制后的目录没有同名文件,这样子在执行复制的时候就会真的是触发复制逻辑,从而更新最新的 Cocos 构建内容到 Apk 包中。
嗯,这个意图很清晰,但是上述代码并不完美。
首先,这种 Hard Code 写法很容易出现问题,如果路径换了一下,那么实际上就不能很好的执行这个删除意图了。而问题恰好就是这个路径问题。
实际上,有些同学可能会用不同版本的 Android Studio ,用了不同版本的 Gradle Plugin。而不同版本的 Gradle Plugin 的 mergeAssets
Task 的暂存目录并不全是上面的绝对路径。
事实上,不同 Gradle Plugin 版本的 mergeAssets 的输出路径有哪些,我也不知道有哪些路径,并且我们也不应该去固化这个路径。Android 在持续发展,打包工具也在持续更新,构建任务也可能会修改升级,但这种 Hard Code 路径的写法却极有可能不会能持续用下去。
我们更应该用的是 variant.mergeAssets.outputDir
变量去表示 mergeAssets 的输出路径,而不是某个 Hard Code 的字符串。
而 Cocos 恰好是用了 Hard Code 的路径字符串,从而导致了这个小问题:有些(版本)每次运行都能拿到最新的 Cocos 构建资源,而有些版本缺不可以
解决方案
至此,修复起来就很简单了,只需要一个很简单的修改就可以修复:
-- delete "${buildDir}/intermediates/merged_assets/${variant.dirName}"
++ delete variant.mergeAssets.outputDir
当然,这个写法能持续兼容多久,不能保证,但是相信到时候你已经知道应该怎么解决了