elo机制,android垃圾回收机制

Android系统开发的第一步就是获取源码，这时就需要用到repo命令了：

repo init，用于初始化repo环境，一个XML格式的manifest.xml文件会生成在本地新建的.repo/中，
manifest.xml定义了本地代码的目录结构，以及从远程下载的代码路径。

repo sync，用于下载Android源码，这需要解析manifest.xml文件，按照指示下构建本地源码目录。

由此可见，repo基于manifest.xml完成对Android源码的管理，manifest.xml是描述源码结构的清单。

对于源码来讲，manifest.xml只是一个到.repo/manifests/default.xml的文件链接。
真正的清单文件是通过manifests这个git库托管起来的。
打开AOSP(Android Open Source Project)的manifests库，其中只包含一个default.xml文件，
这就是最基本的清单构成。

整个结构如下图所示：

在进行Android系统开发时，通常需要对清单文件进行定制，例如：
设备厂商会构建自己的manifest库，通常是基于AOSP的default.xml进行定制，比如：
去掉AOSP的一些git库、增加一些自有的git库。

要实现定制清单的目的，可以直接对default.xml文件内容进行修改，然而这种方式在一些场景下存在弊端，例如：
1、部分对default.xml的修改，不需要上传到代码服务器，于是定期同步最新的default.xml，就容易与本地的修改产生冲突;
2、设备厂商大都是在多分支的环境下开发，对不同default.xml修改的内容都往往是相同的，这就导致需要在多分支上重复提交相同的修改。

这个时候，就可以使用repo支持的另一种定制方式：Local Manifests。
在repo sync下载代码之前，会将.repo/manifests/default.xml、local_manifest.xml和.repo/local_manifests/目录下存在清单文件进行合并，再根据融合的清单文件进行代码同步。
这样一来，只需要将清单文件的修改项放到.repo/local_manifests/目录下，就能够在不修改default.xml的前提下，完成对清单的文件的定制。
Local Manifests机制的原理图如下所示：

参考网上的资料，Local Manifests的隐含规则如下：
1、先解析local_manifest.xml，再解析local_manifests/目录下的清单文件;
2、local_manifests目录下的清单文件是没有命名限制的，但会按照字母序被解析，即字母序靠后的文件内容会覆盖之前的;
3、所有清单文件的内容必须遵循repo定义的格式才能被正确解析。

了解了Local Manifests机制后，我们来看实际的例子。

假设default.xml的内容如下所示：

<?xml version="1.0" encoding="UTF-8"?><manifest> <remote name="origin" fetch=".." /> <default revision="refs/heads/master" remote="origin" /> <project path="A" name="Demo/project-A" revision="refs/heads/master"/> <project path="B" name="Demo/project-B" revision="refs/heads/master"/></manifest>

此时，直接repo sync将得到project-A和Project-B的master分支代码。

如果我们在repo sync前，在.repo/目录下创建local_manifest.xml或local_manifests/1.xml，
那么Local Manifests机制就会启动。

假设local_manifest.xml的内容如下所示：

此时，再进行repo sync，将得到Project-B和Project-C，且Project-B的头节点为527cdcb2b4dad3723bc4c3ae850da8ed187bde1d。