jetpack compose,xml layout 与 flutter 的选型问题

更新日期: 2023-05-17 阅读次数: 1357 字数: 1290 分类: Android

这个周末无论是去公司团结的路上,还是一家去永旺吃饭的间隙,我都在纠结这个事情。也是用这些零碎的时间片段在手机上整理了这篇笔记。

纠结的原因

计划将一个一年前用 jetpack compose 写的练手 android app 重构一下。没想到在没有任何推广,维护的情况下,积累了一些用户。

重构的原因是,有一些用户反馈的需求,我想实现一下。但是使用的 jetpack compose 版本太旧了,毕竟 compose 还处于飞速发展解决,一年一个新样子,甚至今年都成了 android studio 的默认模板。今年用新版本的 as 编译,一堆错误,甚至提示 kotlin 的版本都过低。导致没法继续维护了,只能重构。(现在看真是没必要频繁升级 as)

于是,就产生了技术选型的困扰。我不太想这么早就押注 compose,想稳定之后再大规模使用。代码脚手架还是以 xml layout 为主,一些繁琐的循环列表,或者不重要的页面再使用 compose。当然能不使用更好,不想因为 compose 破坏性版本升级再去维护了。

纠结 flutter 是因为看到一个开源的项目非常符合我的一项需求,我想偷懒在其基础上开发。但是 flutter 的安装过程就把我恶心到了。

jetpack compose

  • compose 项目初始化时,依赖的包太多了。等待时让人烦躁不已,关键是我非常担心这会发展成类似 js 框架那种动辄依赖上万个垃圾包的状况,以后升级存在巨大的不确定性。而且这必然会影响打包的体积
  • 我对声明式 UI 确实不感冒,就像 react 一样,时间一长不接触,语法就忘了。不如 xml 可读性好,随时都能上手修改,没有阅读障碍
  • 看上去还是不成熟。在 XML View 已经成熟的情况下,去尝试一项新技术,如果他没有解决自己的痛点,没必要花时间在上面
  • 预览不方便

flutter

flutter 的最大优势是跨平台。android,ios,Windows,Linux,web 通通支持。看起来非常有吸引力。但是逐个拆解分析一下,会发现,所有的跨平台特性我都用不上。

  • android:无论是 xml layout,还是 compose,都有基本的了解。没必要再额外学习 flutter,增加了学习成本。而且项目中用到的三方硬件(STM 蓝牙芯片)给出的示例代码都是原生开发,基本都是 java,连 kotlin 用的都少。
  • ios:估计业余搞的 app,连开发者账号的成本都不一定能收回。目前所在公司的业务也偏制造业,大多数用的也是 android。
  • Windows:非原生开发,上不了 Windows store,个人开发者也就无法享受平台流量,那开发就没有意义了。再回到公司内部开发,制造业更多用到的是硬件控制相关,而 flutter 只是界面部分,涉及到底层控制估计还得用原生接口,反而增加了复杂度。实际上 c# 的 wpf,winform 开发已经非常方便了。
  • Linux:目前没有遇到过类似需求,而且对个人开发者很难推广
  • web:flutter 没法做 seo,基本废了。

同时也因为咸鱼团队整天鼓吹 flutter,而其开发的 app 体验如同狗屎一般卡顿,所以一直印象很差。直到看到上面提到的那个开源项目,实际体验之后,非常流畅,才对此有所改观。

感觉 flutter 更适合需要迅速多平台出原型的互联网使用场景,至于制造业,以稳定性、高效性为目标的行业并不是适用。再就是敢做这种选型的基本都是大公司,有足够的人手,和技术能力去填坑,小公司或是个人耗不起这个时间。

选型结果

重构掉之前的 compose 项目,用 xml layout 为大架子,把 compose 部分迁移过来。也不再使用 compose 的 navigate router。至于 flutter,还是留给能折腾的少年吧。

值得投资的技术

对个人开发者,或者小团队来说,技术的稳定性很重要。在不确定性的新技术上投入过多精力,严重影响开发效率。例如,之前看过一个案例,一个国外的工程师,业余二十年开发了一套游艇设计软件,使用的是目前世面上并不流行的 delphi。所以说,是否是新技术并不重要,重要的是稳定性,是否可以基于一项技术做到持续的输出结果,研发出新功能,新产品。

而不是什么技术火,就去跟风。因为互联网上讨论的新技术,你很难判断是否是真的火,是否真的有人在真实项目中广泛使用。也许是大公司出了推广费让it新闻网站写软文,也许是技术布道师在完成kpi,也许是为了晋级搞的满是bug的新轮子在做宣传。总之,要冷静观察,试试可以,但不要一开始就投入过多精力。

现在看 asp.net spring 这些真是经典,虽然迫于内存不足不敢上 spring boot,但确实是值得押注的技术。

我尝试过的不靠谱技术

  • weex,对标 react native 的跨平台方案。这个坑巨大,卡顿严重。自此我对 js 框架,跨平台,阿里开源,这几个关键词都长期抱有警惕性。
  • laravel。转型 php 的一个尝试,但是性能差到离谱。虽然这个博客的诞生得益于这个框架,但是自从发现性能隐患之后就转投 golang 方案了,再也没回头。

回头看看,真是不值得花费时间在上面。

关于作者 🌱

我是来自山东烟台的一名开发者,有敢兴趣的话题,或者软件开发需求,欢迎加微信 zhongwei 聊聊, 查看更多联系方式