最近有一个疑问，跨平台不是一直都有吗，就是 H5 这个呀，为什么还要弄出 Flutter 这些呢

[nnegier]

我并没有用过 Flutter 等跨平台方案，也许正因如此才有此问吧。我们暂时不讨论性能这一块儿吧，我也不知道那些跨平台方案的底层实现。感觉也有可能是因为要和原生系统的 API 进行交互，但这个我觉得也不是太大问题，写一些通用接口就好了。

有一些朋友讲既然有了 h5 ，为什么还要装 app 呢？这个问题其实很好回答，就是因为它不能离线使用，对网络依赖比较大。
而我是想把 h5 写好，放在本地，即打包进 app 的资源文件里，到时候加载使用即可。

[kujio]

.net core 也搞跨平台
kotlin compose 也搞跨平台
python 也有个跨平台 kivy

[woxihejinghao]

跨平台方案，痛点在于性能和统一性。
H5 的方案第一个是性能问题，RN 这类的话，性能好一点但是依然有点问题，并且 UI 统一性也不怎么样子。
Flutter 其实也是一个 UI 框架，但是你所看到的东西全部是自己绘制的，对性能和统一性的处理都不错，再加上谷歌的加持所以热度上来了。

[sam384sp4]

恭喜楼主发现了盲点， 为什么 h5 能做的还要用户装 app

[kop1989smurf]

确切来讲，flutter 不叫真正意义上的“跨平台应用”。而是一次开发，多平台输出。更贴切的说法应该是“跨平台开发”。
也就是你用 flutter 写的程序，它可以给你对应生成一个等效的 Android 的客户端程序，以及等效的 iOS 程序。

所以他并不是编译结果“跨平台”，而是可以输出多个结果。

客户端做 js 桥 api + webview + h5 做出来的才叫“跨平台应用”。因为他是一套程序，多个平台（ Android 、iOS 、浏览器）公用。

[kop1989smurf]

也就是说，flutter 生成的 Android 和 iOS 程序，从理论上与原生程序的能力，性能相同。（为了两个平台展示完全相同的内容，iOS 和 Android 有对应的 UI 库）

[lianxiben]

h5 还是有功能上的局限性的，需要 jsbridge 才能完成 APP 的一些操作之类。

[theusername]

我理解跨平台通常说的都是跨操作系统，但是本身就有一个跨操作系统的平台叫做浏览器，后来人们不想受限于浏览器的生态或者性能，或者单纯为了兴趣，或者为了抛弃历史问题轻装上阵，所以搞出了其他的技术。

[hwdef]

用 h5 最多的系统应该是 chrome 了吧，，，除了低价占美国的教育市场，其他领域好像都没有成功过。
还有 electron ，除了微软能调教好，，还没见第二个能把程序大小和运行速度调教好的

[marcong95]

H5 只是个网页，啥平台都没跨。

与之相关的，可以与系统 API 交互的，Electron 在本站被喷得体无完肤，uni-app 其实也在被喷之列，虽然应该主要是开发者喷的。所以只能继续造轮子了

[unco020511]

那么既然已经有浏览器这个天然跨平台的组件,所以公司动用 web 网页就行了,为啥还需要开发 app 呢

[statumer]

App 有很大权限，是浏览器比不了的，所以要开发 App
现代的 GUI 框架的架构和浏览器都很相似，样式表+节点树+脚本，控件能自绘的都会自绘。(比如 Flutter ，微软的 XAML ，Qt)
某个屑移动操作系统不允许在应用里内嵌 Chromium ，所以移动 UI 框架会尝试另辟蹊径再造一个“浏览器”出来。

[xiaoyangsa]

我有个想法。
各类系统无统一的对外接口，
要是各家系统都能对外统一出套 js 能调用的系统。规范化。那跨平台也就是网页的事情了。
现在出的快应用，小程序，都是原生往上封装一层来统一调用。始终是差点意思。

互联网不互联

[nnegier]

@sam384sp4 当然是因为不能离线使用呀，装应用才能离线呀！！！

[ciki]

你考虑下为什么出现小程序这种东西，为什么不用 H5

[DOLLOR]

@xiaoyangsa

PWA：好像有谁在叫我🐶

[caqiko]

引申一下，常用移动端 App 的哪些是难以通过 H5 去做的？

个人理解的：
- 依赖稳定推送的：比如 IM 、打车 App （司机和乘客发消息）
- 在客户端做风控的：比如各个银行 App 、支付宝（这个不是很确定 H5 能不能做）
- 在客户端保存 /缓存大量资源的：读书类、音乐 /视频播放器类
- 业务逻辑复杂的：电商类（尤其是淘宝）
- 依赖特殊 /私有协议的

欢迎补充。

[nnegier]

@ciki 生态吧，要进入那个生态，不得不吧

[ciki]

@nnegier 不管说了多少种原因，核心原因只有一个，性能，催生出小程序最直接的原因就是解决 H5 性能问题，生态都是后面才形成。

[LxnChan]

您要找的是不是 — uni-app

[kop1989smurf]

至于说楼主的 append 。

我也不太理解为何之前东京奥运会都吹一个跑百米的苏 xx 。
我们暂时不讨论短跑这一块儿吧，毕竟我也不跑短跑。

其他的我觉得我吊打他，IT 技术我碾压他，身高比他高，体重比他重。
我能理解的，就是他百米距离内移动速度快。
实在不行，你移动百米距离你骑自行车啊。不会骑自行车，滴滴 app 也不会用？

所以实在不理解吹苏 xx 是个什么心态。

[masterclock]

H5 可以搞 UDP TCP IP mdns arp ethernet usb hid pulseaudio alsa etc 了？

[janxin]

说的好，Html5 能实现的为什么还需要 App

[agagega]

@WildCat

[LxnChan]

@caqiko
1.推送可以直接做在后端上，前端 App 反正也是一个壳（浏览器）里面是 H5 ，那在壳上加个推送接收的 SDK 和其他原生应用加推送基本上是一样的。
2.银行 App 完全就是一群懒狗懒得做罢了；另外支付宝是有网页端支付的。
3.在客户端保存缓存大量资源的这种需求早在 Chrome 65 左右就解决的差不多了，基本上是能够做到自净的。网易云音乐和 QQ 音乐都有网页端。
4.电商类 App 我不太了解，但是我觉得电商类用原生客户端的原因应该是能够提高用户粘性和方便做风控（防止刷单和支付风控）。

※写完了才发现说的不是渲染 H5 的客户端，那有几条要改一下：
1.推送可以直接做在移动设备的操作系统里，然后在后端实现直接推送到手机上。这个目前就我在用的小米来说是实现了但没完全实现，现在的逻辑是检测用户是否有某 App ，然后设定 interval 请求服务器查看是否有推送，App 运营通过在小米后台的 API 推送给用户，在这个期间用户无需调起 App 。那用一样的逻辑检测用户是否访问某网站也是一样的（这个有很多的安全相关问题，但大体的逻辑应该是这样的）。
2.银行的很多业务也可以通过 H5 完成。

[libook]

Flutter 算是 Google 的一个产品，目的除了解决自身 App 开发需求以外，还希望在 App 开发领域（互联网行业的上游供应链）占据一定的话语权，把开发者笼络过来了，想推自己的什么业务都很容易了。

跨平台算是一个吸引开发者的特性，一方面写一套就可以方便生成多个平台的应用，另一方面也可以去抢其他平台（如苹果）的开发者。

顺便想推推 Fuchsia ，以及推广 Dart 早日甩掉 Oracle 的纠缠。

不光是 Google ，顶级科技企业都有这样的思路。

不过目前 Flutter 方案的市场份额并不高，其他方案像 RN 和 JS Bridge 就是基于 Web 的，也有不少开发者在用，所以实际上跨平台大家确实在用 H5 的。为了跟本来就比较方便灵活的 Web 方案竞争，Flutter 主要是依靠性能优势来宣传的。

那么为啥会瞄准 App 这个领域，现阶段 Web 技术其实能做的事情比大多数人了解的要多，但 App 产品已经具备了成熟的产业链，以应用商店为核心，从开发、宣传推广、内购、售后一条龙都有配套，对于开发者来说很多事情只需要砸钱给应用商店就行了，对于应用商店来说也能从广告和内购实实在在盈利。

[nnegier]

@kop1989smurf 你好，对于 H5 性能问题，我个人感觉没有那么严重，尤其在今天。我认为不都是解析渲染，然后调用相关图形界面的 API 绘制到屏幕上吗。

[retrocode]

我的理解是 H5 和 flutter 的跨端方式并不相同, H5 的底层是 webview, 即最起码的目标平台能跑 webview

[kop1989smurf]

@nnegier #26 你这个结论有几个假设。

1 、有完善的 JS 桥或者说 JavascriptInterface 。
2 、客户端设备需要完美支持你预想的 web 引擎。这样才不会导致设备之间的偏差，甚至是不能运行。
3 、你使用的业务，性能不敏感。
4 、你可以承担 api 泄漏等风险。

[acehowxx]

其实 h5 都能做。现在还有 web assembly, 都能在前端 h5 实现。app 本来就可以不建，但中国不行，啥都得逼你装个 app ，毕竟 h5 是无状态协议，哪有 app 开一堆权限获得你个人信息方便统计融资。

h5 的唯一问题就是体验差点，毕竟原生开发直接调 sdk 那体验还是比网页渲染是要强不少的。flutter 算是谷歌的跨平台前端解决方案，比 h5 强点，比原生差点这么个定位。

[Jooooooooo]

想想小程序的价值在哪

[retrocode]

我的理解是 H5 和 flutter 的跨端方式并不相同,
H5 的底层是 webview, 即最起码的目标平台能跑 webview, 然后以此为基础补齐或统一多平台 api, 一个潜在的问题是, 由于应用依托与第三方 webview,并且 webview 还有兼容问题和性能问题
像 RN 的解决方法就是, 山不向我来, 我主动向山去, 放弃 webview 主动去单独适配各平台原生的组件, 这更进一步修复了之前的问题, 但是并没有完全解决, RN 的路子决定了, 开发者不能随意升级, 或者需要一直跟着升级, 因为目标平台的组件更新了 RN 必须跟着更新, 否则就会出问题

flutter 就吊了, 它直接喊一嗓子'适配 nm!兼容 nm!老子全部自己来', 然后对着目标平台的设计稿把所有组件全部重新做一遍, 形似但完全不是一个东西了, 现在剩下的没有兼容问题了, flutter 唯一需要考虑的就是, 后面目标平台的设计语言更新了, 他要不要跟着更新,或者直接按自己的路子更新组件

因为你说你没接触过 flutter, 我简化下上面说的:

**以 flutter 的 h5 输出为例,他的所有组件,我是说所有组件都是重新实现,拿 canvas 画出来的,你明白我意思吧,flutter 直接舍弃了目标平台的所有组件,然后自己重头来了一遍,完全解决了多端一致性的问题**

我找了个 flutter 组件库的 web 端 demo, 你可以感受下
https://bruno.ke.com/online_demo/index.html

[angrylid]

Web 这套技术历史包袱太沉重了，性能很难调优，于是 Flutter 另立门户...

[wangtian2020]

因为 cordova 不火

[caqiko]

@LxnChan

我认为这些 App 难以通过 H5 去做，是考虑完全在手机浏览器内运行。你说的有几点还是需要依赖于一个定制的运行时环境？有点类似小程序的环境了，通过这个环境再和系统 API 进行对接通信。


1. 你补充中的第 1 条的推送这个我不太理解是怎么实现的，可以再讲讲吗？我的想象场景是在手机浏览器打开一个 H5 微信（假如有），然后关掉了这个网页，在浏览器内还能收到推送吗？
2. 刚才通过网易云的 wap 版听了几首歌，简单的听歌体验还不错。如果听了很久，缓存好几个 G 呢？过段时间再次播放是否需要重新通过网络加载？在加上其他的视频网站，整体的缓存数据量会比较大，会不会影响整体的性能？
3. 银行 App/支付宝我认为比较难，在于人脸识别和指纹支付这块。另外，有一些银行 App 不能安装在 root 后的手机上，可能是要检测使用环境，通过 H5 运行在浏览器中难以对系统的安全性进行检测。

想象一下，在 Edge for Android 里打开微信 H5 ，bilibili H5 ，高德导航 H5 ，支付宝 H5 ，还可以随意切换、关掉页面，下次打开还能继续用。 🤣🤣

[WebKit]

H5 并没有跨平台啊，它跨什么了？它不是一直是运行在 webview 容器里吗？

[zhangleshiye]

就跟 type-c 接口一样，大家都知道统一了就好。可是为啥苹果不统一？天下熙熙，皆为利来；天下攘攘，皆为利往。

[LxnChan]

@caqiko
1.小米推送： https://dev.mi.com/console/doc/detail?pId=863 ； Web 推送： https://zhuanlan.zhihu.com/p/269036804 。
2.缓存好几个 G 一般是会留存在浏览器数据里面的吧，这个是网站决定的缓存保留时长；另外即使说会删除缓存，网易云的 App 端也有缓存限制啊（一般是 1G ，超出自动清理），影响整体性能我觉得应该不会。
3.生物特征识别这个就别想了，使用官方 API 暂时不可能（但是可以通过第三方软件以驱动或控件的形式加载到浏览器上，这个就不说了）； root 主要是防止抓包和改程序，一般来说可以从两端强制校验根证书躲过抓包，这么看其实还是 H5 更安全；检测使用环境的话 Web 里面检测 UA 就行了，如果说 UA 可以随便改，那 Xposed 或 Magisk 也能改设备信息，甚至直接改 build.prop 就行。

[ytll21]

H5 永远不可能有 APP 的性能，以及人机交互的便捷优势。道理很简单，苹果、谷歌每年那么多的收入都是来自于自家的应用市场，他们会放开这部分利益给到 H5 吗？不会，就这么简单。

[findex]

h5 和 flutter 完全是不一样的东西。当年 Facebook 狂推 h5 最后歇菜。现在还是不死心。
flutter 底层使用的是 skia 绘图引擎，相当于用 dart 代码调用底层绘图，这个和 android 开发是一样的。skia 是 cpp 写的，跨平台。所以可以放在任何平台下使用。
为了跨平台，我用过 phonegap 、cordava 、html5 、electron ，这条弯路真的不想再走了。这是一种让前端人员去写 webview 做 app 的方式，牺牲性能与功能。还用过 kivy 不能做产品。qt 挺好的，但是学习曲线高，二次开发别人难接手。flutter 更像是一种明星，从底层很好的解决了这些问题。flutter 现在是谷歌独裁，所有的功能，补丁修改，引擎优化都必须要谷歌员工身份才行。其他人顶多能提交个 issue ，左右不了 flutter 未来的发展。就像是谷歌用浏览器 chrome 一样独裁着整个互联网的发展方向。
flutter 的核心是绘图，底层 API 基本都可以获取到。自成一套体系。
h5 就是 webview ，底层 API 也可以调用，思路不一样但是都可用。
举个例子，如果你需要做个系统优化 app ，难道你要用 h5 做 xx 管家吗？

[icyalala]

Flutter 准确来讲是 "跨平台 UI"，它完全重写了渲染引擎，这样能保证在所有平台上达到完全像素一致，这才是它区别于别的跨平台方案的特性。从这个思路来看 Flutter 更接近 QT 。

Web 容器或者 RN ，性能问题是一方面，不用多说，无法提供平台一致性的渲染则是另一个大问题。如果你用 Web 技术栈，就需要考虑不同平台下 Web 容器的碎片化、兼容性，比如 iOS 是 WebKit 、Android 是 Chrome 或者类似 X5 那种定制化的引擎、不同版本，你做不到或者很难做到像素准确。如果想要减轻碎片化，那就需要内置容器，这就是 Electron 的思路，结果大家也都看到了，"太大太重"。Flutter 最初的出发点，是 Chrome 团队 Eric Seidel 的一次实验：他在不考虑 Web 兼容性的情况下，对 Chrome 的渲染引擎不断大量删除兼容代码和少用的功能，最终得到 20 倍的性能提升，这就是后来创建 Flutter 的动机。

如果说对于调用 Native 的功能，相比 Web + JSBridge 、或者小程序、RN 等方案来说，并没有本质区别，Flutter 也需要针对不同平台去封装 channel 来支持调用。

[jones2000]

跨平台说白了就是省开发成本，减少公司试错成本， 本来投 100W 启动的项目，现在投 10W 就能有个东西出来了，如果东西卖的好，可以融到钱了，就可以招人重新做原生的性能更好的， 如果不好就不砍掉。

[dcsuibian]

在我看来，Flutter 的最大优势就是他完全“推倒重来”了。
我极其喜欢跨平台的应用，但 H5 这套历史包袱实在太大太大了，光一个 javascript 的历史包袱就足以吊打其它语言了，性能差、体验差。最主要是我始终不喜欢这种“文档”做 UI 的方式，越写越觉得不舒服，总感觉像在屎山上糊屎。

哪怕我学的所有 js 、css 、html 知识都白费了也没关系，真心希望 Flutter 流行起来。

[dcsuibian]

在目前的跨平台 UI 中，我感觉 Flutter 应该会是比较靠谱的那个。
1 、QT 没接触过不好说
2 、MAUI 建议看 /t/835134 。微软的技术除了 windows 真的都是劣等公民。
3 、React Native 没用过。但个人属实不看好。

RN 和 Flutter 貌似对比的比较多，我不明白底层的渲染技术，在我看起来就像是 Java 的 AWT 和 Swing 。
AWT 因为跨平台，所以只能使用各个平台组件的交集。Swing 则是干脆把系统提供的 UI 提供一个画板，自己在上面画组件。虽然后者肯定有一点性能损失，但跨平台统一性和组件自由度都更好。
所以个人还是比较偏向于 Flutter 。（当然如果能每个平台做一套，那肯定还是原生）

[zqlcrow]

因为痛点就是性能啊。
不考虑能飞，飞机有什么用？


估计还有一些人会说，考虑性能，用原生啊。
这是极端论了。一切的一切，都是在尽量寻找可接受的解。

[AloneHero]

H5(PWA)现在已经可以离线使用了，也可以隐藏浏览器地址栏，推送消息，后台下载，连接 USB 等等，功能很强大，也是 Google(移动端)和 Microsoft(PC 端)在力推的技术。可以说除了和本地系统的交互相关的功能，比如设置闹钟设置屏幕亮度这种，其他的网络浏览，在线购物，IM ，在线编辑，在线 PS 等等功能都是完全没问题的。最重要的还是体验，也就是性能。H5 的体验要想做到比肩原生太难，H5 的接口加载，页面转场都比原生慢太多

[a62527776a]

Flutter 真是当下混合应用最优解了 AOT 保证性能 Skia 保证 UI 一致 Channel 保证原生交互

我们公司 Flutter 做过一个项目 从性能上真是接近至少 90% 但是人力却只需要原先的 60%

PWA 就靠边边吧 根本就是面向未来的技术

[lawler]

看来你不知道，flutter 也可以生成 H5 。

[rbq123456]

@nnegier 可是，h5 可以做成离线使用的呀…

[1000copy]

技术是实现工具，可以回答怎么做的问题。

既然问到的不是怎么做，而是为什么做，就需要回答商业价值了。

老大不会做跨平台，因为没有动力。老二才会做，老二也不得不做。老大肯定只有一个，老二可能很多。

就像微软当年最红的时候，是不会考虑跨平台的。现在，给 iOS 做应用开发商也乐意，何况是跨平台。

[devHang]

UI 一致性，性能贴近原生，这就是优势了。做了快 3 年 flutter 了，坑不少。但确实解决了很多 webview 的性能问题，而且现在前端 app 开发人员最少可以节省一个开发人员的工作量。

[devHang]

虽然新版本支持了 web ，但噱头大于实用，如果真的可以生产。那景象真的有点大一统的赶脚

[Dragonphy]

看看 uniapp 就知道了，H5 完全可用，按需求接入原生 SDK 就行

[littlefishcc]

H5 渲染和 flutter 逻辑不都是自己画界面，屏蔽跨平台，给上层提供统一接口，有什么区别。。。
只是应用场景不一样，效果不一样而已。感觉这个离线没有关系，electron 我们开发桌面时候，如果不需要网络不一样可以离线使用。
如果当 H5 渲染速度最够快，能够解决足够多的场景，那么其他跨平台方案也没有必要，目前就是无法达到，才需要别的跨平台方案来满足不同的场景

[nothingistrue]

H5 ，原本它该代表的 HTML5 ，这个标准仍然是 HTML——超文本传输语言的范畴，它主要面向的是“资源浏览”，不是 UI ，不是客户端。即使是 HTML5+（ ES6+），即常规意义上的 H5 开发，它的核心仍然是资源浏览。再加一个 PWA ，勉强才具备资源浏览外的一些客户端的东西，但至少目前来说还不够。

与其说 H5 是跨平台，不如说 H 是无平台的，因为它的核心是服务器，浏览器端是完全从属于服务器，没有自主能力的。所以如果要搞些单独靠服务器做不了的功能，比如搜集数据（隐私），P2P 传输给服务器分压等，那就得整客户端（ PC 客户端或者手机 APP ）。要搞跨平台，就得用其他技术。

[0x2CA]

其实啊，为什么明明网页能做，一定要搞个客户端，这个大多数属于非技术问题，主要是客户端你可以干更多的事情，比如弹窗，比如通知，比如驻留用户机器干其他事情

[standin000]

@ciki 小程序为什么能提高性能？