9个Android开源App项目拆解：从跑通、改造到资产沉淀

手上有一份9个完整 Android 开源 App 项目清单是件挺容易让人上头的事——点开一看个个都有登录页、首页、列表、详情看着全须全尾仿佛拿到九本装订好的教材。真动手的人都知道热闹和门道差着十万八千里有的项目克隆下来十分钟跑不起来有的能跑但业务是空壳有的架构漂亮却只覆盖了三个页面。我前后折腾过几批这类 Android 开源 App 项目最深的体会是——它们的价值不在完整而在可拆。你得像拆一台旧机器那样一个模块一个模块地拧下来才知道哪块零件能装到自己车上。这篇就按我实际的处理顺序从怎么挑、怎么跑、怎么读、怎么改、怎么避坑、怎么处理授权一路讲到我怎么把九份代码沉淀成自己的资产库写给刚入门想找练手项目的也写给做了两三年、想系统啃一遍别人架构的同学。1. 先做减法九份代码里的分层与取舍逻辑拿到清单的第一反应通常是从第一个开始看这是最慢的路。九个项目如果只是顺着看看到第五个你就记不清第三个的仓库层叫什么名字了。我习惯先花半小时做一张对照表把每个项目的技术栈、体量、业务复杂度、可运行性标出来再决定投入顺序。这一步不做后面全是无用功。1.1 完整这个词在开源项目里到底指什么很多人把完整理解成功能齐全实际上开源 App 项目里的完整通常只意味着有骨架、有数据流、有 UI这三件事凑齐了。登录能进、列表能滑、详情能点开就算完整。但真正决定它值不值得读的是另外三样有没有清晰的分层边界、有没有真实的数据来源哪怕是 Mock、有没有可复用的基础设施代码网络封装、日志、埋点、错误处理。我按这个标准把这九份代码过了一遍大致分成三类后面所有安排都基于这张表分类项目形态体量感受值得投入的点投入建议业务完整型资讯阅读、电商、聊天中等偏大十几个到几十个页面分层结构、状态管理、列表分页重点啃选一到两个深挖单点技术型播放器、相机图像处理、天气页面少但技术密度高音视频、CameraX、自定义绘制按需取用当工具书架构示范型待办清单、记账、工具集合小到中等代码干净Compose、依赖注入、多模块拆分优先跑通当模板我自己的阅读顺序是先架构示范型再业务完整型最后单点技术型。理由很直接架构示范型项目代码量小一两个小时能通读完先把现代 Android 项目大概长什么样这个基准建立起来有了基准再看业务型项目你就能一眼看出哪些写法是项目作者的偏好、哪些是行业共识单点技术型项目则不必通读需要的时候翻对应模块就行。1.2 九份代码的具体拆解我实际怎么给它们定位具体到手上这九份我是这样归位的都用代号避免先入为主项目 A资讯阅读Kotlin MVVM Retrofit Room列表走分页加载有缓存和离线阅读。这份是学标准数据流最好的样本从 UI 事件到 ViewModel 到仓库层到网络/数据库双数据源链路完整。项目 B电商详情与购物车偏老的 Java MVP页面多、跳转乱但业务规则写得实价格计算、规格选择、库存判断这些逻辑有真实参考价值。架构不值得学业务建模值得看。项目 C聊天 Demo长连接 消息列表 本地存储。这份的价值全在消息状态机上——发送中、已送达、已读、失败重发这套状态流转是很多人自己写 IM 时最容易写崩的地方。项目 D音视频播放基于 Media3 的播放器带前台服务、通知栏控制、播放队列。学服务与 UI 解耦的好材料。项目 E待办清单纯 Compose Hilt三百来个文件干净得像教学样本。如果只能花一天我建议就跑这一个。项目 F天气定位 自定义 View 绘制温度曲线图表部分手写 Canvas适合补自定义绘制的课。项目 G记账Room 多模块 统计图表模块化拆分做得比较规矩适合看怎么切模块。项目 H相机图像处理CameraX 滤镜涉及图形渲染坑最多也最能练排查能力。项目 I工具集合多模块 功能聚合适合看大型项目的工程配置。这张表看着简单但它解决了一个关键问题你不会再对自己看不完九个项目感到焦虑。深挖两个、通读三个、翻查四个就是一次很扎实的学习。1.3 投入产出比的现实估算我给自己定过一个粗略的时间预算实测下来偏差不大跑通一个中等体量的项目环境顺利的话 1 到 2 小时环境不顺利可能一整天通读一遍核心链路 3 到 5 小时动手改一个功能 4 小时以上彻底吃透架构半天到一天。九份全按彻底吃透算那是两百多个小时的活普通人根本排不出来。所以我建议的分配是一个深度20 小时、两个中度各 8 小时、六个浅度各 1 小时浏览目录结构总计五十小时上下分摊到一个月的业余时间里是完全可行的。浅度浏览也不是浪费时间——你只需要看它的build.gradle、目录结构和README就能判断这份代码以后遇到什么问题可以回来翻。提醒一句不要贪多。同时打开三个以上项目你的 Gradle 缓存、SDK 版本、IDE 索引会互相干扰排查问题时根本分不清是项目本身的问题还是环境串了。我吃过这个亏后来强制自己同一时间只保留一个可运行项目。2. 让它跑起来环境与依赖里那些不写进 README 的事九份代码里能一次Sync成功的我印象里不超过三个。这不是作者不负责而是 Android 构建工具链的版本耦合太紧——一份两三年前的项目换到今天的 IDE 上几乎必然要动配置。我现在的习惯是克隆下来先不看代码先看四个文件——根目录build.gradle、模块build.gradle、gradle/wrapper/gradle-wrapper.properties、gradle.properties。这四个文件基本决定了你会不会卡在第一步。2.1 Gradle、AGP、JDK 三者的版本咬合关系这是新手最容易翻车的地方。很多人以为升级到最新版就好了结果一升全崩。核心是三者必须咬合AGP 版本决定 Gradle 最低版本也决定 JDK 要求。我整理了一份常见组合遇到老项目照着对就行AGP 版本最低 GradleJDK 要求典型年代感3.x4.10 ~ 5.xJDK 8很老的项目还在用 support 库4.2 ~ 7.06.7 ~ 7.xJDK 8 / 11从 support 迁到 AndroidX 的过渡期7.47.5JDK 11大量现成项目的常见状态8.0 ~ 8.28.0 ~ 8.2JDK 17开始强制 namespace8.5 以上8.7 以上JDK 17新项目主流操作上我会先看一眼原项目的gradle-wrapper.propertiesdistributionUrlhttps\://services.gradle.org/distributions/gradle-8.7-bin.zip如果这个版本和当前 IDE 自带的 JDK 不匹配最省事的做法不是升级项目而是降级工具——去 IDE 设置里把 Gradle JDK 切到项目需要的版本。我机器上常驻 JDK 8、11、17、21 四个版本切换成本很低比改一堆 Gradle 脚本划算得多。真要升级也别一步跨到最新。按小版本递进7.0 → 7.2 → 7.4 → 8.0 → 8.2每升一档跑一次编译。这样做的好处是报错信息能立刻定位到是哪一档引入的破坏性变更而不是面对一屏红字无从下手。2.2 依赖下载比想象中更容易卡住的地方依赖拉不下来是仅次于版本不匹配的第二大拦路虎。表现是Sync卡在某个pom文件上或者直接报Could not resolve。原因通常有三个仓库地址失效、项目用了已下线的仓库、本地缓存被污染。我的处理顺序是先看根目录settings.gradle里的repositories块确认google()和mavenCentral()都在再检查有没有历史遗留的jcenter()——这个仓库早就停止服务了看到就替换掉。// settings.gradle 里的仓库配置建议这样写 dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() // 网络环境不理想时可以在这里加公共镜像代理 // maven { url uri(https://mirror-host/repository/public) } } }缓存出问题时./gradlew --refresh-dependencies能强制刷新但比较慢。更快的是直接删掉~/.gradle/caches/modules-2/files-2.1/下对应 group 的目录然后重新Sync。这招我在处理明明仓库里有这个版本本地就是拉不下来的问题时用过很多次。另外一个细节老项目里的compile、implementation混用。compile在 AGP 7 之后已经被移除看到就得改成implementation或api。批量处理时可以用 IDE 的全局替换但要注意api和implementation的区别别乱换——api会把依赖暴露给下游模块模块化项目里换错了会导致编译期依赖污染。2.3 SDK 版本、Kotlin 版本与编译失败的连带效应compileSdk和targetSdk不一致会引发一堆诡异问题。常见情况是compileSdk 33但某个库要求34编译直接报错。我的原则是compileSdk取依赖库要求的最高值targetSdk跟随最新稳定版两者可以不一致但targetSdk不要低于compileSdk太多。Kotlin 版本和 Compose 编译器的对应关系也常被忽略。Kotlin 2.0 之后Compose 编译器随 Kotlin 版本走用插件方式引入plugins { alias(libs.plugins.android.application) alias(libs.plugins.kotlin.android) alias(libs.plugins.kotlin.compose) // Kotlin 2.0 的 Compose 编译器插件 }如果是 Kotlin 1.9 及以前的项目写法是composeOptions { kotlinCompilerExtensionVersion 1.5.8 }这个版本号必须和 Kotlin 版本严格对应错一个数字就编译不过。我在项目 E 上就栽过——它写的是 1.5.1我本地 Kotlin 是 1.9.22改了三次才对上。实操心得遇到明明代码没问题就是不编译的情况先执行./gradlew :app:dependencies --configuration debugCompileClasspath把解析出来的依赖树打出来看。十次里有六次能直接看到冲突的库和它被传递引入的路径。这比盲猜快得多。3. 读懂它们从九份实现里提取可复用的架构共识跑通之后才是真正的重头戏。九份代码如果一篇篇顺着读读到第五份你会疲劳但如果按主题横向对比来读效率完全不同——同一个问题比如状态管理在九个项目里是怎么解决的对比着看共识和分歧立刻分明。3.1 状态管理MVVM 的三种落地面貌九份代码里MVVM 是最主流的写法但落地差别很大主要有三种第一种是LiveData 多字段老项目常见。ViewModel 里挂七八个MutableLiveDataUI 层分别订阅。优点是上手快缺点也很明显——多个状态之间可能互相矛盾比如isLoading false但data还是 null而且旋转屏幕后状态恢复容易出错。第二种是单一 State 数据类 StateFlow现代项目的主流。把所有状态收敛到一个data classUI 只订阅这一条流data class ListUiState( val isLoading: Boolean false, val items: ListItem emptyList(), val errorMessage: String? null, val isRefreshing: Boolean false ) class ListViewModel(private val repo: ItemRepository) : ViewModel() { private val _uiState MutableStateFlow(ListUiState()) val uiState: StateFlowListUiState _uiState.asStateFlow() }这种写法最大的好处是状态不可矛盾——因为它是整体替换的不会出现加载中又显示错误的荒谬组合。项目 A 和项目 E 都是这种风格我后来的所有项目都沿用了。第三种是MVI 风格事件也进流项目 C 用了。UI 发Intent这里不是 Android 的 Intent是 MVI 概念里的用户意图ViewModel 处理后产出新状态。好处是输入输出都可追溯坏处是模板代码多小项目用起来很重。我自己的取舍是页面状态少于三个字段用简单 StateFlow 就够字段多、状态之间有关联一律上单一 State 数据类需要严格追溯用户操作的场景比如复杂表单才考虑 MVI。3.2 依赖注入Hilt、Koin 与手写容器九份里 Hilt 出现频率最高Koin 次之还有两份是老式的手写单例。这三者在项目里的表现差异读代码时很容易感受到Hilt 的项目依赖关系一目了然——看Module就知道提供了什么看构造函数上的Inject就知道用了什么。代价是编译期生成代码编译变慢报错信息也不太友好尤其是作用域写错的时候报错指向的位置经常让人迷惑。Koin 的项目配置集中在模块声明里运行时解析报错是运行期崩溃而不是编译期。好处是上手简单、编译快坏处是依赖漏了要跑到那一步才知道。手写单例的老项目通常是一个AppManager或者ServiceFactory之类的类把所有东西new出来存着。这种写法隐藏的坑最多——单例持有 Context 导致内存泄漏、初始化顺序依赖隐式、测试时无法替换。我读这类代码时有个固定动作在项目里全局搜索getInstance和object把所有单例列出来看哪些持有 Context、哪些在初始化时做了耗时操作。这一步能提前发现很多潜在问题也是学怎么不这么写的好素材。3.3 网络层与本地缓存:九份代码里的公共套路网络层几乎是所有项目的标配最主流的组合是Retrofit OkHttp 序列化库。差异主要在三点拦截器怎么配、错误怎么统一处理、缓存怎么做。拦截器部分健康的项目通常会有一个公共参数拦截器、一个日志拦截器、一个 Token 拦截器。日志拦截器要注意只在 Debug 构建里启用我看到过直接把日志拦截器写死在正式包里的项目那等于把所有请求明文打到日志里很危险。错误统一处理好的做法是把Response或异常包装成自定义的Result密封类UI 层只处理成功和数据两类分支sealed interface ApiResultout T { data class SuccessT(val data: T) : ApiResultT data class Failure(val code: Int, val message: String) : ApiResultNothing }缓存的套路更值得对比。项目 A 用了网络优先 Room 落库 流式返回也就是仓库层返回Flow先发一次数据库里的旧数据再发一次网络的新数据UI 层自然就实现了先看缓存再刷新的效果。这种写法在项目 G 里也出现了只是换成了手动回调。我倾向于前者因为 Flow 的组合能力让后续加防抖、去重都方便很多。3.4 UI 层View 体系与 Compose 混用的现实九份代码里纯 Compose 的只有项目 E 一份其余全是 View 体系还有两份在迁移中。这个分布其实很真实——市面上大量存量项目还是 XML所以两套都得会。读 Compose 项目重点看三件事remember和rememberSaveable用得对不对、重组范围控制得好不好、状态提升做得是否彻底。项目 E 里有一段列表实现把LazyColumn的items加了稳定的 key这个细节能明显减少滚动时的重组开销。读 View 体系项目重点看findViewById还是 ViewBinding后者是正确方向、Fragment 生命周期里有没有做资源释放、列表适配器有没有做局部刷新notifyItemChanged而不是notifyDataSetChanged。混用的情况最难读。常见做法是在 Activity 里用ComposeView挂一段 Compose UI或者反过来在 Compose 里用AndroidView包一个自定义 View。读的时候要特别注意状态在两个世界之间怎么传递——我见过最糟糕的写法是在 Compose 里持有 Activity 引用直接改 View 状态那种代码基本没法维护。一个我反复验证过的判断标准如果一份代码里同一个业务状态同时存在LiveData和MutableState两份副本那这份代码大约还在迁移中途读的时候不要把它当范本只挑其中成熟的部分看。4. 动手改把别人的 App 变成自己的练手场光读不改收获最多三成。我给自己定的规矩是每读透一个项目必须动手改一处。改什么不重要重要的是走完定位—修改—验证的完整链路这个过程中遇到的问题才是真知识。4.1 改之前先做三件保命的事第一件打一个 tag 或者拉一个新分支。别在原分支上直接改改崩了想回退会非常痛苦。我习惯性git checkout -b my-lab所有实验都在这个分支上做。第二件确认能跑通再动手。如果项目本身跑不起来就先改功能你会分不清崩溃是自己改的还是本来就有的。第三件记录一份改动前的基线。比如首页加载耗时、冷启动时间、包体积改完之后对比一下能发现很多你没意识到的影响。我就遇到过一次加了一个图片加载库包体积涨了 2MB因为默认带了一堆解码器后来换成按需引入才降下去。4.2 第一刀剥离外部服务注入假数据大多数开源项目会依赖某个远程服务服务挂了项目就跑不动。我第一步通常是把数据源换成可控的 Mock这样后续调试不受外部影响。具体做法是在仓库层加一个实现类用开关控制走真实接口还是本地数据interface ArticleRepository { fun observeArticles(): FlowListArticle } class MockArticleRepository : ArticleRepository { override fun observeArticles(): FlowListArticle flow { emit(SampleData.articles) delay(800) // 模拟网络延迟方便验证加载态 emit(SampleData.articles.shuffled()) } }写 Mock 的时候有个细节容易被忽略延迟和异常也要模拟。只返回成功数据你永远看不到页面在加载态和错误态下的表现等到接真接口时才发现空状态页面压根没写。异常模拟可以这样加让 Mock 仓库有 10% 概率抛异常或者用一个全局开关手动触发。项目 A 里我加了这么一段之后立刻发现了它的错误页没处理重试按钮的点击事件——这是静态读代码绝对看不出来的。4.3 第二刀加一个完整的小功能模块比换数据源更有价值的是从零加一个小功能。我一般选收藏或者浏览历史这类不涉及核心业务、但需要打通全链路的功能够用。以收藏为例完整链路是UI 上的按钮 → ViewModel 事件 → 仓库层写入数据库 → 数据库变化 → UI 自动刷新。这条链路跑通一次你就把项目的分层、状态管理、数据持久化全摸了一遍。我建议按这个顺序做先加数据层。建实体、建 DAO、写查询语句用单元测试验证增删查没问题。再改仓库层。加收藏方法返回Flow以便 UI 响应变化。然后改 ViewModel。暴露收藏状态和切换方法。最后改 UI。加按钮绑定状态处理点击。补测试和边界情况。比如未登录能不能收藏、重复点击会不会插两条、取消收藏后列表能不能及时更新。第 5 步是最容易被跳过、也最能暴露问题的。我在项目 G 上加收藏时一开始没做去重快速点两下就在数据库里插了两条记录列表上出现两个一样的心标。这类问题在静态阅读时完全想不到只有自己动手才会撞上。4.4 第三刀换一套 UI验证分层是否真的解耦这一步听起来最表面实际上最能检验你对项目结构的理解。做法是把首页换成一个完全不同的布局看需要改动多少文件。如果一个项目的分层做得好换 UI 只需要改 UI 层如果需要动 ViewModel 甚至仓库层说明它的分层是假的业务逻辑漏到了 UI 层里。我试过在一个老项目上做这件事换首页布局时被迫改了三个 ViewModel 和一个工具类原因就是它把格式化逻辑写在了 Activity 里。这个练习还有个附带好处你会自然形成一套自己的 UI 组件习惯。换布局的时候顺手抽几个可复用组件沉淀下来就是自己的组件库起点。5. 六个高频坑我在九个项目上撞过的墙下面这些全是我实际撞过的不是从文档里抄的。按出现频率 × 排查难度排序前三个几乎每个项目都会碰到。5.1 资源冲突与 R 类膨胀合并多个项目的代码时最常见的问题是资源名冲突。两个模块都有bg_button.xml、都有strings.xml里的app_name合并后要么编译报错要么运行时拿到错误的资源。解决办法有两个层面。构建层面给每个模块配置资源前缀android { resourcePrefix order_ // 该模块所有资源必须以 order_ 开头 }工程层面打开非传递 R 类让每个模块只能用自己模块的 R# gradle.properties android.nonTransitiveRClasstrue这个开关打开后跨模块引用资源必须写全包名编译期就能发现问题比运行时出错强太多。老项目默认是关闭的改完之后会冒出一堆编译错误别慌那些错误本来就是隐患。5.2 混淆规则与打包后的崩溃Debug 跑得好好的打个 Release 包就崩十有八九是混淆规则不全。开源项目里常见的坑包括序列化类的字段被混淆导致解析失败、反射调用的类被裁掉、注解处理器生成的类没保留。排查链路我一般是这么走的先看崩溃堆栈如果是NoSuchFieldException或ClassNotFoundException基本可以确定是混淆问题然后打开mapping.txt反查原始类名最后补规则。# 序列化模型保留字段名 -keepclassmembers class com.example.data.model.** { fields; } # 保留注解 -keepattributes *Annotation*, Signature, InnerClasses, EnclosingMethod还有个细节库模块的混淆规则要写在自己的consumer-rules.pro里不要都堆在 app 模块。这样下游集成时规则会自动带上不会漏。5.3 第三方 SDK 残留导致的清单合并失败开源项目里经常带着各种统计、推送、广告 SDK 的配置。你不需要它们但删不干净就会在清单合并时报错——比如某个 SDK 声明了一个 Provider你删了它的依赖但清单里的引用还在。排查方法是看合并后的清单文件路径在app/build/intermediates/merged_manifests/debug/AndroidManifest.xml里面能看到每一行来自哪个模块。找到来源要么删依赖要么用tools:noderemove显式移除。uses-permission android:nameandroid.permission.READ_PHONE_STATE tools:noderemove /顺手把不需要的权限也清一遍。很多老项目申请的权限在今天看来完全没必要留着既影响审核也影响用户信任。5.4 targetSdk 提升后的行为变更把targetSdk从 30 提到 34 或 35会触发一批行为变更。我踩过的有变更点表现处理方式通知权限Android 13 不发通知动态申请POST_NOTIFICATIONS存储权限拆分读图片拿不到数据改用READ_MEDIA_IMAGES等细分权限前台服务类型启动服务崩溃清单里声明foregroundServiceType隐式 Intent跳转无响应改为显式 Intent精确闹钟定时不准视场景申请精确闹钟权限或降级为不精确最坑的是前台服务那条。项目 D 是播放器提升targetSdk后一启动播放就崩报错说缺少服务类型声明。加上android:foregroundServiceTypemediaPlayback才解决。这类问题不看变更日志根本想不到。5.5 so 库与 ABI 过滤带原生库的项目比如项目 H 的图像处理经常出现模拟器能跑、真机闪退或某些机型装不上。原因通常是 so 库只提供了部分架构或者依赖冲突导致版本不匹配。android { defaultConfig { ndk { abiFilters arm64-v8a, armeabi-v7a } } }现在新设备基本都是 64 位我一般只保留arm64-v8a包体积能省不少。但要注意如果某个依赖只提供了 32 位库砍掉armeabi-v7a就会运行时报找不到库——这种情况要么换依赖要么保留双架构。还有一个新变化值得留意较新的系统版本对内存页大小有要求部分老的原生库需要重新编译才能正常运行。遇到安装成功但一调用原生方法就崩的情况可以往这个方向查。5.6 崩溃排查的完整链路说一个我印象最深的。项目 C 的聊天页面在消息列表快速滚动时偶发崩溃日志只有一行IndexOutOfBoundsException。排查过程是这样的第一步确认复现路径发现只有发送消息的同时快速上滑才必现第二步看堆栈指向适配器的getItemCount和getItem第三步怀疑是数据源在滚动的过程中被修改了第四步检查消息发送逻辑果然是在子线程直接改了ArrayList而列表在遍历它第五步改成CopyOnWriteArrayList或者用DiffUtil提交不可变列表问题消失。这个案例的价值在于并发问题不会在正常操作下暴露只有制造并发才会出现。后来我读任何项目的列表代码第一件事就是找数据源的修改在哪个线程。排查这类问题的通用套路先稳定复现再缩小范围然后提出假设并验证最后修复并回归。最忌讳的是看到崩溃就直接加try-catch——那只是把问题藏起来下次会以更诡异的方式出现。6. 用之前必须搞清楚开源协议与素材授权这一段很多人直接跳过出问题时才发现麻烦。九份代码里协议分布大概是 Apache-2.0 为主MIT 有几个还有个别是 GPL 系。这三种的差别不是文字游戏直接决定你能不能用、怎么用。6.1 三种常见协议的实际边界协议能否商用是否要求开源衍生代码是否需要保留声明实际注意点MIT可以否是最宽松保留版权声明即可Apache-2.0可以否是还需声明修改过的文件注意专利条款GPL 系可以是传染性强是衍生作品需以同协议开源关键在 GPL。如果你把一份 GPL 协议的 App 代码拿来做自己的应用并分发整个应用都需要以 GPL 开源。这对商业项目基本是不可接受的。所以动手之前先看 LICENSE 文件这是纪律。MIT 和 Apache-2.0 相对宽松但也有要求保留原作者的版权声明、在显著位置说明使用了哪些开源组件。我习惯在应用的关于页面里放一个开源许可列表用构建插件自动生成省得手动维护。6.2 代码能用素材未必能用这是最容易忽略的一点。代码协议只覆盖代码不覆盖图片、字体、图标、音频。九份代码里不少项目带着设计稿导出的图、第三方图标包、甚至从网上找的背景音乐。这些东西的授权状态是独立的。我在项目 F 上就遇到过它带了一套自定义字体文件里没有授权说明。这种字体如果是从商用字库来的直接打包进应用是有风险的。处理办法很直接——换掉。系统自带字体或者明确标注可商用的开源字体都比冒这个险强。图标同理。项目里那些ic_xxx.png如果来自某个图标库要确认该库的许可条款。现在主流的做法是用矢量图标库很多开源图标集允许免费商用但要求保留署名。6.3 二次发布前的自检清单如果打算把改过的项目发到应用市场我建议过一遍这几条包名是否已全部替换包括清单、build.gradle、代码里的硬编码字符串签名是否换成了自己的别用项目自带的调试签名应用名、图标、启动图是否已替换避免和别人撞脸隐私政策页面是否准备涉及权限的都要说明用途第三方 SDK 是否清理干净只留真正需要的权限列表是否最小化能不要的都不要开源许可声明页是否添加。这几条看着琐碎但每一条都对应过实际被驳回的案例。尤其是包名和签名改漏了会导致应用装不上或者覆盖掉别人的应用。7. 沉淀把九份代码变成自己的长期资产读到这儿如果只是看完了那九份代码的价值在你关掉 IDE 的那一刻就归零了。我花了不少时间才想明白一件事这些项目的真正价值不是我读过了而是我从中抽出了几块能反复用的东西。7.1 一块自己的基础模块我的做法是维护一个私有基础库把九份代码里验证过的东西抽进去。目前里面大概有这些网络层OkHttp 配置、拦截器、统一错误映射、请求重试。状态封装统一的UiState密封类、加载中/空/错误三种状态的通用组件。扩展函数日期格式化、单位转换、协程作用域辅助、Flow 防抖去重。UI 组件通用标题栏、空状态页、带重试的错误页、列表分页加载封装。抽取的标准是在两个以上项目里出现过且写法基本一致。只在一个项目里出现的东西先别抽很可能只是那个作者的偏好。抽取方式我建议用版本目录管理依赖这样多个项目共享同一套配置升级时改一处就行# libs.versions.toml [versions] kotlin 2.0.21 agp 8.7.2 retrofit 2.11.0 [libraries] retrofit-core { module com.squareup.retrofit2:retrofit, version.ref retrofit }7.2 建立问题—项目—方案的索引笔记比代码更有价值的是笔记。我的笔记不是按项目组织的而是按问题组织。每条记三样东西问题描述、在哪份代码里见过、当时的解决方案是什么。比如列表滚动时数据源被并发修改这条记的是出现在项目 C原因是子线程直接改 ArrayList方案是提交不可变快照。下次任何项目遇到类似崩溃一搜就能定位。这种索引的好处是它把九个孤立的项目变成了一张知识网。你不再记得项目 A 第几行写了什么但你记得分页加载的问题在哪份代码里有成熟实现。这才是能长期复用的东西。7.3 给自己留一份改造记录最后一个小习惯每次改完一个项目花十分钟写一段改造记录。写清楚改了什么、为什么这么改、遇到了什么问题、怎么解决的。这份记录不需要给别人看但三个月后你自己回头看它能帮你快速回忆起当时的技术判断。我在项目 G 上改模块拆分时记了一段后来在另一个项目上遇到模块循环依赖翻笔记发现当时就处理过——那次至少省了我两个小时。我个人在实际操作中的体会是九份代码里真正能进脑子的永远是你亲手改过的那两三份。剩下的六份价值在于当你遇到具体问题时知道去哪一份里翻。所以别追求全部吃透追求知道哪块东西在哪儿然后把手弄脏一次比什么都强。