简介这是一份面向Android开发者的常用第三方库速查资源系统整理了Butter Knife、Gson、Retrofit、OkHttp、Picasso、Glide、Dagger 2、EventBus、RxJava、GreenDao、Room等主流库涵盖视图绑定、网络请求、JSON解析、图片加载、依赖注入、组件通信、响应式编程、数据库访问、生命周期管理等开发高频场景同时说明每类库的适用位置与独特价值帮助开发者建立清晰的技术选型框架。压缩包共2000个文件以xml、png、json类型为主其中xml多用于布局与配置png为界面或示例图片json承载数据样例另有java源码、class文件、jar/aar库文件等整体体积约22.67MB资源组织较系统便于按模块查阅。当前已有1348人学习适合从入门到进阶的Android开发者。内容不只是罗列工具清单还结合实践场景解释各库核心特性例如Retrofit与OkHttp配合网络请求、Glide处理大图与视频缩略图、Room简化SQLite操作、LeakCanary自动发现内存泄漏等读者可据此快速上手并在项目中灵活选用提升开发效率与应用质量。 说实话见过太多入行两三年的人被问“项目里用了哪些第三方库”时只能讲出Glide和Retrofit再多就卡壳了。Android开发是个极度依赖第三方库的领域——网络、图片、缓存、依赖注入、线程切换几乎每一层都有成熟的开源方案帮你把最脏最累的活做完。但“会用”和“会选、会避坑、会管理依赖”完全是两码事。这篇文章我不会给你一份“史上最全的100个库”清单那种列表翻完收藏夹吃灰根本没意义。我更想从实战角度把这些年我验证过、踩坑过、最后稳定下来的选型经验讲透。1. 谈库之前先把“要不要用库”这件事想清楚1.1 库不是零件越多越好先看清它的隐形成本很多新人有个错觉引入的库越多项目越“高级”。但每个第三方库的引入都是一笔负债不是资产。它至少带来四层成本依赖体积一个库连同它的传递依赖可能给APK增加几MB甚至几十MB直接影响下载转化率。初始化耗时不少库需要在 Application 里初始化加得多了会影响冷启动。版本冲突库A依赖Gson 2.8库B依赖Gson 2.10Gradle 在解析依赖树时可能直接报错或者某个库用了被删除的API编译期才炸出来。学习与维护成本项目里每个库团队都需要有人懂、有人能修。作者停更之后迁移路径往往比当初封装还痛苦。所以我的建议是遇到需求先想“官方有没有”再想“社区抄近路”最后才想“自己造”。这个顺序能帮你挡掉至少一半的不必要依赖。1.2 一个场景该不该上库的四条判断标准判断要不要引入一个第三方库我通常问自己四个问题这个功能是不是项目的核心竞争力如果是尽量不要依赖别人的实现尤其是支付、音视频编解码这类底层逻辑。官方AndroidX或者Jetpack里有没有等价方案比如后台任务WorkManager已经覆盖了你能想到的大部分场景没必要再引一个Job库。这个库的维护状态是否健康看最后一次release日期、star趋势、issue回复速度超过一年没更新的库要非常谨慎。我用官方API手动实现代码量大概是多少如果不超过200行或者只是把一个进度条换个圆角样式就别引库了。网上关于“android进度条”的搜索很高频很多人上来就搜自定义控件库。其实Material Components里的LinearProgressIndicator和CircularProgressIndicator已经覆盖了绝大多数场景还自带动态颜色和无障碍支持。这种就是典型的不该上第三方库的需求。1.3 Android引入库的方式和“安装第三方库”根本不是一回事这里要特别提醒一下跨语言过来的新手。搜“第三方库怎么安装”搜出来大量Python相关的pip install教程那套思路在Android里完全不适用。Android引入第三方库是通过构建工具完成的在build.gradle.kts里声明依赖坐标group、name、versionGradle 启动时从Maven仓库Google Maven、Maven Central拉取AAR/JAR由AGPAndroid Gradle Plugin完成打包// app/build.gradle.kts dependencies { implementation(com.squareup.retrofit2:retrofit:2.11.0) implementation(com.squareup.okhttp3:okhttp:4.12.0) }理解这一层你就能明白为什么“android studio每次新建项目都要下载gradle”这类问题那么普遍——本质不是库的问题是构建工具链和依赖仓库的版本匹配问题后面第3章会展开讲。2. 我把高频第三方库按功能拆成五块地图2.1 网络层OkHttp、Retrofit、Ktor 各自的位置网络层是Android工程最不可能绕开的第三方库。三个关键词基本把分工说清楚了OkHttp底层的HTTP客户端负责连接池、HTTP/2、拦截器、超时控制。它是“轮子”Retrofit是踩在它上面的“车壳”。Retrofit把REST接口声明成Kotlin接口方法通过注解和Converter完成序列化/反序列化配合协程的suspend函数写起来非常清爽。Ktor ClientJetBrains家的KMP方案协程原生适合需要多端共用一套网络代码的项目。我自己的标准配置是OkHttp Retrofit GsonConverterFactory再加一个日志拦截器并在Release包关闭日志输出val okHttpClient OkHttpClient.Builder() .addInterceptor(HttpLoggingInterceptor().apply { level if (BuildConfig.DEBUG) HttpLoggingInterceptor.Level.BODY else HttpLoggingInterceptor.Level.NONE }) .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(15, TimeUnit.SECONDS) .build() val retrofit Retrofit.Builder() .baseUrl(BuildConfig.API_BASE_URL) .client(okHttpClient) .addConverterFactory(GsonConverterFactory.create()) .build() interface ApiService { GET(user/info) suspend fun getUserInfo(Query(id) id: String): ApiResponseUserInfo }Ktor Client我一般只在KMP项目里推荐单Android端没必要引入因为OkHttp生态太成熟了拦截器、WebSocket、MockWebServer测试方案要啥有啥。2.2 图片加载Glide、Coil 二选一就够了图片加载库也是手机装机必备。目前主流就三个Glide、Coil、Fresco。对比维度GlideCoilFresco底层实现自研缓存 可接OkHttpKotlin协程实现C So库架构包体积中等偏小偏大生命周期感知有有有Compose支持需要额外适配原生AsyncImage较弱适用场景大多数Android项目纯Kotlin/Compose新项目极重度图片信息流Glide的优势是生态最成熟几十种Transformer、占位符、缩略图方案随便搜都有Coil的优势是轻量和Compose友好AsyncImage直接传URL就能加载AsyncImage( model https://example.com/image.jpg, contentDescription null, modifier Modifier.size(128.dp) )Fresco的内存控制确实强但代价是复杂的So加载逻辑和偏大的SDK体积普通项目没必要用。我的建议很简单老项目继续用Glide新项目如果是纯Kotlin Compose直接Coil。2.3 异步与响应式RxJava 时代的存款和现在的协程聊到异步必须承认RxJava曾经是Android的王者。链式操作符map、flatMap、concatMap、线程切换、背压处理功能确实强大但学习成本也惊人——很多人写RxJava代码写着写着就变成了只有自己能看懂的“天书”。现在的共识是新项目用Kotlin协程 Flow存量老项目如果RxJava跑得稳没必要强行迁移。协程更贴近同步代码的写法结构化并发也比RxJava的订阅生命周期更好管理viewModelScope.launch { val user repository.getUserInfo(userId) _uiState.value UiState.Success(user) }Flow替代了大部分RxJava的操作符场景像map、flatMapLatest、combine都有对应API。背压场景用conflate()或buffer()也够用了。唯一要提醒的是别再引rxjava相关的新库了你已经走在技术栈迁移的路上没必要在旧车上继续加零件。2.4 依赖注入与本地存储Hilt/Koin、Room/DataStore依赖注入是大型项目绕不开的架构环节。HiltGoogle官方推荐的Dagger封装编译期生成代码性能好、和ViewModel/WorkManager等组件的集成是官方级的。代价是注解处理会让构建时间变长而且报错信息对新手不太友好。KoinKotlin DSL风格的运行时注入无代码生成启动快写起来直观。缺点也很明显错误只能运行时暴露调一个因为依赖没声明而NPE的问题可能要看半天日志。我个人的倾向是团队刚起步、不想在注解处理上折腾选Koin足够如果项目规模已经到几十个模块或者你想在架构上更贴近Google官方范式直接上Hilt。本地存储这块Room和DataStore已经是官方指定的答案。Room在SQLite之上封装了编译期SQL校验、DAO接口和Flow返回写起来非常舒服Dao interface UserDao { Query(SELECT * FROM user WHERE id :id) fun observeUser(id: String): FlowUserData }DataStore替代SharedPreferences基于文件存储和事务机制支持Flow监听变化。至于曾经火的Realm优点在API很对象化但包体积和类替换机制在现在反而成了负累新项目我不建议入坑。2.5 UI 组件Banner、刷新、图表在 Compose 前后的区别UI类第三方库是变化最剧烈的一块。以热搜里的“协调布局banner”为例那是典型的XML时代首页结构CoordinatorLayout做联动Banner做轮播再加一个下拉刷新。当年比较流行的是各类Banner开源库配合SmartRefreshLayout。但到了Compose时代情况变了// Compose 里实现Banner的核心就是HorizontalPager HorizontalPager(state pagerState) { page - AsyncImage(model banners[page].imageUrl, contentDescription null) }一个轮播图在Compose里几乎不需要第三方库HorizontalPagerAutoCarousel自己写很快就搞定。图表库也一样过去的MPAndroidChart在Compose里用起来很别扭新选择是Vico、YCharts这类“Compose-first”的库。所以我的建议涉及UI的库先看它是不是Compose原生再看维护状态。很多XML时代的UI库停更极快不建议在新项目里继续引。3. 第三方库集成里的三大坑依赖冲突、混淆、构建版本3.1 依赖冲突的定位链路别猜用命令查依赖冲突是引入第三方库时最常报的错。典型的报错长这样Duplicate class com.google.gson.internal...这种“Duplicate class”错误说明依赖树里有多个版本的同一个库。很多人这时候直接去改Gradle文件凭感觉加exclude运气好能编过但根本不知道根因在哪。正确的排查链路是用Gradle自带的可视化命令./gradlew :app:dependencyInsight --dependency gson --configuration debugRuntimeClasspath这条命令会列出app模块的运行时依赖路径里所有和gson相关的依赖是从哪个库传递进来的。看到像下面的输出就一目了然com.google.code.gson:gson:2.10.1 installDebugRuntimeClasspath ├─ com.squareup.retrofit2:converter-gson:2.11.0 └─ com.tencent.mmkv:mmkv:1.0.23解决办法优先级从高到低是升级主库版本让它传递的依赖覆盖旧版本而不是到处exclude。用全局resolutionStrategy强制统一版本但只在你确认兼容的前提下做。局部exclude这是最后手段因为exclude会让依赖关系变得不可追踪。3.2 混淆配置release 崩溃的“隐形凶手”依赖冲突是编译期报错混淆问题则是运行时黑盒。一个Debug跑得好好的App打Release包后一进页面就崩十有八九是混淆规则没配好。原因很简单R8在混淆时会把类名、方法名重写成abcdef如果某个第三方库内部用了反射它按名字找类就找不到了直接抛ClassNotFoundException或NoSuchMethodException。解决思路有两个方向优先用官方proguard规则。大部分主流库OkHttp、Retrofit、Glide、Gson都内置了consumer rules会在引入时自动打进AAR的proguard.txt不需要你手动配置。对反射重灾区手动keep。常见的需要手动keep的是Gson序列化实体类、EventBus/ARouter这类路由索引库以及所有自己写了注解反射的框架。给Gson的实体类加keep规则时注意数据类字段也不要被混淆-keep class com.example.api.response.** { *; }每次发版前至少在Debug和Release两个包上跑一遍主流程回归。别等用户反馈“Release版崩溃”再去翻日志那个成本高得多。3.3 AGP 与 Gradle 版本匹配新建项目反复下载的根因“android studio每次新建项目都要下载gradle”这个热搜说明很多人栽在构建工具链上。这个问题虽然不完全是第三方库但它直接影响第三方库能不能拉下来。根因是Android Studio版本、AGP版本、Gradle版本三者之间有严格的对应关系。比如AGP 8.5要求Gradle 8.7及以上如果你项目里gradle-wrapper.properties写的distributionUrl版本低于AGP要求Gradle会因为不兼容跑不起来然后Studio尝试下载匹配版本的Gradle每次新建项目如果wrapper版本没统一就在重复下载。# gradle-wrapper.properties distributionUrlhttps\://services.gradle.org/distributions/gradle-8.7-bin.zip解决方案是团队内部统一一套版本矩阵AS版本 AGP版本 Gradle版本 JDK版本写进团队文档。别指望每个人本地都能自动匹配这不是运气问题是工程规范问题。4. 选型逻辑正在被 AndroidX 和 Compose 重塑4.1 官方组件取代了一大波第三方库以前需要第三方库解决的事情Jetpack现在基本都官方化了后台任务WorkManager 取代了各种自研任务队列和Job库分页加载Paging 3 取代了各种列表加载库数据持久化DataStore 取代了SharedPreferences封装库拍照CameraX 取代了大部分第三方拍照库崩溃处理Google Play还自带崩溃报告第三方统计库除外判断一个库是否值得引入先查AndroidX里有没有同名组件是个好习惯。如果官方已经提供那么第三方库的价值就只剩下“官方太基础、不值得自己写”的部分。4.2 Compose First 成了新库的前置门槛Compose普及后选第三方库必须多问一句这个库是Compose原生的吗不是说非Compose不能用而是非Compose的UI库在Compose里用起来极其别扭需要包一层AndroidView去桥接事件回调、状态管理、重组都割裂。反观Coil这种库官方直接提供AsyncImageRoom的Flow查询天然适配Compose的状态流。这种“围绕Compose设计”的库用起来体验是质的差别。所以现在评估一个UI库我甚至会把“Compose First”排在“功能丰富度”前面。不是因为它炫技而是它代表这个库作者还在跟进现代Android开发维护状态大概率也更健康。4.3 定期清理“僵尸依赖”是一项长期工作依赖树里的僵尸库比你想的多。很多项目跑着跑着某个库已经没人用了但Gradle依赖还待在build.gradle.kts里还带着一整套传递依赖。我的习惯是每个季度干一次这件事./gradlew :app:dependencies --configuration debugRuntimeClasspath deps.txt扫一遍输出看看哪些库自己压根没在代码里import过。搜索代码里对应的包名确认没有引用后直接从Gradle里删掉。删完后重新构建一次能过就说明确实是僵尸依赖。这个动作最大的价值不是瘦身APK而是降低混淆规则的维护成本。因为每个库的keep规则和反射配置都可能成为下一次release崩溃的隐患能少一个是一个。5. 我从零搭工程时的库引入顺序和评审清单5.1 引入顺序新建一个项目时我习惯按下面这个顺序引入第三方库每一层都是下一层的基础基础工具层Kotlin协程、AndroidX Core KTX、Lifecycle组件网络层OkHttp Retrofit 序列化库图片层Coil 或 Glide架构层Hilt或Koin、ViewModel、RoomUI层Material Components 优先特殊组件图表、轮播再单独评估先搭网络和图片是因为可以立刻动手写页面架构层早点定是因为后面几十个模块不可能再回头重构UI层最后考虑是因为官方Material库能覆盖大部分基础控件。5.2 用 Version Catalog 统一锁版本团队项目最怕的就是每个人在自己的模块里写死不同的依赖版本。Gradle推荐的Version Catalog能把这个坑堵上。在gradle/libs.versions.toml里统一管理版本号[versions] retrofit 2.11.0 okhttp 4.12.0 coil 3.0.4 [libraries] retrofit { group com.squareup.retrofit2, name retrofit, version.ref retrofit } okhttp { group com.squareup.okhttp3, name okhttp, version.ref okhttp } coil-compose { group io.coil-kt.coil3, name coil-compose, version.ref coil }这样每个模块引入依赖时只用引用一个key版本集中在同一个文件里维护升级依赖时也只需改动一处。5.3 引入新库前的 CheckList最后分享一个我每次引入新库前都会过的清单你可以直接抄走这个库最后一次release是什么时候超过一年pass。它的GitHub issue是不是已关闭一堆没回复是pass。最低API版本是否低于项目的minSdk低于会提高兼容成本慎重。依赖树是否和现有库冲突拉一下dependencies --configuration先看一眼。官方AndroidX是不是已经有等价方案有先考虑官方。它是不是Compose友好的在UI库里这条尤其重要。许可证是否允许商用GPL类的库要特别小心。说实话做Android的时间越长我对第三方库的态度反而越保守。刚工作那会儿恨不得把所有好看的开源库都塞进工程里光是轮播图就换过四五个库。后来维护的代价全部还回来了要么是作者停更之后找不到迁移路径要么是一个小功能拖着一个巨大的依赖树。我现在给团队定的原则很简单——能让主要业务开发效率提升两倍以上的库才值得引入官方方案能解决的就别去翻GitHub。按这个标准筛下来一个中型App里同时存活的第三方库基本不会超过20个维护成本完全可控。愿你也能早点想明白这个道理少走一些弯路。本文还有配套的精品资源点击获取