做一款轻量课表，最后死在能推广出去

GSH 课程表的开发复盘

市面上的课表 App 已经不少了。

它们能查课表，也常常把许多其他东西一起塞进来：校园资讯、社交、成绩查询、兼职信息和各种通知。功能越来越多，课表本身反倒成了其中一个最不起眼的入口。

对我来说，课表是个很简单的工具：打开手机，看看今天有什么课，然后关掉 App。为了这几秒钟，我不太想先经过雷霆摇一摇广告、活动页和一堆自己用不上的功能。

所以我想做一个更轻的课表。

GSH，Great Schedule Helper，就是从这个想法开始的。它希望把注意力放回课程安排本身：打开就能看课表，能快速切换周次，不需要的东西尽量不做。没有广告，不做校园社区，也不希望后台一直运行。

从一个开源项目开始

GSH 不是从空白项目写起的。它基于 YZune 的 WakeUpSchedule 二次开发，也承接了已有的学校适配工作。我在这个基础上继续适配银杏学院的新版正方教务系统，并调整应用界面和课表功能。

这个选择让我能把精力放在自己真正需要解决的问题上，但也意味着需要先理解已有项目的结构，再判断哪些地方适合修改、哪些地方要重新实现。开源项目给了我一个很好的起点，也让我更清楚地看到，一款课表 App 并不只是把课程画在屏幕上那么简单。

开发过程中，我完成了 Jetpack Compose 和 Material 3 的界面迁移，调整了学校的课程时间和学期周数，加入公告功能，并改进了桌面小部件。课表数据可以从教务系统导入，课程单双周也会自动识别。项目使用 Kotlin，整体采用 MVVM，数据层涉及 Room，网络请求使用 Retrofit、OkHttp 和 jsoup。

这些技术名词写在一起很像一份功能清单，但实际开发时，麻烦往往藏在它们之间。

最难维护的部分，是教务系统

教务系统没有稳定、公开的接口文档。所谓一键导入，很多时候就是登录系统、获取网页内容，再从页面里找出课程名称、教师、教室、时间和周次。

只要教务系统页面结构发生变化，原来的解析逻辑就可能失效。对用户来说，表现可能只是“导入失败”；对开发者来说，则要重新观察页面、检查请求，再一点点找出变化发生在哪里。这样的适配很难一劳永逸，也很难只靠写一次代码就结束。

课表本身还有一些看似细小、却会直接影响日常使用的问题。学期从哪一天开始算？单双周课程在当前周应该怎么显示？课程名称、教室和教师信息都放进一张课程卡片时，怎样避免内容挤在一起？

我最后选择用透明度区分非本周课程，并移除了卡片上额外的单双周文字标识。界面能表达清楚的事情，就不再重复写一行说明。这个决定不复杂，却很符合我最初做 GSH 的方向：能让课表更清楚的留下，会增加干扰的尽量拿掉。

让它轻一点，也让它快一些

开发过程中，我也花时间处理课表页面滑动时的卡顿。v1.0.5-beta 的更新里，我调整了构建方式，也修复了左右切换周次时的性能问题。发布记录里测得的主线程单帧耗时中位数从约 9 毫秒降到了约 1.3 毫秒，切换周次的首帧耗时也从约 240 毫秒降到 30 毫秒以内。安装包则从约 25 MB 减少到约 12.8 MB。

这次经历让我意识到，性能数据也会受到构建方式影响。debug 包和 release 包的表现并不一样。如果只根据 debug 包的感受判断问题，很容易把时间花在错误的地方。后来我把构建优化和代码优化分开看，才更能判断真正的瓶颈在哪里。

体积、启动速度和后台行为，都是 GSH 想认真对待的部分。它不需要为了“看起来功能丰富”而一直运行，也不需要把课表之外的内容都塞进来。至少在产品取舍上，我一直希望它能保持克制。

做出来，不等于有人愿意换

GSH 最终没有推广开。

这是我停止继续开发的主要原因。App 做出来了，功能也逐渐完善，但在学生中始终没有形成有效传播。课表属于一种很稳定的工具：很多人开学时装好一个 App，用习惯之后就不太会再主动寻找替代品。即使新产品更简洁，也需要先让人知道它、相信它，再愿意花时间安装和迁移。

对个人开发者来说，安装包的分发也不是小事。通过应用商店安装和从网页下载 APK，给人的信任感并不一样。对开发者而言，提供下载链接只是发布；对第一次看到链接的同学来说，却还要判断这个应用是否可靠、安装是否麻烦、值不值得换掉已经在用的课表。

而课表 App 还面临学校适配的问题。不同学校的教务系统可能完全不同，每增加一所学校，就多出一份适配和后续维护工作。适配范围小，用户就少；用户少，也很难吸引更多人帮忙适配。这让一个原本面向学生的工具，很难只靠产品本身自然扩散。

我最初关注的是“现有课表 App 太臃肿”，但开发结束后看到的是另一面：用户不一定会因为一个工具更简单，就主动迁移到它。产品解决了一个真实的不满，和产品能不能被目标用户发现、接受、持续使用，是两件不同的事。

停下来的原因，不是功能做完了

GSH 停止开发，不是因为课表已经没有改进空间，也不是因为所有技术问题都解决了。教务系统适配、设备兼容和后续维护，都还有事情可做。

只是继续投入时间，需要一个能支撑下去的理由。对我来说，GSH 在学生中没有推广开，用户规模和反馈都不足以支撑持续维护。一个依赖学校教务系统的应用，还需要开发者跟着系统变化不断修复；如果没有足够的用户，也没有其他人接手，这份维护成本最终就会落回开发者一个人身上。

因此我选择停下来。这个决定不代表当初做轻量课表的想法是错的，只是我没能找到让它被更多学生使用的方式。

留下来的东西

回头看，GSH 没有成为一款被很多同学使用的 App，但这段开发经历仍然教会了我不少东西。

我从一个已经存在的开源项目出发，理解它、修改它，再把它适配到自己的学校；我把界面迁移到 Compose 和 Material 3，也处理了教务数据解析、单双周显示、课表布局和性能问题。更重要的是，我亲自走完了从“发现一个问题”到“做出产品”，再到“发现产品推广不出去”的过程。

以前我觉得，只要把东西做好，自然会有人来用。现在我会把产品的传播和维护也算进开发的一部分。功能完成只是一个节点，不是项目成功的保证。尤其是面向学生的工具，能不能被看见、安装和推荐，和它写得好不好一样重要。

GSH 基于开源项目而来，源码也继续留在 GitHub，官网则记录了它的功能、下载方式和更新信息。它没有成为我想象中那款广泛使用的课表 App，但它确实把我最初的想法做成了一个可以安装、可以使用、也可以继续修改的产品。

我做它，是因为觉得课表 App 不应该那么复杂。后来我停下来，是因为做出一个更简单的课表，还不足以让学生愿意换过去。

这大概就是 GSH 留给我的结论：把产品做出来很重要，但从一开始就想清楚它如何抵达用户，同样重要。

此后我可能会再写一版的release，作为这个项目的句号

正如我在app里写的那样，道阻且长，行则将至，后会有期

项目地址：GSH 课程表 GitHub
产品官网：gsh.2lnz.top