西瓜课表 从5月30号晚上的灵机一现，到79天后的今天，基于CMP迁移开发后的新版本西瓜课表终于正式发布了。

在这段时间内首先使用WhatAnime完成了CMP替代Jetpack Compose的技术踩坑与框架可行性检测，然后就是花了大量的时间来完成从多Activity到单Activity的代码迁移，学了不少东西，最后借助AI对一些以前不合理的UI设计进行重新设计与重构。

中途也不乏短暂尝试过腾讯的Kuikly，最后还是选了CMP，看中的就是它的发展潜力。

只是这种跨端开发的情况下，xcode编译实在是太慢了，之前我还以为是10分钟左右，昨天刻意搜了一下怎么查看xcode的构建日志，才发现编译iOS的时候，gradle task执行了17分钟，哪怕是通过AS编译运行到模拟器上，执行一次也要花费4分钟左右，这是最不爽的地方了……

不过这一套打通之后，以后不用专门针对iOS进行编码和测试了，直接针对Android端开发，后续专门在iOS上进行调试，最后完成发版，效率++

西瓜课表 Android Compose 还得是周末这种大段时间才能干这个事情，新的仓库现在已经可以编译运行了，只不过以前是多activity的方案现在需要改成navigation导航的形式，其中涉及的主要是布局的迁移，毕竟以前是个Activity，是个类

西瓜课表 记录 Android 今晚大致研究了一下cmp，也初步尝试了一下多端的开发，现在确认的是目前西瓜课表使用的依赖库都支持或者在cmp部分存在替代

所以后面会花一段时间尝试使用cmp来进行Android与iOS的同步开发，此前虽然已经使用flutter单独开发了iOS版本并且上架了AppStore，但是这种双线开发的情况也极大的拖慢了一些新的想法的开发进度（特别是iOS端打包和调试强烈依赖macos，因此iOS端开发进度非常慢）。

借助cmp可以实现优先对Android进行功能开发，然后等界面以及功能稳定之后花少量的时间切换到macos进行iOS端的调试，这样能让对于macos的依赖大大减少。

要说缺点的话就是对于多出来的鸿蒙端的不确定性，cmp现在没有官方下场对鸿蒙做相关适配，虽然腾讯在搞kuikly，但是我在kuikly的初尝效果并不是很好，自提供组件相当于要把现有的Android布局代码几乎重新写一遍（倘若要这样我为什么不直接想办法用flutter来作为核心开发？至少现在flutter比腾讯这东西稳定成熟吧），不过个人对于鸿蒙并没有太多好感，没版本就没版本吧，非要用就拿些网页版先顶着用吧。

西瓜课表 佛了，查了半天问题我还以为是我代码有问题或者 feature-hub 部署配置不正确，结果是2022年整的一个feature

具体表现就是 client-java-android 有时候就突然卡住了，抓ANR最终定位是在请求边缘节点的时候迟迟没有得到请求成功的标识导致整个代码逻辑卡住，继续抓请求发现和轮询间隔有关系，然后发现当轮询间隔到达时，第二次带有相同参数的请求因为服务端数据没有变更，边缘节点响应了304状态码，本身这个逻辑没有错误，但是 client-java-android 并没有对304做处理，也没有做任何兜底逻辑，最终导致“请求成功了”，但是sdk不知道一直在死等结果

https://github.com/featurehub-io/featurehub-java-sdk/blob/main/client-java-android/src/main/java/io/featurehub/android/FeatureHubClient.java#L203-L231

西瓜课表 快一个亿了

西瓜课表 希望下周一的使用高峰期，不出啥大问题

西瓜课表 十分规律的告警，全部是使用高峰期

西瓜课表 看着这个监控，心情就像过年了一样高兴，虽然高峰时候还是很多失败，但是至少55开了

西瓜课表 找用户要了一些 VPN 账号，然后给整了个小的集群，搭配 feature probe 做了分流，看着成功率上升了 😂

至少证明，这个问题和VPN有关系

瞬间 西瓜课表 峰值应该是这样了