安卓源码下载和编译(网上下载的安卓源码怎么运行) 收藏 0

Repo:Android 源码管理的利器–工作原理与常用命令全解析

在 Android 开发中，源码管理是一项至关重要且颇具挑战性的任务。面对包含数百个 git 库的 Android 源码，如何高效地进行下载、管理和协作开发成为了开发者们必须攻克的难题！repo专为 Android 开发者打造的工具，旨在让开发者们能够更加得心应手地利用 git，提升开发效率。repo 是如何巧妙地管理如此众多的 git 库？它的工作原理究竟是怎样的？又有哪些实用的命令和技巧能助力我们在 Android 开发的征程中披荆斩棘？ 笔者将通过本文与大家分享学习。

1. 概要

repo是Android为了方便管理多个git库而开发的Python脚本。repo的出现，并非为了取代git，而是为了让Android开发者更为有效的利用git。

Android源码包含数百个git库，仅仅是下载这么多git库就是一项繁重的任务，所以在下载源码时，Android就引入了repo。 Android官方推荐下载repo的方法是通过Linux curl命令，下载完后，为repo脚本添加可执行权限：

由于国内Google访问受限，所以上述命令不一定能下载成功。其实，我们现在可以从很多第三方渠道找到repo脚本，只需要取下来，确保repo可以正确执行即可。

2. 工作原理

repo需要关注当前git库的数量、名称、路径等，有了这些基本信息，才能对这些git库进行操作。通过集中维护所有git库的清单，repo可以方便的从清单中获取git库的信息。 这份清单会随着版本演进升级而产生变化，同时也有一些本地的修改定制需求，所以，repo是通过一个git库来管理项目的清单文件的，这个git库名字叫manifests。

当打开repo这个可执行的python脚本后，发现代码量并不大(不超过1000行)，难道仅这一个脚本就完成了AOSP数百个git库的管理吗？并非如此。 repo是一系列脚本的集合，这些脚本也是通过git库来维护的，这个git库名字叫repo。

在客户端使用repo初始化一个项目时，就会从远程把manifests和repo这两个git库拷贝到本地，但这对于Android开发人员来说，又是近乎无形的(一般通过文件管理器，是无法看到这两个git库的)。 repo将自动化的管理信息都隐藏根目录的.repo子目录中。

2.1 项目清单库(.repo/manifests)

AOSP项目清单git库下，只有一个文件default.xml，是一个标准的XML，描述了当前repo管理的所有信息。

AOSP的default.xml的文件内容如下：

• ：描述了远程仓库的基本信息。name描述的是一个远程仓库的名称，通常我们看到的命名是origin;fetch用作项目名称的前缘，在构造项目仓库远程地址时使用到;review描述的是用作code review的server地址
• ：default标签的定义的属性，将作为标签的默认属性，在标签中，也可以重写这些属性。属性revision表示当前的版本，也就是我们俗称的分支;属性remote描述的是默认使用的远程仓库名称，即标签中name的属性值;属性sync-j表示在同步远程代码时，并发的任务数量，配置高的机器可以将这个值调大
• ：每一个repo管理的git库，就是对应到一个标签，path描述的是项目相对于远程仓库URL的路径，同时将作为对应的git库在本地代码的路径; name用于定义项目名称，命名方式采用的是整个项目URL的相对地址。 譬如，AOSP项目的URL为https://android.googlesource.com/，命名为platform/build的git库，访问的URL就是https://android.googlesource.com/platform/build

如果需要新增或替换一些git库，可以通过修改default.xml来实现，repo会根据配置信息，自动化管理。但直接对default.xml的定制，可能会导致下一次更新项目清单时，与远程default.xml发生冲突。 因此，repo提供了一个种更为灵活的定制方式local_manifests:所有的定制是遵循default.xml规范的，文件名可以自定义，譬如local_manifest.xml, another_local_manifest.xml等， 将定制的XML放在新建的.repo/local_manifests子目录即可。repo会遍历.repo/local_manifests目录下的所有*.xml文件，最终与default.xml合并成一个总的项目清单文件manifest.xml。

local_manifests的修改示例如下：

2.2 repo脚本库(.repo/repo)

repo对git命令进行了封装，提供了一套repo的命令集(包括init,sync等)，所有repo管理的自动化实现也都包含在这个git库中。 在第一次初始化的时候，repo会从远程把这个git库下载到本地。

2.3 仓库目录和工作目录

仓库目录保存的是历史信息和修改记录，工作目录保存的是当前版本的信息。一般来说，一个项目的Git仓库目录（默认为.git目录）是位于工作目录下面的，但是Git支持将一个项目的Git仓库目录和工作目录分开来存放。 对于repo管理而言，既有分开存放，也有位于工作目录存放的:

• manifests： 仓库目录有两份拷贝，一份位于工作目录(.repo/manifests)的.git目录下，另一份独立存放于.repo/manifests.git
• repo：仓库目录位于工作目录(.repo/repo)的.git目录下
• project：所有被管理git库的仓库目录都是分开存放的，位于.repo/projects目录下。同时，也会保留工作目录的.git，但里面所有的文件都是到.repo的链接。这样，即做到了分开存放，也兼容了在工作目录下的所有git命令。

既然.repo目录下保存了项目的所有信息，所有要拷贝一个项目时，只是需要拷贝这个目录就可以了。repo支持从本地已有的.repo中恢复原有的项目。

2.4 repo 目录结构分析

• .repo：

此为repo目录，可用于提取相应项目工作目录到外面的repo工作目录。

• .repo/manifests.git：

此为repo配置信息的git库，不同版本包含不同配置信息。每个repo项目初始化后也会有自己的git仓库的repo也会建立一个Git仓库，用来记录当前Android版本下各个子项目的Git仓库分别处于哪一个分支，这个仓库通常叫做：manifest仓库。

• .repo/manifests：

此为repo配置信息的工作目录（将配置信息的工作目录和相应的实际git目录分离管理，并且配置信息中的.git目录实际只是指向实际git库的软连接）。此目录中可能包含一个或多个xml文件描述的配置。每个xml文件是独立的一套配置，配置内容包括当前repo工作目录包含哪些git项目、所有git项目所处的默认公共分支、以及远端地址等。

• .repo/manifest.xml：

repo工作目录中的内容同一时刻只能采用manifests中的一个xml文件做为其配置，该文件就是其软连接，通过init的-m选项指定采用哪个文件；另外，同一xml文件也可能处于manifests库的不同版本或者不同分支，通过init的-b选项指定使用manifests中的哪个分支，每次init命令都会从服务器更新最新的配置。这里通过-m指定的manifests中的xml文件中。

• .repo/repo：

此为repo脚本集的git库，用于repo管理所需的各种脚本，repo的所有子命令就是其中的对应脚本实现。这些脚本也通过git管理，.repo/repo/.git为对其应的git目录，用git进行版本管理。

repo命令的使用格式如下所示：

可选的的有：help、init、sync、upload、diff、download、forall、prune、start、status，每一个命令都有实际的使用场景， 下面我们先对这些命令做一个简要的介绍：

• -u：指定manifests这个远程git库的URL，manifests库是整个项目的清单。默认情况，这个git库只包含了default.xml一个文件，其内容可以参见Android的样本
• -m， –manifest-name：指定所需要的manifests库中的清单文件。默认情况下，会使用maniftests/default.xml
• -b， –manifest-branch：指定manifest.xml文件中的一个版本，，也就是俗称的“分支”运行该命令后，会在当前目录下新建一个.repo子目录：

.repo

├── manifests # 一个git库，包含default.xml文件，用于描述repo所管理的git库的信息

├── manifests.git # manifest这个git库的实体，manifest/.git目录下的所有文件都会链接到该目录

├── manifest.xml # manifests/default.xml的一个软链接

├── repo # 一个git库，包含repo运行的所有脚本

这些本地的目录是如何生成的呢？执行repo命令时，可以通过–trace参数，来看实际发生了什么。

首先，在当前目录下创建.repo子目录，后续所有的操作都在.repo子目录下完成;

然后，clone了两个git库，其中一个是-u参数指定的manifests，本地git库的名称是manifest.git;另一个是默认的repo，后面我们会看到这个URL也可以通过参数来指定;

接着，创建了manifest/.git目录，里面的所有文件都是到manifests.git这个目录的链接，这个是为了方便对manifests目录执行git命令，紧接着，就会将manifest切换到-b参数指定的分支;

最后，在.repo目录下，创建了一个软链接，链接到-m参数制定的清单文件，默认情况是manifests/default.xml。

这样，就完成了一个多git库的初始化，之后，就可以执行其他的repo命令了。

我们还介绍几个不常用的参数，在国内下载Android源码时，会用到：

• –repo-url：指定远程repo库的URL，默认情况是https://android.googlesource.com/tools/repo，但国内访问Google受限，会导致这个库无法下载，从而导致repo init失败，所以可以通过该参数指定一个访问不受限的repo地址
• –repo-branch：同manifest这个git库一样，repo这个git库也是有版本差异的，可以通过该参数来指定下载repo这个远程git库的特定分支
• –no-repo-verify：在下载repo库时，会对repo的源码进行检查。通过–repo-url指定第三方repo库时，可能会导致检查不通过，所以可以配套使用该参数，强制不进行检查

下载远程代码，并将本地代码更新到最新，这个过程称为“同步”。如果不使用任何参数，那么会对所有repo管理的进行同步操作;也可以PROJECT_LIST参数，指定若干要同步的PROJECT。 根据本地git库代码不同，同步操作会有不同的行为：

• 当本地的git库是第一次触发同步操作时，那么，该命令等价于git clone，会将远程git库直接拷贝到本地
• 当本地已经触发过同步操作时，那么，该命令等价于git remote update && git rebase origin/，就是当前与本地分支所关联的远程分支 代码合并可能会产生冲突，当冲突出现时，只需要解决完冲突，然后执行git rebase –continue即可。

当sync命令正确执行完毕后，本地代码就同远程代码保持一致了。在一些场景下，我们会用到sync命令的一些参数：

• -j：开启多线程同步操作，这会加快sync命令的执行速度。默认情况下，使用4个线程并发进行sync
• -c, –current-branch：只同步指定的远程分支。默认情况下，sync会同步所有的远程分支，当远程分支比较多的时候，下载的代码量就大。使用该参数，可以缩减下载时间，节省本地磁盘空间
• -d, –detach：脱离当前的本地分支，切换到manifest.xml中设定的分支。在实际操作中，这个参数很有用，当我们第一次sync完代码后，往往会切换到dev分支进行开发。如果不带该参数使用sync， 则会触发本地的dev分支与manifest设定的远程分支进行合并，这会很可能会导致sync失败
• -f, –force-broken：当有git库sync失败了，不中断整个同步操作，继续同步其他的git库
• –no-clone-bundle：在向服务器发起请求时，为了做到尽快的响应速度，会用到内容分发网络(CDN, Content Delivery Network)。同步操作也会通过CDN与就近的服务器建立连接， 使用HTTP/HTTPS的U R L / c l o n e . b u n d l e 来初始化本地的 g i t 库， c l o n e . b u n d l e 实际上是远程 g i t 库的镜像，通过 H T T P 直接下载，这会更好的利用网络带宽，加快下载速度。当服务器不能正常响应下载 URL/clone.bundle来初始化本地的git库，clone.bundle实际上是远程git库的镜像，通过HTTP直接下载，这会更好的利用网络带宽，加快下载速度。 当服务器不能正常响应下载URL/clone.bundle来初始化本地的git库，clone.bundle实际上是远程git库的镜像，通过HTTP直接下载，这会更好的利用网络带宽，加快下载速度。当服务器不能正常响应下载URL/clone.bundle，但git又能正常工作时，可以通过该参数，配置不下载$URL/clone.bundle，而是直接通过git下载远程git库

从字面意思理解，upload就是要上传，将本地的代码上传到远程服务器。upload命令首先会找出本地分支从上一次同步操作以来发生的改动，然后会将这些改动生成Patch文件，上传至Gerrit服务器。 如果没有指定PROJECT_LIST，那么upload会找出所有git库的改动;如果某个git库有多个分支，upload会提供一个交互界面，提示选择其中若干个分支进行上传操作。

upload并不会直接将改动合并后远程的git库，而是需要先得到Reviewer批准。Reviewer查看改动内容、决定是否批准合入代码的操作，都是通过Gerrit完成。 Gerrit服务器的地址是在manifests中指定的：打开.repo/manifest.xml，这个XML TAG中的review属性值就是Review服务器的URL:

Gerrit的实现机制不是本文讨论的内容，但有几个与Gerrit相关的概念，是需要代码提交人员了解的：

• Reviewer：代码审阅人员可以是多个，是需要人为指定的。Gerrit提供网页的操作，可以填选Reviewer。当有多个git库的改动提交时，为了避免在网页上频繁的填选Reviewer这种重复劳动， upload提供了–re, –reviewer参数，在命令行一次性指定Reviewer
• Commit-ID：git为了标识每个提交，引入了Commit-ID，是一个SHA-1值，针对当次提交内容的一个Checksum，可以用于验证提交内容的完整性
• Change-ID：Gerrit针对每一个Review任务，引入了一个Change-ID，每一个提交上传到Gerrit，都会对应到一个Change-ID， 为了区分于Commit-ID，Gerrit设定Change-ID都是以大写字母 “I” 打头的。 Change-ID与Commit-ID并非一一对应的，每一个Commit-ID都会关联到一个Change-ID，但Change-ID可以关联到多个Commit-ID
• Patch-Set：当前需要Review的改动内容。一个Change-ID关联多个Commit-ID，就是通过Patch-Set来表现的，当通过git commit –amend命令修正上一次的提交并上传时， Commit-ID已经发生了变化，但仍可以保持Change-ID不变，这样,在Gerrit原来的Review任务下，就会出现新的Patch-Set。修正多少次，就会出现多少个Patch-Set， 可以理解，只有最后一次修正才是我们想要的结果，所以，在所有的Patch-Set中，只有最新的一个是真正有用的，能够合并的。

upload是把改动内容提交到Gerrit，download是从Gerrit下载改动。与upload一样，download命令也是配合Gerrit使用的。

• ：指定要下载的PROJECT，譬如platform/frameworks/base, platform/packages/apps/Mms
• ：指定要下载的改动内容。这个值不是Commit-ID，也不是Change-ID，而是一个Review任务URL的最后几位数字。 譬如，AOSP的一个Review任务https://android-review.googlesource.com/#/c/23823/，其中23823就是。

对指定的git库执行-c参数制定的命令序列。在管理多个git库时，这是一条非常实用的命令。PROJECT_LIST是以空格区分的，譬如：

表示对platform/frameworks/base和platform/packages/apps/Mms同时执行git status命令。 如果没有指定PROJECT_LIST，那么，会对repo管理的所有git库都同时执行命令。

该命令的还有一些其他参数：

• -r, –regex： 通过指定一个正则表达式，只有匹配的PROJECT，才会执行指定的命令
• -p：输出结果中，打印PROJECT的名称

删除指定PROJECT中，已经合并的分支。当在开发分支上代码已经合并到主干分支后，使用该命令就可以删除这个开发分支。

随着时间的演进，开发分支会越来越多，在多人开发同一个git库，多开发分支的情况会愈发明显，假设当前git库有如下分支：

那么，针对该git库使用prune命令，会删除dev_feature1_201501和dev_feature2_201502。

定义删除无用的分支，能够提交团队的开发和管理效率。prune就是删除无用分支的”杀手锏“。

在指定的PROJECT的上，切换到<BRANCH_NAME>指定的分支。可以使用–all参数对所有的PROJECT都执行分支切换操作。 该命令实际上是对git checkout命令的封装，<BRANCH_NAME>是自定义的，它将追踪manifest中指定的分支名。

当第一次sync完代码后，可以通过start命令将git库切换到开发分支，避免在匿名分支上工作导致丢失改动内容的情况。

status用于查看多个git库的状态。实际上，是对git status命令的封装。

Android推荐的开发流程是：

• repo init初始化工程，指定待下载的分支
• repo sync下载代码
• repo start将本地git库切换到开发分支(TOPIC BRANCH)
• 在本地进行修改，验证后，提交到本地
• repo upload上传到服务器，等待review

在实际使用过程中，我们会用到repo的一些什么子命令和参数呢？哪些参数有助于提高开发效率呢？下面我们以一些实际场景为例展开说明。

通过local_manifest机制，能够避免了直接修改default.xml，不会造成下次同步远程清单文件的冲突。

CyanogenMod(CM)适配了上百款机型，不同机型所涉及到的git库很可能是有差异的。以CM对清单文件的定制为例，通过新增local_manifest.xml，内容如下：

local_manifest.xml会与已有的default.xml融合成一个项目清单文件manifest.xml，实现了对一些git库的替换和新增。 可以通过以下命令导出当前的清单文件，最终snapshot.xml就是融合后的版本：

在编译之前，保存整个项目的清单，有助于问题的回溯。当项目的git库发生变更，需要回退到上一个版本进行验证的时候，只需要重新基于snapshot.xml初始化上一个版本即可：

在repo init的时候，会从远程下载manifests和repo这两个git库，默认情况下，这两个git库的地址都是写死在repo这个python脚本里面的。对于AOSP而言，这两个git库的地址显然是google提供的。但由于google访问受限的缘故，会导致init时，无法下载manifests和repo。这时候，可以使用init的-u和–repo-url参数，自定义这两个库的地址，辅以–no-repo-verify来绕过代码检查。

repo默认会同步git库的所有远程分支的代码，但实际开发过程中，用到的分支是有限的。使用sync的-c参数，可以只下载manifest中设定的分支，这会节省代码下载时间以及本地的磁盘空间：

如果实际开发过程中，需要用到另外一个分支，而又不想被其他分支干扰，可以在已有的工程根目录下，使用如下命令：

以上命令序列，相当更新了manifest，而且仅仅只下载ANOTHER_BRANCH的代码，这样本地只保存了两个分支的代码。利用保存的snapshot.xml，还能将所有git库方便的切换回原来的分支。

如果本地已经有一份Android源码，假设路径为~/android-exsit，想要下载另一份新的Android源码，通过–reference参数，在数分钟以内，就能将代码下载完毕：

在sync完代码后，所有git库默认都是在一个匿名分支上(no branch)，很容易会由于误操作导致丢失代码修改。可以使用如下命令将所有的git库切换到开发分支：

开发人员可能同时在多个git库，甚至多个分支上，同时进行修改，针对每个git库单独提交代码是繁琐的。可以使用如下命令，一并提交所有的修改：

不用担心会漏提交或者误提交，upload会提供一个交互界面，开发人员选择需要提交的git库和分支即可。

如果需要省去Gerrit上填写reviewer的操作，可以使用–reviewer参数指定Reviewer的邮箱地址：

Git鼓励在修复Bug或者开发新的Feature时，都创建一个新的分支。创建Git分支的代价是很小的，而且速度很快，因此，不用担心创建Git分支的成本，而是尽可能多地使用分支。

随着时间的演进，开发分支会越来越多，而一些已经合并到主干的开发分支是没有存在价值的，可以通过prune命令定期删除无用的开发分支：

对于部分开发人员而言，同时操作多个git库是常态，如果针对每个git库的操作命令都是相同的，那么可以使用如下命令一次性完成所有操作:

参数-c指定的命令序列可以很复杂，多条命令只需要用“;”间隔。

一文读懂 Android 系统的源代码

目前，互联网行业正在朝着移动互联网方向强劲地发展，而移动互联网的发展离不开背后的移动平台的支撑； 众所周知，如今在移动平台市场上，苹果的iOS、谷歌的Android和微软的Windows Phone系统已经形成了三足鼎立的形势，而Android系统的市场占有率是最高的

Android系统之所以能够在市场上占据着第一的位置，一来是因为它依托着谷歌的品德效应和技术实力，二来是因为它是开放的，任何人都可以得到它的源代码，并且能够自由地使用它； 既然Android系统是开放的，作为一个移动平台开发人员来说，当然希望能够深入地去分析和研究它的源代码了，然而，Android系统的源代码非常庞大，我们需要循序渐进地去学习

工欲善其事，必先利其器； 为了全面、深入地理解Android系统的源代码，在正式进入Android系统源代码的世界前，我们需要准备实验环境；此外，还需要了解Android系统的架构知识

按照官方的说法，编译Android 2.3.x及以上版本的系统源码需要64位的系统运行环境来支持，而编译2.3.x以下的版本则需要32位的系统运行环境

官方建议最好预留100G的磁盘空间来下载源码，150G的磁盘空间用来编译源码，如果使用了ccache（一个高速编译缓存工具，可以大幅加快gcc的编译速度），那么则需要更大的空间来支持

所以尽可能地保证自己的磁盘空间够大吧，之前就因为磁盘空间预留不够导致源码编译过程中空间不足，狠狠地把自己坑了一把

如果你是在虚拟机上跑Linux，官方建议至少需要16G的内存空间，我的机器只有8G的内存空间跑虚拟机，目前跑起来也没太大问题，就是编译源码的过程非常漫长，不知道是否跟内存大小有关

Android系统的源码的编译支持 Linux 跟 Mac OS 两种操作系统； 一般情况下，Android系统源码都是在Linux Ubuntu系统上进行开发与测试的，所以如果你准备使用Linux系统来进行源码编译，那一般推荐安装Ubuntu版本的Linux

下面列出了各Android版本与编译系统版本的对应关系：

Linux:

Mac OS：

不同的Android版本编译也需要对应的JDK环境，这里列出了各版本之间的对应关系

开发Android应用程序可以在两种环境下进行； 一是在Android SDK环境下进行，一般是集成在Eclipse里面进行开发，二是在Android源代码工程环境下进行，在这种环境进行开发的好处是可以使用一些在SDK中不公开的接口

但是如果我们要修改Android系统的源代码，或者为Android系统增加新的功能接口，那么就只能在Android源代码工程环境下进行了； 由于我们的目的是对Android系统源代码进行分析，因此，我们在开发Android应用程序时，也在Android源代码环境下进行；这样，我们就需要搭建一套Android源代码工程环境了

目前，Android源代码工程环境只能在Linux平台上使用，而Linux系统的发行版本比较多，这里我们推荐Ubuntu系统； Ubuntu系统是免费的，而且非常易于使用，安装和更新应用程序也非常方便

安装好Ubuntu系统之后，我们就可以在上面下载、编译和安装Android源代码了

Android系统的源代码工程默认是不包含Linux内核源代码的； 如果我们需要修改Android系统的内核或者在里面增加新的模块，那么就要把Android内核源代码一起下载、编译和安装了

Android源代码工程环境搭建好了之后，我们就可以在里面开发新的应用程序或者修改系统代码了； 增加了新的应用程序或者修改了系统的代码之后，不需要重新编译整个源代码工程，只要单独编译有改动的模块就可以了

对于已经开发好的应用程序或者系统功能； 如果想把当作Demo展示给客户来体验时，我们既可以在真机上面运行，也可以在模拟器（Android源代码工程环境或者Android SDK环境都集成了模拟器）上面运行

当我们手头上没有真机，而且我们又不想把整个Android源代码工程环境或者Android SDK环境带去展示我们的Demo时，就可以考虑把模拟器这两个环境中独立出来了

Android系统是按层次、分模块来设计的； 在我们着手对Android系统的源代码进行分析前，需要对Android系统的架构有一个总体的认识，这样我们就能够快速地知道哪些代码位于哪个层次上的哪个模块中，节省搜索代码的时间，把更多的精力投入在源代码的分析上去

整个系统划分内核空间和用户空间两部分； 内核空间包含了进程管理、内存管理以及设备驱动程序模块等，其中Android专用驱动Binder、Logger和Ashmem就是在内核空间实现的

用户空间包含了硬件抽象层（HAL）、外部库和运行时库层（External Libraries & Android Runtime）、应用程序框架层（Application Framework）和应用程序层（Applications）四个层次； 我们应该如何去掌握这个层次结构呢？最好的方法就是从学习Android的硬件抽象层作为切入点了

可能大家会觉得比较奇怪，为什么要把Android系统的硬件抽象层作为学习Android系统架构的切入点呢？

其实是这个层次因为涉及到硬件，看起来这是一个比较复杂和深奥的知识点； 实则不然，Android系统的硬件抽象层在实现和使用上，层次都是非常清晰的，它从上到下涵盖了Android系统的用户空间和内核空间

内核空间主要就是涉及到硬件驱动程序，而用户空间就涉及到了Android系统应用程序层、应用程序框架层和系统运行时库层的相关知识； 因此，学习Android系统的硬件抽象层，可以使大家快速地认识整个Android系统，从而对Android系统得到一个感性的认识，为后面深入分析Android系统的源代码打下良好的基础

学会了编写基本的Android应用程序并且对Android系统的整体架构有一个大概的了解之后，我们就可以去分析Android系统的源代码了

在分析Android源代码的过程中，我们经常进入到应用程序框架层去分析它的源代码； 而在应用程序框架层中，有一部分代码是使用C++来实现的，这时候就会经常碰到智能指针，因此，我们把Android系统中的智能指针也作为一个基础知识点来学习

相信使用过C++语言来做开发的读者对智能指针不会感到陌生； 用C++来写代码最容易出错的地方就是指针了，一旦使用不当，轻则造成内存泄漏，重则造成系统崩溃，因此，系统为我们提供了智能指针，避免出现上述问题

在Android系统中，提供了三种类型的智能指针，分别是轻量级指针、强指针和弱指针，它们都是基于对象引用计数技术来实现的；

轻量级指针的计数技术比较简单，只要对象的引用计数值为0，它就会被释放

强指针和弱指针的计数技术相对比较复杂； 一个对象可以同时被强指针和弱指针引用，但是这个对象的生命周期一般只受强指针的控制，即当这个对象的强引用计数为0的时候，这个对象就被释放了，即使这时候这个对象的弱引用计数不为0

引进强指针和弱指针这种复杂的引用计数技术是为了解决垃圾收集（Garbage Collection）问题而提出的； 考虑这样的一个场景，系统中有两个对象A和B，在对象A的内部引用了对象B，而在对象B的内部也引用了对象A

当两个对象A和B都不再使用时，垃圾收集系统会发现无法回收这两个对象的所占据的内存的； 因为系统一次只能收集一个对象，而无论系统决定要收回对象A还是要收回对象B时，都会发现这个对象被其它的对象所引用，因而就都回收不了，这样就造成了内存泄漏

如果采用强指针和弱指针技术，这个问题就迎刃而解了，即A和B都用弱指针来引用对方

文章基本上就到这里，文章只是对 Android 源码做了一些个人理解的东西，如有地方不对或者有不同理解的可以提出来

有需要获取更多Android相关资讯的同学 可以 私信发送 “进阶” 或 “笔记” 即可 免费获取

现在发送还可以获得 更多《Android 学习笔记＋源码解析＋面试视频》

最后我想说：

对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们

当程序员容易，当一个优秀的程序员是需要不断学习的； 从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人

技术是无止境的，你需要对自己提交的每一行代码、使用的每一个工具负责，不断挖掘其底层原理，才能使自己的技术升华到更高的层面

Android 架构师之路还很漫长，与君共勉

PS:有问题欢迎指正,可以在评论区留下你的建议和感受；

欢迎大家点赞评论，觉得内容可以的话，可以转发分享一下

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com