简介这份面向Android应用开发者的第三方库资料包围绕日常开发中高频使用的视图注入、网络请求、图片加载、依赖注入、事件通信、响应式编程与数据持久化等场景整理了Butter Knife、Gson、Retrofit、OkHttp、Glide、Dagger 2、EventBus、RxJava、GreenDao、Room、LiveData/ViewModel、LeakCanary、Timber等库的相关内容适合初中级开发者查漏补缺也可供有经验者做选型对比。压缩包共2000个文件以xml布局与资源、png图片、json配置、java源码、class字节码以及jar/aar依赖包为主整体约22.67MB便于按库检索和本地查阅。已有1349人学习下载说明其在Android学习群体中具有一定参考价值。读者可从中了解各库解决的问题、典型使用方式和适用边界减少重复实现基础功能的成本并为项目集成与技术选型提供依据。1. 选错一个图片库我在低端机适配会上被按着复盘去年做一个以图片流为主的项目图省事选了当时社区呼声最高的那个加载库功能确实全变换、动画、进度回调一应俱全。上线前在一批 3GB 内存的老机器上跑列表滑到第三十屏开始明显掉帧内存峰值冲到四百多兆监控曲线像心电图。换成另一个更轻的方案同一套列表、同样的图源掉帧率降了七成代价只是少了几个高级变换。这件事之后我把 Android 第三方库的选型从「看谁 star 多」改成「看谁能在下一次升级里活下来」这份清单就是那段时间一份份对比、一次次回滚攒出来的。如果你正在给项目挑库或者刚接手一个依赖几十个第三方库的历史工程下面这些判断依据和踩坑记录能帮你省掉我加班的那几个凌晨。2. 网络层和图片层最费神用四个维度把候选库筛到只剩一个2.1 先立评判维度再谈选谁挑库最容易犯的错是打开搜索页看排行榜。排行榜衡量的是「有多少人用过」不是「适不适合你这个工程」。我现在固定用四个维度打分每个维度 1 到 3 分四项里只要有一项是 1 分这个库基本就不进主链路了——那个 1 分项往往就是半年后返工的起点。第一个维度是包体积增量。做法很土但有效在引入之前打一个 release 包用构建工具自带的包分析器记下 dex 方法数、so 体积和资源占用引入之后再打一个两包对比。有些库主打功能大而全代价是几 MB 的 native 库对安装包敏感的渠道来说这笔账必须先算清楚。我见过一个项目因为三个不同厂商的 SDK 各自带了一份同类的 so光这一项就多出近十兆。第二个维度是线程模型和协程的贴合度。现在新写的代码基本都是挂起函数加 Flow如果一个库的主 API 还是回调加 Handler你就得在中间套一层适配这层适配代码没人维护出了问题是典型的黑匣子。判断方法很简单看它的核心接口有没有 suspend 版本看它内部是不是自己 new 线程池。第三个维度是维护活跃度和破坏性变更频率。不是看最近一次提交时间那么简单要看它的版本号节奏——如果一个库每隔两个小版本就改一次包名或者改一次初始化方式你的升级成本会指数级上升。反过来长期不发布新版本也未必是好事可能意味着它跟不上新的系统行为变更。第四个维度是可替换性也就是有没有一层稳定的抽象。这条最容易被忽略却最能救命。我的习惯是业务代码不直接依赖具体库的类型中间隔一个自己定义的接口库只做实现。换库的时候改一个实现类而不是改三百个调用点。提示四个维度打分只是辅助决策真正要盯的是那个 1 分项。分数可以妥协短板不能。2.2 网络层三选一Retrofit、Ktor 与裸用 OkHttp网络层是绝大多数 App 的骨架选型错了后面全是补丁。这三个候选不是同一个抽象层级的东西放在一起比才有意义。维度RetrofitKtor Client裸用 OkHttpAPI 风格声明式接口声明式接口加 DSL手写 Request 构造协程支持原生 suspend原生 suspend需自行封装包体积增量中等偏大含引擎与插件最小多平台能力有限好有限学习成本低中高适合场景单平台业务 App需要多端共享网络层接口极少的工具或 SDK结论我给得很直接单平台业务 App 用 Retrofit需要多端共享网络层用 Ktor Client只调三五个接口的小工具或者要嵌进别人 App 的 SDK 直接裸用 OkHttp。中间那种「既想轻又想全」的犹豫最耗时间不如按接口数量划线超过十个接口就别手写了。// 声明式接口返回类型直接写业务模型调度交给框架 interface UserApi { // suspend 让调用方直接 await不用回调套回调 GET(v1/user/{id}) suspend fun getUser(Path(id) id: Long): UserDto // Body 走序列化转换器请求体不需要自己拼 JSON POST(v1/login) suspend fun login(Body body: LoginRequest): TokenDto }这段代码的关键在suspend加了它框架会用协程调度器执行请求调用侧写val user api.getUser(1)就够了异常通过 try/catch 捕获。Path会自动做 URL 编码别自己拼字符串中文和斜杠会翻车。转换器只配一个别同时挂两套序列化方案否则类型解析的顺序问题能查一下午。底层客户端我一般只留一个单例超时按业务分普通接口连接 10 秒、读 15 秒上传下载单独建一个客户端放宽到分钟级。拦截器数量控制在三个以内——一个加公共头一个打日志只在 debug 变体启用一个做统一错误码映射。拦截器越多请求链路越像迷宫。2.3 图片层三选一Glide、Coil 与 Fresco图片库的差异比网络库大得多因为它直接吃内存。维度GlideCoilFresco内存策略自建 Bitmap 池复用依赖底层客户端加内存缓存堆外匿名共享内存协程与 Compose需扩展适配原生支持支持较弱包体积增量中小大复杂变换能力强够用中适合场景老项目、重变换新项目、声明式 UI图片极重且内存吃紧新项目我直接选 CoilAPI 是挂起函数风格和现在的写法一致包体积也小。老项目如果 Glide 已经跑稳、用了大量自定义变换别为了「新」去动它迁移的收益抵不上回归测试的成本。Fresco 只在图片体量极大、堆内存频繁告警的场景才值得考虑它的堆外方案确实能压住峰值但接入成本和包体积的代价也是实打实的。真正决定图片性能的不是库是尺寸。列表里的缩略图必须按控件尺寸降采样不给目标尺寸库就会按原图解码一张四千万像素的图能把内存直接打穿。列表快速滑动时暂停加载、停止时恢复这个开关一定要接上。还有onTrimMemory回调里清缓存很多项目压根没写。2.4 序列化Gson 到 kotlinx.serialization 的迁移判断序列化库选错的代价不在性能在空安全。反射型方案会绕过构造器直接填字段Int字段遇到 null 就变成 0String遇到 null 就变成 null线上出现的那些「用户昵称显示 null」多半来自这里。维度GsonMoshikotlinx.serialization空安全反射填充风险高支持代码生成编译期校验最严默认值不生效支持支持混淆成本需 keep 模型类生成后可裁剪无需额外规则多平台不支持支持支持迁移成本基准中中我的判断标准是接口字段多、后端不规范、历史包袱重先用 Moshi 过渡它的代码生成能保住空安全又不要求一次性改完新模块直接上 kotlinx.serialization编译期就能把类型不匹配的问题拦住混淆规则也省了。迁移别一次全切按模块来先切调用链最干净的那个跑一周线上再推下一个。3. 架构三件套怎么配注入、存储、事件流各留一个口子3.1 依赖注入Hilt 与 Koin 的分界线在哪依赖注入这件事小项目觉得多余大项目离不开。Hilt 和 Koin 代表两条完全不同的路线一个是编译期生成一个是运行期查找。维度HiltKoin校验时机编译期写错直接构建失败运行期第一次取实例才报错构建耗时明显增加几乎无影响多模块支持强模块边界清晰需要手动组织模块定义学习成本高注解和限定符多低DSL 直白适合场景中大型、多人协作小项目、快速原型我的分界线是模块数三个模块以上、有明确的 feature 分层、团队超过三个人就上 Hilt编译期把注入错误拦下来这件事在多人协作里价值极高省下的调试时间远超构建多等的那几十秒。反过来一个两周要交付的独立小项目用 Koin 几行 DSL 就配完了没必要为几个依赖关系引入注解处理器。用 Hilt 最容易踩的坑是模块边界。功能模块里定义的绑定应用模块拿不到必须通过接口下沉到基础模块。所以项目初期就要把「哪些是跨模块契约」想清楚等模块多了再补改动面会非常大。Koin 的坑则在运行期定义写错不会报错直到某个页面打开才崩所以配 Koin 的项目必须有一层启动自检把所有模块定义在 debug 构建里先解析一遍。3.2 本地存储Room、DataStore 与 MMKV 各管一摊存储选型的核心是分清你要存什么而不是哪个库更流行。维度RoomDataStoreMMKV数据形态结构化表键值含类型化对象键值查询能力完整 SQL无无线程模型挂起函数与 Flow挂起函数与 Flow同步读写迁移支持版本迁移脚本需自行处理无结构迁移适合场景列表、关联查询配置项、开关高频小数据结论很清楚需要按条件查、需要联表、需要分页排序的用 Room存用户偏好、主题、开关这类配置用 DataStore它天然返回 Flow改了值界面自动刷新高频读写的小块数据比如登录态、最后浏览位置用 MMKV同步读写够快。三种都用不冲突关键是别混用。我见过把用户列表塞进键值存储再用 JSON 反序列化的写法为了查一个字段要全量解析一遍数据量一上来就是灾难。也见过拿数据库存单个布尔开关的为了一个值建表建迁移纯属给自己加活。Room 这边最需要注意的是迁移。生产环境一定要写显式迁移脚本别开破坏性重建用户的本地数据说没就没。每加一个字段就写一个版本迁移测试环境再加一条覆盖全版本的迁移测试这条投入我从来不打折。3.3 事件总线把 EventBus 换到 SharedFlow 的实际路径事件总线在小项目里很爽全局发一个事件到处能收但它的隐式耦合会在项目变大后集中爆发谁发的、谁收的、生命周期对不对全靠人脑记。我现在的默认做法是用 SharedFlow 做作用域内的单向事件流。// 仓库层持有一个热流只暴露只读视图防止外部随意发射 private val _events MutableSharedFlowUiEvent( replay 0, // 不做粘性避免新订阅者收到历史事件 extraBufferCapacity 8, // 缓冲防止发射方被挂起 onBufferOverflow BufferOverflow.DROP_OLDEST ) val events: SharedFlowUiEvent _events.asSharedFlow() // 发射用 tryEmit不阻塞调用线程 fun notifyRefresh() { _events.tryEmit(UiEvent.Refresh) }replay 0是关键参数设成 1 就变成粘性事件页面重建时会重新收到一次容易出现「刷新执行两遍」。extraBufferCapacity给一点缓冲超过就丢最旧的宁可丢事件也不要卡住发射方。收集侧必须在有生命周期的协程作用域里页面销毁自动取消这一点比老式总线的手动反注册可靠得多。迁移时不用一次全拆。先把事件按业务域拆成几个独立的流一个域一个流别搞一个全局大流再逐个把消费方从注册监听改成收集流。什么时候算迁移完当你搜代码里已经没有全局单例的总线对象时就差不多了。4. 避坑与排查五条翻车记录和一套固定动作4.1 五条翻车记录现象、原因、解决第一条debug 包一切正常release 包一进页面就崩。现象是抛类找不到或者方法不存在的异常堆栈里全是被混淆后的短类名。原因是混淆规则没跟上某几个库靠反射找类、找注解代码裁剪阶段把「看起来没人调用」的类删掉了。解决办法是给每个引入的库补 keep 规则序列化模型类、注解类、被反射调用的类都要保开构建产物分析看一眼到底删了什么比猜快得多。补完规则一定要打 release 包真机验证debug 变体不会跑这套流程别用 debug 的结论骗自己。第二条多个库带不同版本的同一个传递依赖运行时报重复类。现象是构建通过、安装成功运行到某个功能点直接崩日志里出现同一路径两个来源。原因是 A 库依赖了某协程库 1.4B 库依赖了 1.6打包时都进了 dex。解决办法是先跑依赖树把冲突点定位出来用平台约束或者 BOM 统一版本实在统一不了的做依赖排除然后显式声明你需要的那个版本。别用强制覆盖了事覆盖后如果 API 不兼容问题会推迟到运行时才暴露。第三条列表滑到一半内存告警监控里图片缓存一路涨。现象是只在特定机型出现图越多的页面越明显。原因是没有按目标尺寸解码加上缓存策略用了默认值原图被完整读进内存还长期持有。解决办法是三件事一起做所有列表图片都指定目标宽高、给缓存设置上限并按内存等级清理、页面不可见时暂停加载。改完再看峰值通常能降一半以上。这条属于典型的血泪经验光换个库解决不了。第四条冷启动时间莫名多了四百毫秒代码没动过。现象是新增一个统计或推送 SDK 之后启动耗时曲线整体上移。原因是这类 SDK 喜欢用启动自动初始化的机制把自己的初始化塞进应用启动流程还不在你的代码里。解决办法是查合并后的清单文件确认是哪个组件在自动初始化按官方方式关掉自动初始化改成首帧渲染之后再手动初始化。不是所有 SDK 都能关不能关的就评估要不要换。第五条升级了某个库的新大版本编译全绿运行时偶发闪退。现象是概率性的可能几十次才崩一次堆栈指向框架内部。原因是破坏性变更里有一条改了线程模型原来的回调现在在子线程执行而界面更新在主线程。解决办法是升级前先读完变更说明重点看线程、生命周期、默认值这三类改动升级后不要只看编译结果把涉及该库的所有页面手动过一遍复杂项目直接补一套回归清单。4.2 出问题后的固定排查顺序踩坑踩多了就形成肌肉记忆我现在遇到依赖问题按固定顺序走不做跳跃。第一步永远是看依赖树别猜。跑一次编译期依赖报告把输出重定向到文件按坐标搜冲突版本。这一步能解决七成的重复类和版本不一致问题而且成本最低。# 导出 release 变体的完整依赖树用于对比版本冲突 ./gradlew :app:dependencies --configuration releaseRuntimeClasspath deps.txt # 定位某个具体依赖被谁引入以及最终解析到哪个版本 ./gradlew :app:dependencyInsight \ --configuration releaseRuntimeClasspath \ --dependency kotlinx-coroutines-core第一个命令输出的是整棵树重点看那些被标记为版本冲突的条目箭头指向的就是最终生效版本。第二个命令更有针对性给定一个库名它会告诉你哪些上游把它带进来、每一条路径请求的版本是多少、为什么最后选了某个版本。查冲突时优先用第二个输出短、信息密度高。第二步看产物。把 release 包拖进包分析器看 dex 里到底有没有那个类看 so 目录下每个架构的体积分布。有些问题在依赖树里看不出来因为打包阶段有额外的裁剪和合并动作。第三步才是运行时验证。打开严格模式的线程与资源检测跑一遍核心链路把主线程磁盘读写、未关闭的流、泄漏的实例都揪出来。这一步能发现那些「功能正常但迟早出事」的隐患。注意依赖问题不要靠反复清理缓存和重启 IDE 解决。构建缓存只是放大器不是根因清了能跑通大概率是增量编译掩盖了冲突。5. 依赖治理把「库多到失控」变成可量化的清单5.1 版本对齐版本目录加 BOM先把地基压平库一多版本号散落在各个模块的构建脚本里改一个版本要全局搜索替换还容易漏。第一步是把所有版本号收拢到一个版本目录文件里坐标和版本分离。# gradle/libs.versions.toml所有版本集中在一处模块只引用别名 [versions] coroutines 1.7.3 # 协程统一版本全项目唯一来源 retrofit 2.9.0 [libraries] coroutines-core { module org.jetbrains.kotlinx:kotlinx-coroutines-core, version.ref coroutines } coroutines-android { module org.jetbrains.kotlinx:kotlinx-coroutines-android, version.ref coroutines }这样改版本只改一处模块里写implementation(libs.coroutines.core)版本冲突从源头少了一大半。对于官方提供物料清单的库族优先用物料清单约束版本它保证同一族里所有组件互相兼容不用你一个个对。没有物料清单的就在构建脚本里加版本约束块把关键依赖的版本钉死让传递依赖乖乖就范。这一步做完依赖树会短一截后续排查也轻松。5.2 体积与裁剪R8 规则和 so 过滤的实操体积治理的核心思路是「能裁就裁能只打一个架构就不打四个」。代码侧开代码压缩和资源压缩把用不到的类、资源、语言包全部剔掉native 侧用架构过滤只保留主流架构其余走兼容方案。// 只保留两个主流 ABI其余架构由兼容包兜底 android { defaultConfig { ndk { abiFilters listOf(arm64-v8a, armeabi-v7a) } } buildTypes { release { isMinifyEnabled true // 开启代码压缩与混淆 isShrinkResources true // 开启无用资源裁剪依赖混淆结果 proguardFiles( getDefaultProguardFile(proguard-android-optimize.txt), proguard-rules.pro ) } } }isShrinkResources依赖isMinifyEnabled两个必须一起开只开资源裁剪不会生效。混淆规则文件里按库分组写注释谁加的规则、为什么加写清楚否则半年后没人敢删。每条规则都要能对应到一个具体的运行时问题写不出理由的规则大概率是历史遗留删掉之前跑一遍回归。还有个细节很多库自带消费者规则会自动合并进来不需要你手写。所以遇到崩溃先确认这个库有没有自带规则别急着自己写一条宽泛的通配规则那等于把整个包都保下来体积白白变大。5.3 定期体检三步把隐形依赖挖出来依赖治理不是一次性动作我一般每个版本周期做一次体检三步走。第一步导出依赖清单按引入来源分组看有没有同一个功能被两个库重复实现——两个网络客户端、两个图片加载器、两个日志框架这类重复最占体积也最容易出诡异问题。第二步看每个库的最近使用位置搜一遍调用点超过半年没人碰的库列进待删清单下个版本安排移除。第三步回归体积曲线把每个版本的安装包大小记下来一旦某个版本突然涨了几百 K立刻定位是哪个改动带进来的这时候查最省力。这套动作花不了半天但能避免「项目做了三年没人说得清依赖了多少个第三方库」这种局面。等到不得不治理的时候成本已经是平时的十倍。6. 落到一张最小清单新项目我会这么配把上面所有判断收拢成一张表这是我现在的默认配置新项目直接照抄遇到特殊情况再逐项调整。层默认选择什么情况下换网络声明式接口库加单一客户端多端共享网络层换多平台方案接口少于十个裸用客户端图片轻量协程图片库老项目已稳定运行且重度使用自定义变换则不迁序列化编译期序列化历史接口字段混乱先用代码生成方案过渡注入编译期注入框架单模块小项目或原型用轻量运行期方案存储数据库加类型化键值高频小块数据补充同步键值存储事件作用域内的热流跨进程或跨模块解耦再考虑总线方案配套三条硬规则写进团队规范里业务代码不直接依赖具体库的类型中间必须隔一层自己定义的接口任何新库引入前先打两个包对比体积增量超过阈值的必须给出理由每个版本周期做一次依赖体检把没人用的库清出去。回过头看我踩过最大的坑不是选错了某个库而是没有及时换掉它。当时想着「先用着以后再说」结果这个库的 API 渗透进了二十多个页面再想换就得排一个迭代的工期还得全量回归。从那以后我每次引入第三方库之前都会强制走一遍「抽象层加体积对比加退出方案」这三步哪怕是个只有两个方法的小工具库也要先想清楚怎么把它摘出去。这份清单你可以直接拿去对也可以只挑其中一层先用起来。希望帮到你。本文还有配套的精品资源点击获取