移动端技术选型，军师们有啥建议？

[maxmax4max]

做一个电商 APP （ iOS 、Android 、小程序），会涉及到比较复杂的页面：K 线走势（需要处理走势并深度自定义 UI 和交互）、动画效果、30%的页面都比较复杂类似京东商品详情页。整个页面数量大概 200-300 ，前后端+产品+测试 10 人左右，开发周期还没确定。

考虑以下技术方案，按喜好排名：
1 、react native ，一端开发多端使用，可以热更，组件一致性差点，小程序单独做
2 、flutter ，一端开发多端使用，组件一致性好，小程序单独做
3 、uniapp ，可以覆盖所有端，性能稍差，插件质量不一
4 、iOS 原生+Android 原生+小程序单独开发

[Razio]

要是我说都走 webview 会不会太省了点

[chiaf]

选 4 利好就业👍

[ala2008]

只能说 uniapp 很坑，发版一次还得收钱哦

[maxmax4max]

@Razio webview 体验太差了，to C 的商城怎么可能全 webview 呢，活动页是可以。

[maxmax4max]

@chiaf 选 4 最多是 3 个人分别开发 3 端，其它方案估摸着也要 2 个前端协同开发，差别不会太大。

[liaozzzzzz]

个人选一，rn + taro （ react ）方案，多个前端负责不同业务模块多端开发，要求把业务逻辑抽离到 store 或者 hooks 便于 app 和小程序复用，专注于交互的区别开发就是了

[zzjun]

4 把 体验拉满

[qxmqh]

3 不用说了。等以后有钱了，再换 4 。不然都是扯淡的。先把东西搞出来，商城 就是卖东西的说实话，你做的再好看，东西没有性价比，也没人用的。别陷入到技术误区。

[maxmax4max]

@qxmqh 客源不担心，之前就积累了不少用户。

[fffq]

哪个出活快用哪个

[HolidayBomb]

分析的已经很透了，已经按喜好排名了，自然是 1 了，不过 RN 要找有客户端经验的会好一些

[zy0829]

4

[hellomimi]

一次性多端？不如前期只做小程序版本，降低试错成本。
小程序试运营符合预期的话，直接再加人，iOS 原生+Android 原生。
===
以我的经验，电商类平台，和技术选型有点关系，但是关系没那么大（不要太拉垮，影响用户体验）。更侧重于运营、选品...等和技术无关的环节。

[sheeta]

kotlin multiplatform + 小程序

[sdads12]

@maxmax4max #4 pdd 几乎全是

[murmur]

没钱建议放弃幻想，200-300 个页面要动画要交互，预算多少啊？？

[LOWINC]

webview 做好了体验不差的

[maxmax4max]

@sdads12 pdd 怎么可能全是，首页、个人中心、聊天、详情、规格弹窗都是原生。

[maxmax4max]

@murmur 有上市公司背景，所以预算还好，会综合考虑性能、开发周期。

[maxmax4max]

@LOWINC 这块太难了，我看 pdd 这块不错，活动页的性能堪比原生，其它家都去卷跨端框架了。招一个能 crud 能优化这块内容的，估计抵 2 、3 个人的工资了。

[bengcaca]

@hellomimi 方案+1 。

1. 先小程序验证
2. 确定没问题后客户端直接上 Flutter
3. 等确认有性能瓶颈后部分页面改为 native

[darlingsingera]

招行 APP 除了几个一级页面和个人中心的页面，其他的业务模块基本全部是 H5 ，包括转账等页面。
直接使用 nextjs 开发，APP 端配合 capacitor.js 调用原生能力，小程序直接内嵌 H5 ，需要原生的个别页面单独开发，例如支付页面，登录页面等。
我司 ToC 的商城，6 年前就这么改造了，那时没有 capacitor.js ，APP 端也是把一级页面之外的所有模块都 H5 化了，体验上很难识别到是 H5 ，但是开发效率翻了几倍。我们那时是 H5+小程序+安卓+IOS 都是全功能对客。
现在 nextjs 进化了 ISR/流式传输等能力，页面在响应上基本都是 0 秒跳转，loading 都没有了

[murmur]

@maxmax4max 原生你考虑纯血鸿蒙吗

[hyqCrystal]

kotlin multiplatform +uniapp

[maxmax4max]

@murmur 原生鸿蒙已经做过一个简版并上线了效益并不好，新的 APP 暂时不打算做了。

[maxmax4max]

@darlingsingera 你这个确实可以考虑，招人不太容易吧，中高级开发才能 hold 住。

[RightHand]

有热更需求选 rn ，没有选 flutter

[faimin]

电商首选 RN ，因为可以热更。比如快手的电商业务基本都是 RN 开发的

[yuntun]

不需要考虑 uniapp

[wjcwukong]

投一票 2

[hugebug]

投 RN 一票 哈哈

[iflint]

kmp cmp

[zoharSoul]

flutter
不用做小程序, 谁用淘宝/京东/拼多多的小程序买东西啊 怕不是抖 m

[zoharSoul]

@sdads12 #15 pdd 核心链路纯原生
并且是优化到极致的那种

[kimixeon]

flutter ，小程序都可以用 flutter 来做.

[chaxus]

@maxmax4max #4 支付宝的理财 tab 里面，还有活动几乎都是。虽然都是 webview 但做了离线包加速，甚至看不到进度条的加载。

[rocmax]

选 rn ，如果需要复杂动画可以用 react native skia 解决

[rocmax]

k 线
https://x.com/ekrembk/status/1782875120739971381?t=NnJqb9a9XePS0ZRqCGK-EA&s=19

[roundgis]

@darlingsingera 招行 app 用了 capacitorjs? 難得

[anjingdexiaocai]

@sdads12 你在想啥呢，pdd 最多活动页用用 h5 ，你记住 h5 性能永远都差原生一大截，因为 h5 的运行时是 webview 浏览器内核

[jones2000]

@rocmax K 线 [https://github.com/jones2000/HQChart]( https://github.com/jones2000/HQChart)

[xiaoshan5733]

根据目前的人员配置，体验和成本综合考虑的话 RN 是最优选

[skallz]

app 用 flutter ，效果还是很不错的，小程序用 uniapp ，这个没得争（其他家小程序还有部分插件都已经有专门的 uniapp 文档你就知道 uniapp 在小程序的市场份额了，虽然坑还是很多）

[BeiChuanAlex]

原生，因为风险最低，跨平台技术甩不了锅

[DeWjjj]

4!

[DeWjjj]

大部分前端都有兼写小程序能力的，主要是 ios 和 android 需要你再找。

[liyafe1997]

5. Jetpack compose (安卓原生，同时支持编译成 iOS App)

[huaweii]

回复的都没注意这个 k 线图表需要深度定制，根据这个以及团队能力还有需求来选型吧。军师们疑似都是纸上谈兵，不过看到整个页面有 200-300 这个，我才发现楼主也是来搞笑的。随便草台班子起一个 mkdir ，骗到钱弄个两三期工程然后跑路的节奏😁

[Geon97]

首先排除 3 完全不用考虑。
方案 2 ，flutter 可以做小程序
方安 4 ，学习成本高，但是体验更好
学习能力强、学习时间充裕就选 4 ，反之就选 flutter 。如果学习成本还是感觉高就选 RN

[jeesk]

@anjingdexiaocai 你把网络关掉看看，首页除了点击商品，其余的都能看到加载网络的报错。

[jchnxu]

@maxmax4max #18 早期除了首页基本全是 webview 。后来第一是离线加载，上市了之后才慢慢原生化。

所以歪个楼，问题变成了，OP 打算什么时候上市

[janus77]

从你们这背景来看我感觉是创业团队而且不舍得请大牛也不会烧大钱，所以我推荐 RN 。因为我个人看法，你这种成功率不高

[issues]

只有原生和 web 或者原生+web 这两种最成熟

[mailworks]

@darlingsingera
"现在 nextjs 进化了 ISR/流式传输等能力，页面在响应上基本都是 0 秒跳转，loading 都没有了"

这个似乎是 next.js 的 SSR 和 SPA 混用吧，加了 SSR 复杂度会增加单论 App 来说还是 SPA 合适简单点（ App 不需要 SEO ），楼下有人说的支付宝 App“模式”，核心功能原生再加离线 H5 包也还行，离线 H5 包也能做成热更新，当然我也没多少实践不一定对

[MindMindMax]

@janus77 路人 认同你的观念。 OP 怎么开发成本最低 怎么来吧。反正上线赚到利润的概率低于 10%

[DLOG]

小弟客户端干了 10 年，略懂 android iOS 鸿蒙和前端
我的建议：iOS 、android 鸿蒙 原生，业务更新频繁的用 Web

[darlingsingera]

@mailworks 使用 ISR ，SEO 不是最主要的，既然用了 nextjs ，也不会作为纯 SPA/离线包来使用，因为离线包无法在小程序内使用，同时也会增大 APP 的更新复杂度。

传统 SPA 使用离线包主要是因为首屏白屏的问题，ISR 后首屏呈现基本不依赖 JS 资源文件下载和接口交互，纯 CDN 加载静态 HTML ，这个速度非常快，加载完毕后才开始水合，大幅降低了白屏的时间。

首屏加载后，用户在界面操作过程中，所有跳转都会提前预取，所以真正点击菜单/链接都会 0 秒延迟跳转，包括目标页面的大部分接口数据也会提前准备好，这里的交互比原生更快，毕竟原生接口请求还是会 loading 转圈。

从技术层面出发，这些特性不需要写多余的代码，因为 nextjs 框架已经帮忙做了，按着它规范去写就能实现，所以带来的额外工作量不大。

对于研发效率，基本就是编码一次，发布一次，全平台自动就更新了，省去了之前多端各开发各的，沟通/管理/招聘/开发/维护成本巨大，各端 BUG 还各不相同，APP/小程序发布还有审核，还要兼容历史版本/接口等问题。

[15757mu]

@DLOG +1

[jayasme]

既然人员都定了那就选目前人员最熟悉的技术栈，先把产品拉起来再说