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

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