之所以 2025 了 GSYGithubApp 还能迎来 Jetpack Compose 版本的开源,主要还是依赖于 AI 的强大:github.com/CarGuo/GSYG... 。

GSY 系列项目做早是从 2016 年开始做的开源,其中大家最为熟悉的应该是 GSYVideoPlayer ,它也是维护至今最长的项目,而 GSYGithubApp 系列最早是在 2017 年 11 月开源,至今正好是八年,而近日这个项目也正式开源了 GSYGithubApp 的 Jetpack Compose 版本:

GSYGithubApp 诞生之初 Github 的官方客户端还没有出来,而当时因为做开源也有些时间,所以在日常中没有一个应用其实挺不方便,正好那时候刚学 React Native 没多久,所以 2017 年第一个 GSYGithubApp 就作为练手项目诞生了,之后陆续随着接触的技术栈变化,开源的版本也越来越多,它们开源的顺序依次是:
- React Native github.com/CarGuo/GSYG...
- Weex github.com/CarGuo/GSYG...
- Android Kotlin View github.com/CarGuo/GSYG...
- Flutter github.com/CarGuo/GSYG...
- Android Jetpack Compose github.com/CarGuo/GSYG...

而其实随着 Github 官方的 App 发布后,GSYGithubApp 存在的意义就变了:它更多是成为一个完整的技术学习项目,并提供同款技术对比的一个目的。
另外过去的时候,闲鱼就曾用过 GSYGithubApp 的 React Native 版本和 Flutter 版本做过一些性能对比测试:

而之所以选择做 Github 客户端也是因为这个,这能让它成为一个完整的 App 开源项目,Github API 相对稳定并且丰富,流程从登录,用户,仓库,Issue ,输入输出,数据库等都能覆盖,能让开源项目涉及的内容更全面。
当然,个人经历有限,随着时间推移,其实 GSYGithubApp 在过去挺长的时间里,除了 Flutter 版本外,其他版本都是处于"放(qi)生(keng)"状态,直到 2025 AI 的能力大幅提升之后,它们才又迎来了更新:
- React Native 版本目前更新到 0.82 ,说实话就算是有 AI ,从 0.61 升级到 0.82 也是一个挺让人"绝望"的体验,详细可见:用 AI 把一个五年前的 RN 项目,从 0.61.3 升级到 0.74.0 是一种什么样的体验
- Android Kotlin View 版本,在 AI 的帮助下,终于成功升级到可以在最新 Android Studio 和 Gradle 环境运行
- Weex 版本,嗯,还是处于"放(qi)生(keng)"状态,懂得都懂
所以在感受到 AI 强大的辅助能力后,我就觉得也许可以再来个 Jetpack Compose 版本的 GSYGithubApp 项目,而实际上零零散散开发直到开源,大概也就是两周的时间,其中 80% 以上都是 AI 完成:

当然,这个速度主要也是因为需求明确,原型已经有了,给 AI 参考的资料就多了,基本上也算是熟悉的领域,大部分只需给 AI 投喂好资料,初始结构直接让 AI 参考官方的 android/androidify 项目,制定好路线和方向,整体还是相当省心的:


当然,这里面就不得不提开发过程中给 AI 指定 rules 的必要性,因为 AI 实际上很多时候并不会全局考虑你的项目结构,每次需求对他有限的 Context 来说,大多数时候都只会局限性的考虑问题,这时候在开发过程中根据 AI 的调性配置相应的规则还是很重要的,例如通用的模板和生成规则就很有必要:

这些规则不是说你一开始就要有,而是在 AI 开发过程中,在已经有一定代码的情况下,就可以让 AI 读取现有的结构去生成,还有就是 AI 的脑回路大多数时候只和它训练时的数据绑定,所以有些新的东西,就需要你明说,一些他经常错的东西,就需要你显式的罗列出来:

这里大部分都是使用 Android Studio 的
Gemini for businesses完成,部分是 Copilot Web Agent 和 Claude 完成,另外,新版的 Android Studio Otter 2 Feature Android Studio 的 Agent 模式也开始配备了 Android 知识库,从而显著提高准确性并减少错误信息。这意味着,Agent 不再仅仅依赖于其训练数据,而是可以在回答用户问题之前主动查阅来自官方来源(例如 Android 开发者文档、Firebase、Google Developers 和 Kotlin 文档)的最新文档。
当然,最终代码还是需要人审核,咱也不懂,为什么它增加个多语言的时候,会删掉某个标签,加个 camera 做什么?

当然,在这个过程里,你还能见到嘴硬的 AI 开始推卸责任,不得不说 AI 的拟人化越来越真实:

而对于项目的架构,我们也可以通过 AI 来完成,例如 https://deepwiki.com/ ,只需要通过 https://deepwiki.com/CarGuo/GSYGithubAppCompose ,我们就可以得到一份项目的架构报告,并且你还可以通过它继续询问相关问题:

另外,通过 AI 我们也可以生成对应的结构实现,例如以下就是通过 Gemini 生成的手绘图示例:
架构图
bash
┌─────────────────────────────────────────────────────────────────────────┐
│ GSYGithubAppCompose │
│ (Jetpack Compose + MVVM) │
└─────────────────────────────────────────────────────────────────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
┌───────▼────────┐ ┌──────▼──────┐ ┌───────▼────────┐
│ Presentation │ │ Data │ │ Core │
│ Layer │ │ Layer │ │ Layer │
└────────────────┘ └─────────────┘ └────────────────┘
│ │ │
┌───────▼────────┐ ┌──────▼──────┐ ┌───────▼────────┐
│ feature/* │ │ data │ │ core/network │
│ │ │ │ │ core/database │
│ - welcome │ │ Repository │ │ core/common │
│ - login │ │ Pattern │ │ core/ui │
│ - home │ │ │ └────────────────┘
│ - dynamic │ │ - User │
│ - trending │ │ - Event │
│ - profile │ │ - Repo │
│ - search │ └─────────────┘
│ - detail │
│ - code │
│ - issue │
│ - push │
│ - list │
│ - notification │
│ - info │
└────────────────┘
模块依赖关系图
bash
┌─────────┐
│ app │
└────┬────┘
│
┌───────────────────────┼────────────────────────┐
│ │ │
┌──────▼──────┐ ┌─────▼─────┐ ┌──────▼──────┐
│ feature/* │ │ data │ │ core/ui │
│ │ │ │ │ │
│所有功能模块 │◄────────┤Repository │ │ 通用UI组件 │
│ │ │ │ │ │
└──────┬──────┘ └─────┬─────┘ └──────┬──────┘
│ │ │
│ ┌───────┼────────┐ │
│ │ │ │ │
└──────────────┼───────┼────────┼──────────────┘
│ │ │
┌───────────▼─┐ ┌──▼────────▼──┐ ┌─────────────┐
│core/network │ │core/database │ │core/common │
│ │ │ │ │ │
│ Retrofit │ │ Room │ │ DataStore │
│ Apollo │ │ Entity │ │ Token │
│ Model │ │ DAO │ │ Resources │
└─────────────┘ └──────────────┘ └─────────────┘
依赖规则:
app → feature/*, core/ui, data
feature/* → data, core/ui, core/common
data → core/network, core/database, core/common
core/ui → core/common
core/network → (独立模块)
core/database→ (独立模块)
core/common → (独立模块)
技术架构图
scss
┌─────────────────────────────────────────────────────────────────────┐
│ 技术栈 (Tech Stack) │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ UI层 Jetpack Compose + Material 3 │
│ Navigation Compose │
│ Coil (图片加载) │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │
│ 状态管理 StateFlow + ViewModel │
│ Kotlin Coroutines + Flow │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │
│ 依赖注入 Hilt (Dagger 2) │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │
│ 网络层 Retrofit 2 + OkHttp │
│ Apollo GraphQL │
│ Gson / Kotlinx Serialization │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │
│ 数据库层 Room Database │
│ DataStore (替代 SharedPreferences) │
│ ├─────────────────────────────────────────────────────────────┤ │
│ │
│ 架构模式 MVVM + Repository Pattern │
│ Clean Architecture │
│ Unidirectional Data Flow │
│ │
└─────────────────────────────────────────────────────────────────────┘
数据流向图
scss
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ │ │ │ │ │
│ Screen │◄───────┤ ViewModel │◄───────┤ Repository │
│ (Compose) │ State │ (MVVM) │ Flow │ (Data) │
│ │ │ │ │ │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
│ User Action │ Business Logic │ Data Source
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ │ │ │ │ │
│ onClick │───────►│ loadData() │───────►│ Network / │
│ onRefresh │ Event │ refresh() │ API │ Database │
│ │ │ │ Call │ │
└──────────────┘ └──────────────┘ └──────────────┘
数据流:
1. 用户操作触发 UI 事件
2. ViewModel 处理业务逻辑
3. Repository 协调数据源(网络/数据库)
4. 数据通过 Flow 返回到 ViewModel
5. ViewModel 更新 UiState
6. UI 自动重组显示新状态
分层职责
| 层级 | 模块 | 职责 | 主要技术 |
|---|---|---|---|
| 表现层 | feature/* | UI渲染、用户交互、状态展示 | Jetpack Compose、Navigation |
| 业务层 | data (ViewModel) | 业务逻辑、状态管理、数据编排 | StateFlow、Coroutines |
| 数据层 | data (Repository) | 数据访问、缓存策略、数据映射 | Repository Pattern |
| 网络层 | core/network | API调用、网络请求、数据模型 | Retrofit、Apollo、OkHttp |
| 存储层 | core/database | 本地缓存、数据持久化 | Room、DataStore |
| 基础层 | core/common、core/ui | 公共工具、UI组件、资源 | 多语言、主题、工具类 |
可以看到,AI 确实可以大大提高开发的效率,不仅"救活"了已经荒废的老项目,在新项目的迭代上也起到了很大的帮助,这也是为什么 2025 了还能有 GSYGithubAppCompose 的原因。
事实上现在 GSYGithubApp 系列项目存在的意义也就是学习和对比,而 GSYGithubAppCompose 的意义,还提现在 AI 的应用和项目维护上,如何更好使用 AI 去维护一个项目,这对于程序猿来说,还是有一定的必要的,毕竟 2025 作为开发者,真的离不开 AI。
当然,如果你是 Android 原生开发,还没用上 Compose ,那 GSYGithubAppCompose 或者也值得了解下?毕竟如果 Compose 会了,约等于 Compose MultiPlatform 也会了不是么?当然,你也可以说,AI 会就行🤭 。
最后
最后,借着 AI 的风,本次也把所有项目的 Logo 形象都统一,从五个 GSYGithubApp ,到 gsy_flutter_book 文章合集项目,再到 GSYVideoPlayer 播放器和 gsy_flutter_demo 示例项目,现在全都统一使用这个 logo ,虽然没什么设计感,但是我很满意:

再结合 AI ,一个看起来很颠的视频效果就这么出来了:
