用 Compose 写 App 可以多快？

休整半年多的我，在今年年后就在思考与尝试我的事业应该怎么走了。其实在去年年终总结中，我已经提及了我的几个方向。

我最开始的方向就是迈入养生行业，虽然我有技术，也有医术，但是没客户，所以我大概需要很长的时间去累积客户，加上现在客户都迷恋让肌肉放松的推拿按摩，以及房租设备之类的开销。还不如找个小公司安心上班来得舒服。可是我又耐不住想折腾的心。

所以我开启了 PlanB，去走中医知识学习领域，虽然现在市面上有一些这类的 app，不过他们都不是真正有中医知识的人主导的，只能说是一堆资源的简单聚合，或者为了卖课而存在。而根本不知道学习中医的痛点是什么，怎样才能真正的提升医术，这就是我的市场了。所以我从零做了一个 app，目前完成了首个版本了。这是真的做一个 app 满足自己的需求。虽然目前功能、数据还很少，但我认为它是有价值的，虽然可能没有钱途。

App 已经在官网villa.qhplus.cn、华为、小米、应用宝、Oppo 的应用市场上架了， 但对于开发而言，并不会懂这个 App 的内容以及结构，毕竟不是为你们而设计的，但是你们可以体验下 Compose 已然是多么的丝滑了。因为这个 app 是全部用 Compose 开发。从立项开始到现在，仅用一个半月左右的时间完成开发，是时候让你们感受下 Compose 开发的速度了。先欣赏下设计稿的数量（辛苦我美丽动人的老婆大人了）。

并且我做的是全栈式的开发，其包括：

1. 
   
2. 思考产品形态
   
3. 用 rust 写后端服务
   
4. 数据爬取、清洗与整理入库
   
5. 用 vue3 写官网、隐私协议等 H5 界面
   
6. 为了上架、登录、push 等要开一个壳公司，跑各种流程（最繁琐、最耗时的工作）
   

即使是 app 端，也要有各种数据逻辑、上报、存储等逻辑，可想而知，能分配给写 UI 的时间能有多少？

当然，这也归功于在去年修整期间我写的 emo 组件库，极大的加速了业务层的开发。

问：为什么不考虑小程序开发，Flutter 开发，RN 开发？

答：小程序挺好的，但是它却很封闭，我想要实现桌面小组件之类的功能，小程序就完全做到，但对于中医条文，用小组件来让我们每天回忆一条条文，是个我个人很喜欢的功能。

而 RN 的性能太差，而且用它，就要牺牲诸如动画、复杂布局等各种场景。并且往往这些需要与原生交互的场景，就要用力十倍才能解决。

不用 Flutter，首先当然是因为我不会，其次是它和 RN 都是 UI 层面，如果和数据层一起考虑，那就没那么简单了。 而我用 Compose，与整个 Android 生态都是打通的，所以性能又高，开发速度又快。何乐而不为？跨平台？各自写就行了，不再去入整体跨平台的坑了。跨平台的坑不仅是技术抽象应对各自生态不是那么稳定的坑，还有人力资源协调的坑。总会让人心累。

下面我们可以来看看 Compose 和 emo 协同开发带来的一些爽点：

界面管理

用 Compose 加 scheme 路由的方式来处理界面跳转、曝光，就非常简单了, 每一个新界面就是一个 Composable，加上 @ComposeScheme 就完了

@ComposeScheme(
    action = SchemeConst.ACTION_THINK_DETAIL,
    alternativeHosts = [HolderActivity::class]
)
@SchemeLongArg(name = SchemeConst.ARG_ID)
@SchemeLongArg(name = SchemeConst.ARG_COMMENT_ID)
@Composable
fun ThinkDetailPage(navBackStackEntry: NavBackStackEntry) {
    LogicPage(navBackStackEntry = navBackStackEntry) {
       // content
    }
}

@Composable
fun LogicPage(
    navBackStackEntry: NavBackStackEntry,
    saveToLatest: Boolean = false, 
    content: @Composable () -> Unit
) {
    content()
    LaunchedEffect(navBackStackEntry) {
        val scheme = navBackStackEntry.arguments?.getString(SchemeKeys.KEY_ORIGIN)?.let { Uri.decode(it) }
        if (scheme != null) {
            // 上报 scheme，作为曝光
            // 保存 scheme，如果用户退出了，直接重入这个界面。 
            // 这个在调试中很好用。例如某个界面，需要点5层才能进去，每次编译重启就要点5次才能看到这个界面，那就蛋疼了，所以如果每次把它记录起来，启动就进去，那开发就顺很多了
        }
    }
}

界面状态

很多界面基本上就是列表，然后就有空界面、错误提示情况，列表，列表可能还有加载更多。在原来 View 体系，就要做各种 View 的显示隐藏操作，写起来贼麻烦。 用 Compose 封装起来就简单了。 看我的封装结果

val logic by vm.thinkFlow.collectAsStateWithLifecycle()
LogicBox(
    modifier = Modifier
        .fillMaxWidth()
        .weight(1f),
    logic = { logic },
    reload = {
        vm.reload()
    },
    emptyText = "空"
) { list ->
    // 列表数据
}

把它往 LogicPage 里面套就完事了，当然这也是数据逻辑层我抽象了强大的 logic 逻辑。借助这个逻辑，可以分分钟完成数据的从网络数据拉取，再到读存 DB，再到界面的渲染，可以快速补充完成空界面、加载出错、加载更多、下拉刷新等功能。

多级评论

看我这个思辨详情页面，假设以旧的 RecyclerView 体系来做这个，想想都痛苦。而我是数据逻辑层加UI一起两三个小时搞定, 毫无 bug。

另外这里还有一个“从通知点击进来滚动到当前评论”的场景，如果是原生或者 RN 来做，最痛苦的事情就是滚动时机了，一般最终会使用 post 万能大法大法，然而总有没滚动的情况发生，然后产品就找过来了。

而 Compose 也就是一小段代码的事了：

if (vm.targetCommentId > 0) {
    val targetCommentIndex = remember(vo) {
        indexOfTargetCommentId(vo, vm.targetCommentId)
    }
    if (targetCommentIndex > 0) {
        LaunchedEffect(Unit) {
            vm.listState.scrollToItem(targetCommentIndex, 0)
        }
    }
}

嵌套滚动

看看这个一般的嵌套滚动界面

即使有 NestedScroll 或者 CoordinatorLayout，但新手用不懂，高手也容易遗忘某些配置而踩坑。

那么 Compose 需要多少代码呢？

val nestedScrollConnection = remember {
    object : NestedScrollConnection {
        override fun onPreScroll(available: Offset, source: NestedScrollSource): Offset {
            if (available.y < 0 && vm.scrollState.canScrollForward) {
                scope.launch {
                    vm.scrollState.scrollBy(-available.y)
                }
                return available
            }
            return super.onPreScroll(available, source)
        }
    }
}
Column(
    modifier = Modifier
        .fillMaxSize()
        .verticalScroll(vm.scrollState)
        .nestedScroll(nestedScrollConnection)
) {
    BookInfoBasic(info)
    BookInfoPageTabSegment(vm = vm)
    HorizontalPager(...)
}

这样就完成整个界面了，其实也是对 nestedScroll 的封装，道理和 View 体系一样，只是用起来更方便了。

ChatGPT

ChatGPT 对于 Compose 而言，很不好，毕竟其训练依赖的是旧版本，所以会有很多错误，所以不能用的，但是它在逻辑层面就很好用了，例如文件上传、下载等，我都是让它写，写完自己校验下，就完工了。为了赶时髦，我当然也在 app 里接入了 ChatGPT，当然，我做了配置，目前对外不开放。

漫长的审核

正如文章开始所说，开发我用了一个多月，但是后面的审核上线则是用了两个月左右，其实说到底还是对规则的不熟悉。在电子版权、安全评估报告等环节都是在处理一份之后才知道必须要另一个，所以化并行为串行了。并且做安全评估，给我的感觉就是我的 app 分分钟有上百万的日活，实际上整个圈子可能不过数万人，但我也得完成相应的功能，例如接入飞书机器人，在飞书群里完成内容审核功能。

所以这两个月，最多的就是认识到了整个市场，在公司注册、记账、上架等各个环节衍生的无数商业行为，很多都是收智商税和信息差赚差价的。所以中国有商业头脑的人还是很多，在各个小环节拉拢豪绅、巧立名目，只要有信息差，我就可以无限拉高价格。因为也铸就了现在创业那高不可攀的围墙。

当然，我已经进到墙内了，如果能够成功，那这个墙就是对我的保护了，毕竟干的又不是 ChatGpt 那种无法轻易复制的产品，所以这堵高墙就可以为我争取更多的成长时间了。

在这两个月，我打造了另一款产品：emo-ai。最主要的功能就是 ChatGpt 的代理，目前维护了一个小用户群体，收到了第一桶小金。

此外，我也了解了下 StableDiffusion，本地搭建了 StableDiffusionWebUi 的环境，了解它的 prompt 玩法、 controlnet、lora 之类的知识。绘图入魔怔~

最后

ChatGPT 的爆火，让人们见识到了 AI 的力量，开发、设计、文案等领域，都快被取代了。中医这个领域，虽然目前完全没有被波及，但我以前曾提过：

**治疗 = 根据【当前的症状/指标】推荐出【相应的药物】

所以医学本质是一个推荐系统，西医强调靶向治疗，中医则是用阴阳五行之类的建立了一个巨大的模型，从这个角度上来讲，中医显然更胜一筹。

但是深度神经网络时代，显然我们可以训练参数规模更大的模型，来完成辨证论治的过程。

但是模型的训练，少不了数据的支撑以及模型的建立。

数据来说，中医有几千年的数据积累，是世界上最大最全的资源，只是需要整合与结构化。

而模型最为重要的是模型的结构是怎样的？损失函数、优化器如何定义？经过长久的学习，我已然有了一些思路，也是我跨领域融合所独有的见解。

但目前数据还不是结构化的，GPU 也不是我能买得起的，所以这条路还很长，也是岐黄小筑想要承载的梦想。

拥有梦想，也要脚踏实地，因为我目前做的事情就比较苦逼了。我要把一本本书籍的拆分出来，存成结构化的数据，并对内容做链接，用技术只能得到模糊的结果，最后还要自己去校对。录入系统的管理后台也还在建设中。

所以， 最后再吹下 Compose， 为我节约了大量的时间。在 View 时代，鉴于喜欢写 UI 和能够写 UI 的人真的偏少，我大概能够一次性取代 6 个业务开发，那在 Compose 的加持下，也许取代 60 个业务开发也不是什么大问题了。