Cocos Creator Android 打包疑难杂症记录

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

当然,这个写法能持续兼容多久,不能保证,但是相信到时候你已经知道应该怎么解决了

你可能感兴趣的:(Cocos Creator Android 打包疑难杂症记录)