业精于勤,荒于嬉; 行成于思,毁于随

前言

去年年底的时候，写过一篇博客叫《Android-application中使用provided-aar并没有那么简单》。当时文章中介绍了android gradle plugin不同版本的实现方式，对android gradle plugin 2.2.0以下版本的实现，是采用使用gradle maven的api实现，利用gradle本地缓存，这种方式不但反射的地方非常多，而且不支持传递依赖，局限性非常大。周末有空，又重新拿起来研究了下，最终实现了android gradle plugin [1.3.0,3.2.0+)版本的传递依赖，在插件化中起着重要意义，几乎是全版本兼容了，通过源码发现使用相同的方式无法进行兼容1.3.0以下的版本，且版本过于久远，所以直接不支持了。建议阅读本篇博客前，强烈建议先将之前的那篇博客看一下，否则可能无法理解。没有特殊说明的情况下，下文将android gradle plugin简称为AGP。

前言

之前写过一篇aapt2适配之资源id固定，该文章介绍了如何使用aapt2固定资源id，其实这篇文章是对该文章的一点补充，主要介绍如何在固定id的同时，将该资源进行导出，打上public标记，供其他资源进行引用。整个问题的解决方案断断续续差不多思考了一个来月，现将解决方法简单介绍一下。

前几天遇到一个坑，就是Clion、Cmake、NDK在一起使用的时候，Clion会将NDK相关头文件报红，即找不到相关头文件，无法做到代码提示及自动补全，但是编译是可以通过的，google了一番，发现这个问题在2015年的时候就存在了，但是官方宣称已经修复了， 但是实际测试下来，并没有修复。相关链接见：

• Problem with include, parser is now broken with -DCMAKE_SYSTEM_NAME=Generic (MinGW)
• CLion fails to find some of my headers. Where does it search for them?
• Cannot find the header in C

前言

首先简单讲一下这个需求的背景，大部分场景下，是没有这个需求的，这个需求出现在插件化中，当一个android插件引用aar中的类的时候，并且这个插件是使用com.android.application 这个gradle插件进行打包的，但是这个类已经在宿主中或者其他插件中，其实就没有必要将这个重复类打包到插件中，因此只需要进行引用，不需要打包到插件中。引用是其中一个目的，保证混淆的正确性则是另一个目的。寻找这个需求的解决方案的过程中，发现这个问题其实并没有想象中的那么好解决，会遇到许许多多的细节问题。

最近需要对AOSP上的aapt和aapt2进行自定义，但是AOSP的整个源码树过大，完整释放后约200G，不大适合整个拉下来编译，因此对构建环境进行精简，只拉取aapt和aapt2的关键依赖项目，使用cmake进行编译，整个移植过程很顺利，并且成功的编译出了mac和linux的可执行文件和对应的动态库，包括x86和x86_64的文件，但是在编译windows的版本的时候，遇到了一点小问题，就是AOSP上的依赖项目，存在软链接，但是windows系统是不支持软链接的，因此不能在windows上进行编译。

Google最近发布了Tensorflow Lite，并且提供了demo，虽然该demo可以使用bazel build –cxxopt=’–std=c++11’ //tensorflow/contrib/lite/java/demo/app/src/main:TfLiteCameraDemo命令成功编译出来，但是文档中并没有提及如何纯粹的编译出动态库，参考之前的一篇文章《当 Android 开发者遇见 TensorFlow》，这篇文章就简单介绍一下如何编译动态库

前言

资源id的固定在热修复和插件化中极其重要。在热修复中，构建patch时，需要保持patch包的资源id和基线包的资源id一致；在插件化中，如果插件需要引用宿主的资源，则需要将宿主的资源id进行固定，因此，资源id的固定在这两种场景下是尤为重要的。而在Android Gradle Plugin 3.0.0中，默认开启了aapt2，原先aapt的资源固定方式public.xml也将失效，必须寻找一种新的资源固定的方式，而不是简单的禁用掉aapt2，因此本文来探讨一下开启aapt2的情况下如何进行资源id的固定。

为了偷懒，使用了nio中的FileChannel进行流的读取，代码如下：

1

long transferSize = toChannel.transferFrom(fromChannel, 0, Long.MAX_VALUE);

前言

本文基于AOSP Android 8.1分析，Android 9.0 资源proto文件格式发生了变化。

从Android Studio 3.0开始，google默认开启了aapt2作为资源编译的编译器，aapt2的出现，为资源的增量编译提供了支持。当然使用过程中也会遇到一些问题，我们可以通过在gradle.properties中配置android.enableAapt2=false来关闭aapt2。

如果你觉得本篇文章太长，可以直接看我总结的结论：

Google Archive Patch是严格的基于Zip文件格式的差量算法，其核心生成差量的算法还是BsDiff，核心合成文件的算法还是BsPatch，只是它将旧Zip文件和新Zip文件里的内容解压出来分别转为了差量友好的一个文件，使用差量算法生成差量文件；合成时，将旧Zip文件里的内容解压出来转为差量友好的一个文件，应用合成算法，生成新文件的差量友好的一个文件，再利用patch文件中每个ZipEntry的偏移和长度，以及压缩等级，编码策略，nowrap等标记，将其恢复为Zip文件。之所以使用差量友好的文件是因为一个文件，如果未压缩，那么可以很简单的描述其变化，如字符串”abc”，变为了”abcd”，我们可以直观的描述其变化，增加了一个字符”d”；但是如果字符串经过了压缩，那么这个变化不再可以这么容易的被描述。因此需要将压缩后的文件转为未压缩的文件，生成差量友好的文件。

生成慢：Google Archive Patch之所以生成Patch的时间变长了，是因为Zip文件解压出来后，生成的差量友好的文件变大了，因此使用BsDiff时，耗费的时间变长了。比如解压出来后变大了2倍，则时间消耗变为了原来整个文件的生成差量的时间的2倍。

合成慢：合成的时间变长了，一方面的消耗也是因为生成差量友好的文件变大了，但是这不是本质原因，BsPatch合成是极快的，就算double倍时间，这点时间也是可以忽略不计的。其耗费时间的根本问题还在于重新生成zip文件时需要对流做各种判断操作，一部分数据需要压缩，一部分数据需要拷贝，基本上大部分的耗时操作都花在了数据的压缩操作上。

生成文件小：小的原因上面已经解释过了，是因为基于差量友好的文件生成差量文件的，文件间的变换变得很容易描述。