为何长理星球App的iOS端和Android端区别这么大
今天在直播间开着直播和朋友聊天写代码的时候，突然聊到了长理星球安卓端，朋友也比较熟悉我的 iOS App，但是他不了解 Android App 长什么样子，于是就给他看了一下。作为长理星球 iOS 端目前唯一的开发者和维护者，我觉得有必要说明一下，为何 iOS 端和 Android 端的区别如此之大。
24 年 11 月 12 日，刚入大学的我在学长的推荐下了解了长理星球的项目，当时的我还主要是在学习前端开发（React），然后刚好有这么一个项目需要做一个后台管理系统，于是加入了团队。
其实加入后一直都没做什么事情，甚至可能还有点捣乱，好好的 Vite 开发 React 的项目被我要傻逼的搞成了 Next.js，不过所幸没搞出什么幺蛾子。中间也没发生什么事情，转机在于 25 年三四月份，我把我的主力手机从安卓换成了 iOS，当时那段时间也在纠结以后找工作要找哪方面的工作，我个人是不太喜欢前端，于是在 25 年六七月份的时候就开始学习 iOS 开发，准备至少毕业了先找一个 iOS 开发相关的工作。
刚好长理星球 App 没有做 iOS 端，只有一个 Android 端，我本来让 AI 来帮我 Vibe Coding 了一个 Demo，叫做 CSUST Box，功能类似长理星球，甚至当时的我基本上都不会写 Swift，就整出了这么一个项目，甚至也能跑。支持查宿舍电费，查成绩，查课表和查考试安排。
刚好呢，当时那段时间在忙于期末考试，所以这个 CSUST Box 项目就搁置了。并且期末考试之后，经过思考，我就准备正式进行长理星球 App 的开发了，毕竟这个 App 没有做 iOS 端，所以我就直接变成了长理星球团队中的 iOS 开发。于是旧的 CSUST Box 这个 Vibe Coding 的产物就被我丢掉了。
不过在开发 App 之前，我没有计划直接开发 App，而是准备先开发最重要的爬虫库CSUSTKit。因为我不想让我的 App 局限于教务系统的那些功能，我希望我的 App 能够支持网络教学平台，所以我在一开始入手的时候就选择了往长沙理工大学的统一身份认证下手（authserver.csust.edu.cn），因为登录了统一身份认证就可以直接登录教务系统和登录网络课程平台。
所以就看 CSUSTKit 的 GitHub 提交记录，我从六月底开始开发，一直开发到七月初，基本上实现了学校各个系统最常用的接口，以及各个系统与统一身份认证的登录认证。
在爬虫库基本写完后，我就开始了 iOS App 的编写，其实我认为这里就是分歧点，分歧的原因要从长理星球 Android App 的架构讲起。
长理星球 Android App 的核心功能全部依赖于他的后端服务器，首先进入 App 就需要登录一个“长理星球”的账号，随后再绑定学校教务系统的账号，然后每次查询成绩，或者查询课表都需要把用户的教务系统账号密码上传到云服务器（并且还是通过 HTTP 传输，而不是 HTTPS），上传到后端后，后端再调用学校教务系统的接口来登录，来查询数据，最后再将数据返回给 Android 端进行显示。我看了甚至后端的接口返回的数据有些情况下还不是完全解析的数据，而是直接从教务系统上爬取下来的原始字符串数据，例如“1-15(周)[03-04 节]”这种字符串。
说实话我当时看到后端的 Apifox 文档我是头皮发麻的，接口文档也不清晰。并且我认为最核心的一点：相关的查询操作必须要在客户端进行，完全没有在服务端进行的意义，原因如下：
- 能够有效减轻后端压力
- 能在客户端做的事情，为啥要在服务端做
- 万一学校封禁了后端服务器的 ip 地址，那就会导致所有用户无法使用 App
- 要传输用户账号密码到服务器
当然说实话，这些东西在服务器上也有服务器的好处，好处就更新的时候可以覆盖到所有用户，但我觉得总体来说还是弊大于利。就以长沙理工大学尿性，隔三差五就会把某个系统变成仅内网开放，这些查询操作在服务器上就完全用不了了，要是在客户端的话如果用户的设备连接了校园网的话，还可以进行查询。
所以这一点方面就产生了分歧，我坚持我的想法，把这些操作放在客户端上进行。
接下来就是第二点：社区功能的设计。
按照开发团队的想法，这个 App 要做一个交流社区（新鲜事），可能类似于百度贴吧那种社区。如果我需要在 iOS 端接入的话，我就也得需要让用户登录一个“长理星球”的账号，但其实我觉得这一设计十分的多余。既然使用我的 App 要登录学校的账号，并且如果“长理星球”账号要与用户个人信息强绑定的话，那完全可以设计成为本地登录统一身份认证，然后传输一个统一身份认证的 Token 到服务端，服务端验证 Token 有效，再给用户返回一个长理星球自己的 JWT。也就是说设计成用学校的账号来登录统一身份认证的账号。
这样设计的好处是：
- 方便监管，既然有提到过，之前的长理校园 App 下架是因为其中社区的灰产泛滥，设计成这样后任何发布人都有实名身份，可以针对进行监管和封号
- 减少重复登录，完全没必要设计成用户登录长理星球账号，再绑定一个学校系统的账号
最后我的这个设计想法其实也没采纳，说实话搞后端的同学可能也是比较忙，估计没这个心情折腾我这个想法，可能也想的就保持原样挺好，具体我也不太记得了，最后就没有然后。后端也没做设计，那我也只能搞我自己的活了。
所以在此之后我的 iOS App 开发我就按照我个人的想法来开发了，没有接入任何的 Android 所用到的后端，所以这就是技术上 Android 端和 iOS 端的区别。
接下来还有一点，就是 UI 设计。
我一直觉得长理星球 Android 端的 UI 设计不合我口味，而且我觉得很丑。虽然说实话，我也不觉得我自己做的 iOS App 有多好看，但是我基本上无法接受 Android 端的 UI 设计。
还有一个问题，就是人员多，但是活跃的贡献者不多。虽然项目设计之初的意义主要是给大家一个学习的平台，大家通过这个项目来学习并提高自己的开发技术。进入项目组的人有数十人。不考虑以往的贡献者学长（部分已经参加了工作，无法维护项目），还有不考虑一些其他的项目组熟人同学，真正还在维护项目的人寥寥无几。其实就只看没参加工作的同学，目前这些同学里面维护项目的人也只是少数。而我是一个闲的蛋疼的傻逼，就只有我最闲了没事就去写一些东西。
并且我认为我不能够这么自私：我开发了 iOS 的这个 App，我不负责 Android 的开发，还要求 Android 设计成和我这样。我认为这是很自私的行为。
但是我也不想按照 Android App 那样设计 iOS 的 App，所以总的来说，长理星球 iOS 端和 Android 端的 UI 设计，技术架构和各个页面设计结构完全不一样，以至于就像是完全没关联的只是名字和图标一样的 App，原因大概就是以上了。
上面讲完了两个 App 的不同，接下来再补充一点后续的故事
后续一段时间，长理星球托管在华为云的后端服务器过期了，虽然在此之前 Android 端的大部分代码就已经开始迁移到本地客户端进行的网络库（类似我的 CSUSTKit），但是仍然有大部分用户没有更新 App（这算不算 iOS 有 App Store 的好处），所以还有很多用户停留到了使用后端的版本，并且由于准备不充分，本来更新新版本，客户端进入 App 时会检查有没有新版本更新的。但是时间过于匆忙，所以大部分用户都没有进行更新，而是停留了旧版本。
其实按理来说就算是服务器过期了，只要更换服务器，改变一下 DNS 地址就可以了的。但是问题在于：Android 端配置的后端地址是 IP 地址，而没有配置域名，导致出现如此严重的问题。
还有一个故事，某一天学校的教务系统的登录突然添加了一个验证码输入，用户登录教务系统账号的时候必须要输入一个验证码。教务系统的这一行为直接干穿了所有的类似软件，除了我的 iOS 端没有受到影响，因为我的设计中，是从统一身份认证登录教务系统的，而统一身份认证一般情况下登录不需要输入验证码，从统一身份认证登录教务系统也是走的sso.jsp，所以我的架构完全没有受到影响。而其他的所有 App 都需要调整架构方案了，例如要加验证码识别，或者重新编写爬虫。
所以现在的长理星球 Android App 也是一样，走的统一身份认证登录了。不过页面设计还是和原本一样，所以就算是走统一身份认证，设计出来的页面架构和我做的 iOS App 也是完全两样。
不过现在 Android App 正在进行 Compose 相关的重构，目前的正式版 Android App 各个页面设计还有点割裂感，不过以后应该也会变得越来越好的。
最后，关于这篇文章，我写这篇文章只是记录一下截止 2026 年年初的我和这个长理星球项目的故事，不意味着我对项目组的任何团队成员有意见。虽然同名 App 的 iOS 和 Android 设计上（不管是 UI 还是整体）完全不一样，每次别人提到这一点时，我都会觉得有点尴尬，不知道如何回复。我也不知道我这么选择是不是对的，我只是想做我觉得应该做的事情。我依然希望这个项目能够继续走下去，让这个项目变得更完善，能为所有同学提供便利。