用 Compose 写 App 可以多快？

这篇文章写于 2023 年 3 月初，原因是审阅上线流程走了接近两个月，嘿嘿~

休整半年多的我，在本年年后就在考虑与测验我的作业应该怎样走了。其实在去年年终总结中，我现已提及了我的几个方向。

我最开端的方向便是迈入养生职业，尽管我有技能，也有医术，可是没客户，所以我大概需求很长的时刻去累积客户，加上现在客户都沉迷让肌肉放松的按摩按摩，以及房租设备之类的开销。还不如找个小公司安心上班来得舒服。可是我又耐不住想折腾的心。

所以我敞开了 PlanB，去走中医常识学习范畴，尽管现在市道上有一些这类的 app，不过他们都不是真正有中医常识的人主导的，只能说是一堆资源的简略聚合，或许为了卖课而存在。而根本不知道学习中医的痛点是什么，怎样才干真正的提升医术，这便是我的商场了。所以我从零做了一个 app，现在完结了首个版别了。这是真的做一个 app 满足自己的需求。尽管现在功用、数据还很少，但我认为它是有价值的，尽管或许没有钱途。

App 现已在官网villa.qhplus.cn、华为、小米、运用宝、Oppo 的运用商场上架了， 但关于开发而言，并不会懂这个 App 的内容以及结构，究竟不是为你们而规划的，可是你们能够体会下 Compose 已然是多么的丝滑了。因为这个 app 是全部用 Compose 开发。从立项开端到现在，仅用一个半月左右的时刻完结开发，是时分让你们感受下 Compose 开发的速度了。先赏识下规划稿的数量（辛苦我美丽动人的老婆大人了）。

而且我做的是全栈式的开发，其包含：

1. 考虑产品形态
2. 用 rust 写后端服务
3. 数据爬取、清洗与整理入库
4. 用 vue3 写官网、隐私协议等 H5 界面
5. 为了上架、登录、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 个事务开发也不是什么大问题了。