作为一个常年混迹GitHub的Android开发我手机里收藏夹的星标数量比微信未读消息还多。每次换电脑、重装系统第一件事就是赶紧把那些攒了好几年的开源项目链接重新找回来生怕哪个好用的库从此失联。于是去年年底我干脆做了个决定把自己从入门到现在看过、用过、踩过坑的Android开源项目和文章系统整理成一个合集持续更新当作自己团队的内部资源库也顺便分享给身边刚转Android的朋友。这就是这份“Android 开源项目和文章集合”的由来最近一次更新是2022年3月21日。它不是什么大厂出品也没有花哨的官网就是一个普通开发者每天在地铁上、深夜里慢慢攒出来的干货仓库。里面从开发环境搭建、基础控件使用到Jetpack全家桶、性能优化、音视频处理、面试刷题基本覆盖了Android开发日常会碰到的所有场景。如果你正处在“收藏了无数文章但真到用的时候找不到”的阶段或者刚入行不知道从哪开始积累这份合集应该能帮你省下不少时间。1. 这个集合到底解决了什么问题1.1 从“收藏夹爆炸”到“分类索引”我相信大多数开发者的浏览器收藏夹都是一片混乱。今天看到一个Kotlin协程的讲解收藏明天又刷到自定义View的实战再收藏。等到真要做某个功能的时候面对几十个没分类的书签只能凭着模糊的记忆一个一个点开找效率极低有些过时的文章还会把你带进坑里。当时我整理这份集合的初衷就是不想再因为“明明看过但死活找不到”而重复造轮子。所以我把内容分成了几个大类开发环境和工具、基础组件和UI、架构与模式、性能优化、网络与数据存储、音视频和多媒体、开源库推介、以及面试题汇总。每个条目都标注了项目名称、简介、GitHub链接或原文地址有的还附带了我在实际项目里的使用评估。比如说热词里提到的“android studio dolphin | 2021.3.1 patch 1 安装教程”和“android studio怎么设置中文”这类问题每天都有新人在群里问。我就会在集合的“环境准备”板块里专门整理一份Android Studio从下载、汉化到配置Git的完整指引JDK版本怎么对应、SDK Manager该勾选哪些组件、模拟器怎么加速都写得明明白白。这样新人照着做就能跑通第一个Hello World不用在各大论坛里大海捞针。1.2 适合谁来看这份集合我的体会是这个集合最适用的人群是两类。第一类是刚入坑Android开发不久的新人他们需要知道当前社区的主流方案是什么避免一头扎进十年前的老框架里出不来。第二类是像我这样做了两三年的开发脑子里功能大概知道怎么实现但需要快速确认某个库的最新版本、某个API的替代方案或者想系统查漏补缺时有个整理好的索引会方便很多。有朋友问我为什么不定时更新非要把日期标得这么清楚。其实很简单Android生态变化太快了今天还在推荐的库明天可能就被官方组件取代某个问题的标准答案半年后就变成了错误示范。标注更新日期相当于告诉阅读者这份内容里截止到这个时间点信息是经过验证的之后如果你看到更优的解法请以官方文档和社区最新讨论为准。这是一个负责任的资源集合应该有的态度。2. 我是怎么筛选和整理开源项目的2.1 筛选标准不是“星标多”就收很多人整理开源项目喜欢按GitHub star数从高到低全列一遍我一开始也这么干过后来发现这样并不实用。一个项目星标多可能只是因为发布时间早、蹭到了某个热门话题不代表它现在依旧维护良好、没有致命bug、API设计合理。我踩过最大的坑就是项目A在某个技术博客里被吹上天结果引入项目后发现它的维护者两年前就断更了issue里全是反馈崩溃的只能自己fork下来改白白浪费两个晚上。所以现在我的筛选标准核心是三条第一有活跃的维护记录最近半年内至少有一次提交或回复issue第二有清晰的README和示例代码不看源码单靠文档就能跑起来第三在github上能查到真实的、非水军的issue讨论和star增长曲线如果增幅平缓但稳定说明用户口碑比较扎实。至于文章我更看重的是“作者是否还在持续输出”和“内容有没有被后续版本推翻”。就拿热词里提到的“android音频 - 支持多应用同时录音_android9.0修改方法”来说这类涉及系统源码修改的文章如果不附带具体版本号和修改前后对比基本没法用。收进合集时我会额外备注“该方案基于Android 9.0验证Android 10可能不适用”避免后来的人拿着旧方案去适配新系统。2.2 分类是骨架注释是血肉光把链接扔进一个issues列表里还不够真正的价值在于每个条目下的两行注释。我会写上这个项目是做什么的、适合放在哪个业务场景、有没有替代方案、集成时要注意什么以及我自己用下来的直观感受。例如热词中反复出现的“content://com.tencent.wework.fileprovider/external_path/android/data/com”这类FileProvider权限问题很多文章只给了代码片段但没说清楚为什么不同App的authorities会冲突、为什么外部存储路径要区分主目录和缓存目录。我在合集里整理FileProvider专题时就把不同应用微信、QQ、企业微信的provider路径冲突常见报错汇总成了一张表方便大家排查。2.3 持续维护比一次性写完重要说实话第一次整理这份集合花了我大概四个周末的时间。刚开始我以为写完了就完事了后来发现远远不是。每隔一两周我会花半小时到一小时清理一遍看看之前收进来的文章有没有被官方文档取代、某个库是不是推出了不兼容的大版本、自己团队项目里是否验证过某个新方案可行。2022年3月21日这次更新的内容里就是增加了几个新的开源项目推荐并修正了部分旧链接和失效的文章地址。如果你也想维护自己的技术资源合集我建议别一开始就想做到完美先搭个粗略的架子然后在日常工作中遇到什么补什么让这个文档像代码一样跟着项目一起演进。分类太粗没关系先能定位到东西再慢慢调整结构比憋大招式的一次性整理靠谱得多。3. 集合里的几个重点模块和实操参考3.1 环境搭建Android Studio和SDK相关的坑Android开发的第一步就是装环境但这第一步就能劝退不少人。热词里“android studio下载”“android studio安装教程”“android studio汉化”“android studio 配置git”“android studio怎么设置中文”这类词常年霸榜搜索记录说明环境问题确实是拦路虎。我在合集里专门有一节是安装和配置指南重点写了几件事。首先是版本选择我个人的经验是优先用稳定版不要一发布新版本就急着升级除非你需要新版本里的某个特性。2022年3月前后不少人还在用Android Studio Dolphin2021.3.1和北极狐版本这些版本都有个共同特点JDK版本捆绑合理Gradle插件兼容性比较稳。文章里我都会列出一个经过验证的组合Android Studio版本、Gradle版本、Gradle Android插件版本、JDK版本这几个必须对齐否则会出现各种莫名其妙的编译错误。其次是汉化问题。新版本Android Studio其实自带中文语言包插件市场里搜Chinese就能找到安装后重启就是中文界面。但不少教程都把过程做得很复杂。我在集合里写的是最简步骤File → Settings → Plugins → Marketplace然后搜索中文安装重启。安装之后不影响任何功能适合英文界面比较吃力的新手。再就是配置Git。Android Studio里的Git集成虽然内置但有个容易卡住的地方SSH key的生成和配置。很多人直接在Settings里填了账号密码结果每次push都要输入一遍麻烦不说换了电脑又得重新配。我的做法是生成SSH key之后把公钥配到GitHub或GitLab然后在Android Studio里选择SSH方式克隆仓库一劳永逸。这块我还专门写了Windows、macOS、Linux三种系统下的生成路径方便对照操作。3.2 UI与自定义View进度条、协调布局与Banner集合里有一块我自己特别看重的部分就是UI相关的开源库和文章。Android的UI实现方案变化太快从最早的XML写界面到DataBinding再到现在的Jetpack Compose每一步都有一堆新东西要学。但我发现无论架构怎么变基础的UI组件知识永远是刚需比如热词里提到的“android进度条”“android中协调布局banner”。关于协调布局和Banner我遇到过最典型的一个场景首页需要一个上滑时折叠顶部搜索栏、同时支持轮播图跟随滚动的效果。用传统方式写得同时处理CoordinatorLayout的Behavior、ViewPager2的滑动事件、Banner轮播的自动滚动稍不留神就会出现滚动冲突、轮播卡顿的bug。我在合集里整理了两种思路一种是纯原生通过自定义Behavior让Banner随着AppBarLayout联动适合不想引入额外依赖的场景另一种是直接使用开源库比如当时社区里比较成熟的Banner库配合CoordinatorLayout用AppBarLayout.ScrollingViewBehavior就能实现大部分效果适合项目里已经引了相关依赖的团队。写这套整理的时候我特意记录了一个容易忽略的细节CoordinatorLayout里的Banner如果高度是wrap_content那么AppBarLayout在折叠时的高度计算出错会出现标题栏没有完全隐藏的问题。解决办法是把Banner的高度固定为一个dp值比如根据设计稿算出比例1920x1080下用180dp或者动态监听图片加载完成后重新请求layout。这类问题官方文档不会告诉你只有真跑过一遍才知道。3.3 文件与权限FileProvider和外部存储路径的坑热词里出现了好几个形如“content://com.tencent.wework.fileprovider/external_path/android/data/com”的搜索记录这其实反映了一个非常普遍的痛点在Android 7.0及以上系统中App之间传递文件uri不能直接传file://路径必须通过FileProvider转成content://格式。不同App用相同authority还会冲突报错日志里显示“Failed to find configured root”很多新手看到这行就懵了。我在集合中专门有一篇长文整理FileProvider的用法核心内容包括在AndroidManifest.xml里声明provider节点、在res/xml里配置paths、以及在代码中通过FileProvider.getUriForFile()生成content:// uri。更重要的是我记录了不同常见App微信、QQ、企业微信分享文件时的路径特征方便做跨App文件分享时判断uri来源。这里有个我之前反复踩过的坑如果你同时配置了外部存储根目录和缓存目录那么不同Android版本在访问同一个文件时可能会因为路径变化导致uri过期。比如你在Android 11上通过FileProvider拿了一个uritemp授权有效期过了到Android 12上再想访问同一个文件时系统会直接抛SecurityException。所以在做文件分享、跨App传递这类功能时最好在授权时设置Intent.FLAG_GRANT_READ_URI_PERMISSION并在Activity结果回调中立即处理数据不要存到全局变量里供后面慢慢使用。3.4 音视频与AI从录音到语音唤醒来敲门音视频模块是很多人觉得高大上、平时又不太敢碰的领域。热词里“android audio - 支持多应用同时录音_android9.0修改方法”这种搜索词能看出来有部分开发者已经开始接触系统级别的音频了。在Android 9.0上多个应用同时录音默认是不允许的A应用在录音时B应用调用AudioRecord会直接抛错。有些方案是通过修改framework层的AudioPolicy配置来允许并发但这种改动需要root权限不适合普通的App开发。我在合集里整理了更实用的思路语音唤醒功能。之前团队要做嵌入式级的“小X小X”唤醒调研了一圈发现onnx-wakeword这类基于ONNX Runtime的方案很合适。它的核心思路是训练好的唤醒词模型转成onnx格式在Android端用ONNX Runtime做推理麦克风通过AudioRecord采集音频数据利用VAD语音活动检测切分出有效语音片段再送入模型判断是否命中唤醒词。整体流程不复杂但需要处理好音频格式和模型输入的匹配问题比如采样率是16k还是8k、帧长是30ms还是50ms这些参数错了直接导致识别率暴跌。如果你是刚开始做音视频方向我的建议是先不要碰系统源码修改级的内容除非你确实在做系统级定制开发。做App层开发把AudioRecord、MediaCodec、MediaExtractor这几个基础API吃透能解决绝大多数业务需求。合集里相关文章的编排也尽量按“应用层 → 框架层 → 系统层”的难度递进方便大家按需取用。3.5 工程化Gradle、签名与多语言配置这一块是我个人认为最容易产生“会者不难、难者不会”差距的地方。热词中“android 应用签名sha1值”“android自定义混淆字典无效”“android java实现多语言”“android动态图标主题”看着都是零散问题但背后对应的是Android工程化的几个核心动作。先说说给应用签名获取SHA1值。无论是接入地图SDK、分享SDK还是微信支付都要求你提供开发版和发布版的签名指纹。很多教程会让你在Android Studio里用Gradle task执行signingReport但如果你用了自定义签名文件就得自己去命令行执行keytool -list -v -keystore xxx.jks。这个命令一跑SHA1和SHA256都出来了复制到对应平台的后台就能过。我当年在这里卡了一晚上是因为开发版签名和发布版签名混了接入的SDK一直报签名校验失败。后来养成的习惯是每个项目建一个signing_configs的gradle文件统一管理签名信息需要查指纹就执行gradlew signingReport一目了然。再说自定义混淆字典。很多人发现自己在proguard-rules.pro里通过-dictionaryfilename指定了一个自定义字典文件但打出来的包还是老样子。原因基本只有一个字典文件没被当作资源打包进工程。正确做法是把字典文件放在app模块的根目录就是和proguard-rules.pro同级的位置然后在proguard-rules.pro里写上-dictionaryfilename “mydict.txt”并确保minifyEnabled为true。这个配置对资源名和类名的混淆有效但方法名不一定完全可控所以别指望它能做到100%的代码安全。多语言和动态图标是偏业务的功能。多语言最简单的做法是用Android的资源目录机制在values-zh、values-en等目录下维护strings.xml然后在代码里通过Locale.setDefault切换。至于动态图标主题Android 13之前只能通过Activity-alias做有限的图标切换Android 13之后官方才提供了自适应图标支持。这篇文章更新于2022年3月当时我明确注明了不同系统版本对不同方案的限制避免读者踩了低版本的坑。3.6 面试与进阶从基础到架构查漏补缺热词里“android 面试题”出现频率不低说明很多人处于准备跳槽或校招的阶段。我这份集合里也整理了一份面试题合集但不是那种把网上几百题全抄一遍的题库而是按我的经验做了精选和分类。我会在每一题下面附上源码或官方文档的引用这样就算不会答也能知道该去翻哪份资料。比如自定义View、事件分发、Handler机制、Activity启动模式、Binder通信原理这些是无论大厂小厂都爱问的基础。再往上进阶一点就是JVM内存模型、类加载机制、性能优化、自定义Gradle插件、组件化与插件化方案对比。到了架构层面MVP、MVVM、MVI各自的优缺点和适用场景也经常会成为面试官深度追问的起点。我觉得面试准备的核心原则是与其背一百道题目的标准答案不如吃透三五个关键知识点背后的原理。比如Handler机制不能只说“子线程通过Handler发消息给主线程”要能画得出MessageQueue、Looper、Handler三者的关系解释清楚IdleHandler什么时候触发、同步屏障有什么用、为什么主线程的Looper调用loop()不会卡死应用导致ANR。这些内容我在合集里都做了关联整理看的时候可以按“问题→源码→延伸”的顺序去读效率会高很多。4. 更新日志背后的维护思考和常见排查4.1 2022年3月这次更新重点调整了什么每次更新日志我都会写清楚这次改了什么方便已经读过旧版本的朋友快速定位增量内容。3月21日这轮更新做的比较多的调整主要有三类。第一类是链接纠错和补档。GitHub上经常有库删档或者改地址Google官方文档也会不定期调整目录结构这些失效链接如果不及时修正收藏的人点进去就会看到404。我逐条检查了上一版里标记为“待验证”的链接该换源的换源该替换推荐项目的就替换掉。第二类是补充了这半年新出现的好库和新技术文章。比如Jetpack Compose相关的实践又多了不少我也补充了几篇手写Compose自定义布局的实际案例分析。语音唤醒、端侧AI这类方向也因为社区的讨论热度上升我增加了几条onnx-wakeword相关的中文踩坑记录。第三类是修正了几条过时结论。举个例子之前我收录过一篇文章推荐用某个旧库来做轮播图但后来这个库在Android 12上频繁出现测量异常社区里的替代方案已经非常成熟了。我在更新日志里明确提示了这个问题并给出迁移方案避免读者照旧实现后踩雷。如果你也想让自己的资源集合保持参考价值我真心建议每隔一段时间哪怕一个月一次回头检查一遍把“已验证”“已失效”“已替代”这种状态标注清楚。一个过时的错误推荐可能比没有推荐更有害。4.2 一套可复制的链接有效性排查清单这里分享我自己常用的排查方法。打开整个合集清单后先用脚本或者在线工具批量检测所有链接的HTTP状态码把返回404、403、410的筛选出来人工二次确认。对于返回200的链接也不能完全放心因为有些页面是软404服务端返回200但内容为空或已经被重定向到首页需要抽样点击验证。如果是GitHub项目我还会额外看四样东西最近一次commit时间、open issue的数量和最新回复时间、README里的badge是否还在正常显示、以及release页面是否有较新的版本。这四样综合下来基本能判断一个项目是死是活。对于死掉的项目如果确实没有替代品我会保留链接但在注释里标明“目前无维护fork自用时注意”这样既尊重原作者的贡献又不会误导后人。4.3 收藏了很多却用不上的问题有不少人来找我说我也收藏了几百个星标库但真到写代码时还是只会用那三五个这个合集收了有用吗我的回答是光收藏确实没用但如果按照“当下项目需求”去翻合集把一个库里涉及到的源码和文章顺着读一遍然后立刻在小demo里写一遍这个库才算转化成你自己的东西。我自己的习惯是每次做一个不熟悉的功能模块前提前花一晚上时间在合集里找到对应分类把七八篇相关文章和两三个开源项目做横向对比挑出最符合当前项目约束的方案。然后在项目中先写一个最小可用版本能跑通了再深入看源码和细节。这个过程坚持一年下来你会发现你不再需要频繁搜搜索引擎了很多方案自己心里有数因为你知道“这个问题我在哪里见过、那篇文章在哪个分类、那个库当时踩了什么坑”。5. 常用工具与信息源推荐维护这个合集这么久我沉淀下来几个自己每天都会用的信息源和工具分享出来供你参考。如果你也想自己做一个类似的资源集合这些会很有帮助。GitHub的Trending页面是每天看项目动态的第一个入口但它的信息噪音很大。我一般配合“GitHub Topic”功能一起用搜索android、kotlin、jetpack-compose等大话题再按最近更新的时间排序这样看到的都是不久前的活跃项目。除此之外一些周报类的开发者平台比如一些专注推技术干货的公众号和网站也会定期整理优质开源项目关键是找那些自己有明确选型和实践验证的作者而不是什么火就转什么。工具方面我推荐大家用Raycast或者Alfred做本地片段的速查很多常用的代码模板和命令行工具说明都可以存成片段一键唤起。另外在线版HTTP状态检测工具也常备在浏览器书签里整理链接时随用随查。如果你在某个平台看到一篇讲得特别透彻的文章建议想办法找到作者本人的主页。很多博主会在自己的博客里放更完整的系列文章质量往往比单个平台上的推文更高。我这份合集里不少深度文章就是从这样“顺藤摸瓜”的方式挖出来的。6. 几个容易忽略却非常重要的细节6.1 阅读开源项目源码的正确顺序拿到一个开源项目如果你的目标是学习而不是简单接入我推荐的阅读顺序是先看README中“Framework”“Architecture”部分了解整体分层再跑通demo从main入口进来接着读核心类的公共方法注释搞懂对外暴露的能力最后深入内部实现按调用链逐层推进。这个过程最忌讳的是从头到尾一行行读代码一会儿就看晕了。先建立地图再探索细节效率完全不一样。6.2 分辨一篇技术文章是否值得读的三个信号我在整理文章链接的过程中逐渐形成了自己的过滤机制。首先看发布时间和文章里引用的库版本如果写的是“compileSdkVersion 28”之类的老版本除非明确说是历史方案介绍否则基本可以放弃了。其次看作者是否在关键步骤前解释了“为什么这么写”如果全文都是复制粘贴的代码而没有原理说明那多半是二手内容。最后看评论区或issue区如果一堆人在反馈问题且作者没有回应说明这个方案的可靠性存疑。6.3 开源许可使用别人的代码前一定要看一眼最后一个容易忽略但非常致命的点开源许可证。有些项目虽然代码公开在GitHub上但许可协议是GPL或AGPL如果你的项目是商业化闭源应用直接搬代码可能会带来法律风险。我见过不止一个开发者在不知情的情况下用了GPL库的代码最后被要求开源整个项目。我在这份合集里虽然不是每个项目都标注了许可证类型但我自己接入前一定会去确认希望阅读这份集合的人也能养成这个习惯。MIT、Apache 2.0、BSD这类宽松许可相对安全GPL、LGPL需要结合你的项目性质慎重评估。说个我自己的习惯维护这个合集以来我越来越确定一件事技术积累的核心不在于收藏了多少链接而在于你能否在需要用的时候准确知道去哪里找答案、什么是好答案、什么不能直接用。这份Android开源项目和文章集合就是我为这个目标搭建的一个私人导航它帮我省下大量搜索和试错的时间希望对你也有同样的作用。