手机游戏SDK-第7部分（游戏打包（第2部分）-自动打包和坑记录）

您好，女士们，先生们，欢迎来到自动包装系列的最后一篇文章. 以上已整体分析并构建了自动化包装项目. 以下是与大人物包装的实际战斗. 处理方法.

在撰写之前，让我们看一下之前的包装流程图:

image.png

从该图可以看到，整个打包过程就是资源整合的过程，而自动打包逐步记录是资源整合的重心.

通常，在合并游戏和通道的资产目录时，首先要处理通道的特殊配置，然后将通道资产目录资源覆盖到游戏资源目录中. 但是在这里我们会遇到两个陷阱:

以YSDK通道程序包为例，当您以漂亮的外观运行该程序包时. . . bangbangbangbang，哈哈，单击YSDK频道登录，但没有任何反应. 有什么问题？不用担心，首先，您需要找到一个可以正常运行的软件包. 反编译并键入软件包后，您会发现资产目录中缺少一堆文件.

image.png

这些文件来自哪里？最后，您会发现在YSDK的.jar包中，当该包转换为smail时，仅转换源代码，并且不处理资源文件，从而导致资源丢失.

image.png

因此，在合并库资源时，您需要提取jar中的非类资源以进行处理. 该代码将在后面说明

细心的朋友可能会从上面的屏幕截图中看到，除了资产目录中的资源之外，BeaconVersion.txt文件也添加到了jar文件中，而该文件一开始并没有进入游戏. 那这个文件呢？

实际上，当编译并生成apk文件时，apktool工具会将非.apk文件打包到一个未知目录中. 在这里，您可以参考apktool的源代码分析.

Apktool源代码分析-第一篇

Apktool源代码分析-第二部分

public void decodeUnknownFiles(ExtFile apkFile, File outDir, ResTable resTable) throws AndrolibException {
  LOGGER.info("Copying unknown files...");
  File unknownOut = new File(outDir, UNK_DIRNAME);
  ZipEntry invZipFile;
  // have to use container of ZipFile to help identify compression type
  // with regular looping of apkFile for easy copy
  try {
      Directory unk = apkFile.getDirectory();
      ZipExtFile apkZipFile = new ZipExtFile(apkFile.getAbsolutePath());
      // loop all items in container recursively, ignoring any that are pre-defined by aapt
      Set<String> files = unk.getFiles(true);
      for (String file : files) {//取出apk内所有文件名
          if (!isAPKFileNames(file) && !file.endsWith(".dex")) {//不是常规文件也不是.dex文件
              // copy file out of archive into special "unknown" folder
              unk.copyToDir(unknownOut, file);//拷贝至unknown目录
              try {
                  // ignore encryption
                  apkZipFile.getEntry(file).getGeneralPurposeBit().useEncryption(false);
                  invZipFile = apkZipFile.getEntry(file);
                  // lets record the name of the file, and its compression type
                  // so that we may re-include it the same way
                  if (invZipFile != null) {//这里把他们收集起来，如果需要回编译还可以原封不动的塞回去
                      mResUnknownFiles.addUnknownFileInfo(invZipFile.getName(), String.valueOf(invZipFile.getMethod()));
                  }
               } catch (NullPointerException ignored) { }
            }
        }
        apkZipFile.close();
   } catch (DirectoryException | IOException ex) {
        throw new AndrolibException(ex);
   }
}

当您处理前两个坑并将资源文件复制到相应的目录时，您认为它们是以一种精美的方式打包的，并且您会发现在您处理的未知目录中找不到资源在重新编译期间. 内部是Apk. 为什么？

请看一下这句话:

{8: b: c: 2: 6: 3: 4: e: 7: c: 8: 1: 9: 1: b: 8: c: 6: e: a: 4: 5: a: 5: 7: a: 6: f: 7: 1: 1: d）

apktool工具在反编译apk时会将编译过程的资源信息写入apktool.yml文件中，然后在重新编译时读取apktool.yml的配置信息以查找相应的资源文件.

public void writeMetaFile(File mOutDir, Map<String, Object> meta)//键值对信息
            throws AndrolibException {
        DumperOptions options = new DumperOptions();
        options.setDefaultFlowStyle(DumperOptions.FlowStyle.BLOCK);
        Yaml yaml = new Yaml(options);
        try (
                Writer writer = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(
                        new File(mOutDir, "apktool.yml")), "UTF-8"));//输出目录
        ) {
            yaml.dump(meta, writer);
        } catch (IOException ex) {
            throw new AndrolibException(ex);
        }
    }

因此，当我们将资源合并到未知目录中时，我们需要修改apktool.yml信息

这个坑是相对秘密的. 它是由不同版本的apktool发现的. 故障排除时遇到了它. 打包工具使用2.3.3版，但计算机配置环境变量apktool版本是2.0.1. 版本，然后手动重新编译，它将始终报告错误: “无法确定标签'tag: yaml.org，2002: brut.androlib.meta.MetaInfo'的构造函数”. 只是发现更高版本的apktool工具生成apktool.yml文件时，此字段会自动添加到第一行，并且在重新编译该版本时会报告错误. 如果用于反编译和重新编译的版本相同手游sdk登录失败怎么解决，则没有问题.

这个问题已经检查了很长时间，最终发现游戏包主体资源放置在资产目录中太多了. 当将其编译回apk包主体时，将无法对其进行编译. 由apktool.yml处理下doNotCompress字段下的字符串数限制引起的（Windows命令行支持8191个字符的字符串长度限制）.

要解决此问题，您还需要与apktool的版本兼容.

apktool 2.0.2和更早版本不处理这种未压缩的机制，可以正常地编译回去.

从2.0.2到2.3.2的新的未压缩过滤规则

“ jpg | jpeg | png | gif | wav | mp2 | mp3 | ogg | aac | mpg | mpeg |中| midi | smf | jet | rtttl | imy | xmf | mp4 | m4a | m4v | 3gp | 3gpp | 3g2 | 3gpp2 | amr | awb | wma | wmv | webm | mkv“

但是在2.3.3及更高版本中，没有过滤规则已被删除.

为了与apktool版本兼容，请在重新编译期间修改设置过滤器规则，并修改apktool.yml文件下的doNotCompress字段.

对于上述问题，您可以在PackageApkTool / MergeLibUtils.py中检查Modify_jars的具体实现

通常，在合并游戏和频道的libs目录时，您需要处理两种类型的文件处理: .jar和.so.

1. 将非类资源提取到.jar文件中，然后将其复制到相应的目录中.

2. 确保通道提供的.so资源文件在armeabi / armeabi-v7a / x86以及与游戏包正文相对应的其他目录中一致. 否则，某些模型将崩溃.

需要对WeChat相关功能进行进一步处理的3..java文件转换为相应的jar文件，这便于后续的jar自动转换为smali代码以进行统一处理

对于上述问题，可以在PackageApkTool / MergeResource.py

中查看merge_libs_resource的特定实现.

通常，当游戏和频道的libs目录合并时，频道资源副本将直接覆盖到游戏目录中.

常规频道的res目录资源通过前缀来区分，但是需要考虑的是与游戏资源和频道资源同名的文件的覆盖范围.

反编译后，通道提供的资源目录结构与游戏的目录结构不一致. 通常，在创建新的Android项目时，res目录中的大多数资源包都采用drawable，drawable-hdpi，drawable-xhdpi，values，values-hdpi等形式. 但是在反编译之后，您会发现目录格式游戏的方式不同:

image.png

如果游戏资源的资源文件已经存在，则在复制频道资源后，将在编译时提示其重复该资源. 为了解决这个问题，合并资源文件时，需要预先确定反编译后的目录结构. . 复制到相应的资源文件.

在复制通道资源后，在游戏反编译后，通道中具有相同名称的资源将覆盖原始资源，以确保该资源是通道的最新版本，但应注意数组. 值目录中的xml / colors.xml文件/demens.xml/strings.xml的资源丢失问题是因为将游戏apk包反编译后的资源信息打包到了这些文件中. 覆盖后，找到相应的资源将导致各种问题，因此您需要合并这些资源文件.

单个通道的res / values目录提供了values.xml和values-hdpi.xml的复合资源文件，该文件定义了资源属性. Values.xml就是arrays.xml / colors.xml /demens.xml/strings.xml和其他组合:

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/sanxing/article-147116-1.html