Android开发中依赖AAR文件的优势与适用场景解析

在Android应用或库项目中，最常用的远程Maven依赖写法如下：

implementation "xxx.yyy.lib-name:{$libVersion}"

除此之外，也支持直接依赖AAR文件的引入方式：

implementation files('libs/file-name.aar')

这种方式直接使用已经构建发布完成的aar文件，文件可以提前下载到本地项目目录，也可以从制品库拉取后落地存储。

直接依赖AAR的核心优势 #

• 接入流程极简：不需要额外配置专属Maven仓库地址，不用处理仓库鉴权、网络白名单这类杂项，把AAR放到对应目录加一行配置就能直接用，完全不会碰到远程仓库宕机、历史版本被官方下架导致项目突然编译失败的问题
• 依赖内容完全可控：本地存储的AAR是什么内容，最终打包进安装包的就是什么内容，不会出现远程仓库同版本包被篡改、植入恶意代码的情况，依赖一致性极强
• 构建效率更高：Gradle同步和编译阶段会跳过远程仓库索引拉取、版本校验、包下载缓存的流程，直接读取本地文件，在多模块、依赖量级大的项目里，同步和编译速度的提升会非常明显
• 定制修改灵活：如果需要调整第三方SDK的内部逻辑、适配项目特殊配置，不需要拉取SDK完整源码重新构建，直接修改AAR内的对应代码、资源后替换文件就能生效，不用等SDK官方排期发版

推荐选择AAR直接依赖的场景 #

• 对接没有发布到公开Maven、也没有内部私有Maven服务的第三方SDK时，对方直接交付AAR文件的情况下，本地依赖是成本最低的接入方案
• 项目需要做版本固化、保障可复现构建时，比如发布线上正式版本前，把所有核心依赖的AAR都落地到项目仓库，哪怕隔很长时间拉取对应历史版本的代码，也不会因为远程仓库变动导致老代码无法编译
• 小团队内部跨项目复用公共组件，暂时没有精力搭建私有Maven服务时，直接输出AAR给各业务项目接入，比拷贝源码模块的方式更轻量，也能避免公共模块的核心源码随意泄露
• 第三方SDK存在bug或适配问题，等不及官方排期修复时，可以自行修改AAR内容后通过本地依赖替换，快速解决问题上线
• 封闭内网开发、离线开发场景下，无法连通外部Maven仓库时，提前把所有依赖的AAR存储到本地，不需要网络就能完成全量编译构建

内容的提问来源于stack exchange，提问作者lannyf