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

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

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

@WildCat

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

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

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

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

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

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

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

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

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

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

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

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

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

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

想想小程序的价值在哪

我的理解是 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

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

因为 cordova 不火

@LxnChan

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


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

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

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

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

@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 就行。

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

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 管家吗？

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 来支持调用。