老生常谈的技术选型 react native vs flutter ?

[murmur]

总体需求

1 、办公类应用，企业证书，不需要上市场

2 、有集成 fragment 或者 ios 原生组件的需求（第三方提供的 sdk 和界面）

3 、webview 是核心，因为大多数业务是 cordova 迁移过来的，这部分大概有 100 多个页面，所以重写的大概 20-30 个页面左右

4 、重构只是因为 ios 相机启动 wkwebview 白屏太烦了，核心业务准备重写，这部分还得能转成 h5 复用

5 、安卓、ios 开发都是其他开发兼职

选 flutter 的理由

1 、社区热度更高，有很多国内厂商甚至提供官方插件

2 、界面一致性更好处理

3 、google 背书不容易倒

4 、dart 虚拟机编译的东西比 js bundle 不容易反解

选 react native 的理由

1 、jsx 的语法太舒服了

2 、因为 rn 渲染的都是 native ，所以无论集成 fragment 还是 view 都是手到擒来的事情

3 、rn 的 webview 似乎比 flutter 强一些

4 、rn 的 web 比 flutter 好点

不选 flutter 的理由

1 、语法太 tm 畜生了

2 、官方似乎只提供了集成 view 的说明

不选 rn 的理由

1 、直到新架构还是实验期，正式上的只有新的 js 编译器

2 、插件不支持热加载(热加载插件是实验特性)

3 、如果不优化的话包大的可怕（ debug ~50m ，几乎没写什么东西，就路由和一些图标）

大家给点意见？

ios 的相机是不折不扣的 3aaaaa 应用，我拿 instruments 看进程列表，拍照的一瞬间会增加 1gb 的内存占用，然后这部分内存被回收

[shaojian0702]

语法太畜生了，笑死我了

[flyqie]

dart 的语法。。个人确实不太能接受。

基本是看一次劝退一次。。。

[0o0O0o0O0o]

同求建议：
- 三个桌面平台两个移动平台和 WEB 都想要
- 需要上架，apple store 、google play 、ms store
- 无所谓语言，但希望尽可能真的一套代码跨平台
- 尽量能别和原生打交道
- 希望社区火热，不需要自己踩坑

[adjusted]

你这个项目我会选择 react native 。其实 ios 应用排行榜上很多应用都有 react native, 还有 expo 支持，而且我感觉 meta 内部用 react native 应该比谷歌内部用 flutter 多，目前来看 flutter 完全靠谷歌风险反而大很多。而且你这个项目本来就是 web ，开发上手 react native 也比 flutter 容易多了。

[flyqie]

@adjusted #4

go 跟 flutter ，虽然不是同一类。

但感觉 google 给 go 的资源。。似乎还行？

[musi]

dart 这语法，搞个复杂点的布局，嵌套看得我不知道哪是哪

[flyqie]

@flyqie #5

又了解了一下。。感觉。。似乎也不太行。。

[dcsuibian]

我不是这方面的专家，但我还是想要发表一下我的观点，在我仔细看过你的问题经过长时间的思考后，我其实也不知道要怎么回答，正如我一开始说的，我不是这方面的专家。

[dcsuibian]

@dcsuibian 开玩笑的，只能说看团队吧。
如果对 javascript 本身已经比较熟悉了，那么选 react native 。
Flutter 的优点主要体现在其 UI 一致性和性能上。

[debuggerx]

虽然总体来说我是 flutter 派，但是你这个情况，明显还是原生开发最适合吧，核心 webview 又有接原生页面的需求，不管是 rn 还是 flutter 都是脱裤子放屁吧

[debuggerx]

另外 dart 语法其实非常均衡且常规，语言本身没什么好黑的，觉得语法丑的那是因为没有理解 flutter 的设计思想，以及还没领悟到 UI 的本质其实就是嵌套，嵌套的描述性代码才是最符合直觉和原始意义的，觉得嵌套深就找不到北的，一是不够熟悉，二是不会善用 inspector……

[owen800q]

react native webview + H5 ， 不二之選，按你在上面寫的，我想不到一個理由要把部分頁面重寫
camera 相機的直接在 RN 實現，把照片/qr code 之類的結果傳進 H5 不就好了，只要確保把 camera 和 webview 包在同一個組件，完全不會有白屏，只能說寫 RN 的那個開發沒解決過類似問題的經驗

[murmur]

@owen800q 以前是 cordova 的框架，只有一个 wkwebview ，如果调用 ios 拍照，杀的是 wkwebview 的一个进程，然后就会导致整个应用白屏卡死

这个是无解的，微信公众号更严重，毕竟 3A 大作，小程序据说重写了相机稍微好一点，但是还是概率白屏

唯一的方法就是不要用 h5 写核心业务，做 webview 自恢复问题太多了，尤其是涉及一堆页面的数据保存，体感也不好

[murmur]

@debuggerx 不是接近原生页面的需求，是迫于 ios 下白屏被迫重写一些核心业务代码，不涉及拍照的还是用 h5 做，我们的分析是那个页面用了高德地图，新的高德地图是 webgl 渲染，超级吃资源，再调个相机分分钟杀进程

jsx 也是嵌套，好处是几乎所有的样式都可以在 style 里完成，你不需要管原组件提供了什么参数

dart 那种一堆 children 嵌套起来真的是丑陋，他 children 也是要闭合的啊，代码长度比 jsx 小了么，甚至嵌套地狱下 IDE 被迫提供了看闭合的括号是哪个的功能

[kuituosi]

技术上其实没有什么可以比较的，各自生态都能进化。说生态危险的就是搞笑，苹果再牛逼也不敢得罪大量 flutter 用户，要封杀早就动手了。国内应用选 flitter ，国外应用选 rn 。原因是国内应用生态对 rn 支持非常弱，你随便集成第三方的 rn 可能无法提供，但是 flutter 通常都会有。国外恰恰相反，rn 非常流行，提供的第一选项支持是 rn

[owen800q]

@murmur 那只要把原生相關的功能用 RN 重寫就好，UI 相關的沿用原來的 H5 就好了，只要把 webview 同原生組件 包在同一個組件就好，完全不會有白屏

[murmur]

@owen800q

微信 chooseimage 白屏

用这些关键字搜能搜出非常多的结果

微信不会不知道给 webview 包壳就可以把，而且 wkwebview 是多进程，他怎么知道自己被包在哪里该不该 crash

唯一能做的就是业务部分和主界面独立开，这样白屏了做恢复的时候只要恢复业务就可以，不至于主程序也跟着白

[runze]

@debuggerx #11
“另外 dart 语法其实非常均衡且常规，语言本身没什么好黑的，觉得语法丑的那是因为没有理解 flutter 的设计思想，以及还没领悟到 UI 的本质其实就是嵌套，嵌套的描述性代码才是最符合直觉和原始意义的，觉得嵌套深就找不到北的，一是不够熟悉，二是不会善用 inspector……”

这种话可以套给任何东西：

另外 go 语法其实非常均衡且常规，语言本身没什么好黑的，觉得语法丑的那是因为没有理解 go 的设计思想，以及还没领悟到 错误 的本质其实就是 if ，重复的 if err != nil 代码才是最符合直觉和原始意义的，觉得 if 多就找不到北的，一是不够熟悉，二是不会善用 debugger……

另外 XXX 语法其实非常均衡且常规，语言本身没什么好黑的，觉得语法丑的那是因为没有理解 XXX 的设计思想，以及还没领悟到 AAA 的本质其实就是 BBB ，CCC 才是最符合直觉和原始意义的，觉得 DDD 就找不到北的，一是不够熟悉，二是不会善用 EEE……

[cnhongwei]

RN 吧，对 flutter 还有一个不爽的地方就是 json 的处理。

[mynameislihua]

@cnhongwei JSON 处理确实恶心，为什么不能像 java 一样，加个注解什么的自动就生成代码

[moonrailgun]

如果主要是 webview 的话，我的建议是 rn 。因为我调研下来 flutter 的 webview 不如 rn 的 webview 。（甚至本来还考虑过 uniapp 的 w2a 方案不过正如 op 所说太畜生了）

这是我的项目可供参考, 一些与 webview 通信与相互调用的实践: https://github.com/msgbyte/tailchat/tree/master/client/mobile

[xulihang]

@murmur 拍照用 cordova 的插件也会有杀 wkwebview 的问题吗

[murmur]

@xulihang 有啊。cordova 的插件调用的就是官方相机，有考虑过重写一个简陋的相机专门拍照，但是既然微信小程序都没能解决，那除了受影响的功能拿出 webview 也没什么好办法

[n3r0]

需要 h5 复用和 webview 核心，以及集成原生 view 。你这需求用跨平台真是一点好处没捞到呀……还是用原生吧，部分抽出来改写一下。

另外 2023 年了还有人嫌 flutter 的 UI 写法嵌套丑陋，合着拆分是一点都不愿意做呀，写业务逻辑也不至于一个方法从头到尾吧。要是真有那么恶心就不会发展的这么快了。相比于之前安卓写 XML ，几个群里普遍都觉得是好几倍的效率提升，同样 compose 这些新的声明式 UI 框架也是类似的写法，基本就是未来的趋势了。

虽然 flt 问题也不少，说说多窗口字体渲染编辑器输入法候选框 json 解析大家都认同，老看这些吐槽不到点子上的也是很槽心了。。

[murmur]

@n3r0 这是被迫的，我查了那么多资料，能解决 wkwebview 白屏的问题就只有不用 webview ，连微信和微信小程序都搞不定这个问题

我们的问题比微信小程序还严重点，微信小程序拍照一般就是传个发票发个商品，我们有的页面要求拍照几十张，就算缩图内存占用也很恐怖

[murmur]

@n3r0 业务部分代码用原生写太恐怖了，那种复杂的表格和表单用原生渲染，想想都头大，但是因为这部分业务还得能跑在微信（部分页面），所以还是得找个跨平台非 h5 框架

[tool2d]

flutter 写新项目可以，可老项目那么多页面和代码需要推翻重写，工作量巨大，同事未必愿意。

[n3r0]

@murmur 那就只能原生了。。几十张图稍微处理不好就 OOM 了，RN 不知道，flutter 这个场景感觉还比较薄弱，基本没啥自带优化的，缓存啥的都得自己做。

[androidzai]

webview 是核心推荐 RN 。一来 webview 支持好，二来技术栈也比较相似。

[npe]

ReactNative
成熟度来说会好些，这方面招人成本也低一些。

[GTim]

我，我会写 Flutter 插件，但是我不会写 RN 插件，也是无语了

[murmur]

@GTim 我以前维护过 cordova 的插件，贼简单，rn 的插件我也看不懂，除了一大堆 c 、c++的代码外，还有巨复杂的 gradle 指令

[murmur]

@androidzai 放弃 rn 了，体验太差了，那个 metor 编译器动不动就闪退，开了调试模式之后直接 app 都起不来了，也不知道哪个插件出了兼容问题，直接是 so 报错都不知道哪里改

说是 react 结果一堆 js 库兼容问题

[simpleH]

留个脚印，在接触 flutter ，"语法太 tm 畜生了"😭