V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
VDimos
V2EX  ›  程序员

这样的想法可行不?

  •  
  •   VDimos · 2019-08-23 13:17:35 +08:00 via Android · 4979 次点击
    这是一个创建于 1905 天前的主题,其中的信息可能已经有所发展或是发生改变。

    webassembly 的性能现在已经很突出了,按照目前的发展趋势,wasm 的性能会逐渐逼近原生。

    如果用 web canvas 做绘图层,用 wasm 做计算。在 wasm 返回给 web 的 buffer 里只有像素信息,它已经做好了布局之类的。

    这样 canvas 只做绘图,而把计算交给了 wasm。或者说大部分情况下都是用的 canvas,相当于 canvas 成了最基本的组件。

    如果 canvas 再使用 webgl 来绘图,性能会不会更好一点儿?

    这样是不是更容易实现跨平台?

    但我不确定,这样的话性能会如何?各位有没有这方面的研究?一起探讨下

    29 条回复    2019-08-24 17:46:33 +08:00
    kamilic
        1
    kamilic  
       2019-08-23 13:25:08 +08:00
    flutter?
    VDimos
        2
    VDimos  
    OP
       2019-08-23 13:29:42 +08:00 via Android
    @kamilic flutter 原理不了解,不是直接编译两套代码吗?用 wasm 的话可以忽略掉平台差异
    userdhf
        3
    userdhf  
       2019-08-23 13:31:45 +08:00
    想法挺好,是不是以后网页直接贴张设计稿上去,监听点击位置就好了...
    nicoljiang
        4
    nicoljiang  
       2019-08-23 13:31:49 +08:00
    感兴趣,静候大佬作答。
    love
        5
    love  
       2019-08-23 13:54:09 +08:00
    然后不断加功能,再实现一遍 DOM
    VDimos
        6
    VDimos  
    OP
       2019-08-23 13:58:47 +08:00 via Android
    @love 没必要实现 dom 那么复杂的标准,如果只实现基本的功能呢?我记得国外是有全部用 canvas 实现的应用?
    murmur
        7
    murmur  
       2019-08-23 14:00:07 +08:00
    可以,没必要,以前 react 就有 canvas 实现的版本,后面还是用了 react native
    tabris17
        8
    tabris17  
       2019-08-23 14:03:05 +08:00
    即便 canvas 渲染能力出众,wasm 性能贴近原生,但是真的能保证用 canvas 实现一套 ui 组件的性能可以接近原生 html 吗?
    augustheart
        9
    augustheart  
       2019-08-23 14:11:35 +08:00
    估摸了一下,可能要分你最终做的是什么东西吧。不过性能更好这个基本上不可能。
    这东西就好比客户端的 duilib,会省去一些系统组件间的交互,某些方面可能会快一点,但是要综合起来谈性能更好,同样的渲染条件下没可能。
    Cooky
        10
    Cooky  
       2019-08-23 14:17:30 +08:00 via Android
    qt webgl 那个?
    momocraft
        11
    momocraft  
       2019-08-23 14:20:05 +08:00
    字体,排版,样式,每一个都是无底深坑
    loginbygoogle
        12
    loginbygoogle  
       2019-08-23 14:48:40 +08:00 via Android
    不说性能问题,就一个简单的输入框控件就够你折腾
    VDimos
        13
    VDimos  
    OP
       2019-08-23 16:04:31 +08:00 via Android
    @loginbygoogle 主要就是性能允许与否
    VDimos
        14
    VDimos  
    OP
       2019-08-23 16:05:06 +08:00 via Android
    @momocraft 那如果光探讨可行性,可行吗?
    gchxp
        15
    gchxp  
       2019-08-23 16:08:20 +08:00
    重复造了一个 js 游戏引擎?
    momocraft
        16
    momocraft  
       2019-08-23 16:23:38 +08:00
    @VDimos 做来玩随便,有期待不可行
    random0O
        17
    random0O  
       2019-08-23 16:35:05 +08:00 via Android
    accessibility 也是个问题
    VDimos
        18
    VDimos  
    OP
       2019-08-23 16:49:33 +08:00 via Android
    @gchxp 有点儿类似,但和游戏引擎的侧重点不太一样
    sujin190
        19
    sujin190  
       2019-08-23 17:12:14 +08:00
    没多大用吧,用户层缓冲帧率上不去,不直接用 canvas 绘图,你显卡不是毛用没有了
    绘图渲染还是要用 canvas 直接完成,排版倒是可以用 wasm,感觉也比不了浏览器直接的体验更好吧
    MMMMMMMMMMMMMMMM
        20
    MMMMMMMMMMMMMMMM  
       2019-08-23 17:13:02 +08:00
    可以,但是应用场景不会多

    因为现有的 web 无论是常规 site 还是 pwa,大部分瓶颈都不在性能上

    游戏可能用的上,但是人家游戏引擎就是专门做这个的,unity,ureal 貌似现在都能直接发布到 Webassembly 了

    强行 port 过去,重写一遍现有业务,npm 替代品没有的轮子再造一遍,你看大公司们乐意不

    个人自己玩玩倒蛮有意思的
    exip
        21
    exip  
       2019-08-23 17:19:04 +08:00 via Android
    会不会出现把计算密集的实时性又不高的东西直接放到客户这边,类似 js 挖矿,只不过性能更高一点?
    doublleft
        22
    doublleft  
       2019-08-23 17:44:41 +08:00
    @murmur
    @VDimos

    flipboard 之前就是用 canvas 来替代 DOM,现在还能找到一些文章。
    而且 做这个事的第一受益应该不是性能吧
    secondwtq
        23
    secondwtq  
       2019-08-23 21:15:14 +08:00 via iPad   ❤️ 2
    我看 flipboard 那个文章的意思就是他主要是为了性能做的

    这个问题我觉得可以换一个角度看

    根据我的观察,UI 库(指广义的 UI 库,不是前端一亩三分地里面的那几个)按照其绘制界面的方式可以分为两个流派
    一个是用更高(或不同)的抽象包装平台提供的 GUI 相关的 API 和控件,比如 Windows 平台的原生 API 是 Win32,微软就有 MFC、WinForms 等一堆库来做这个包装,Borland 的 VCL 应该也算(没记错的话应该是)。这种做的比较大的,跨平台的我就知道一个 wxWidget。还有 SwiftUI,按照 Apple 的说法( SwiftUI 使用了 UIKit/AppKit )。
    SwiftUI 是属于这一类的,另外 UIKit 和 AppKit 的基本思路一样,但是确实是两套不同的 API,所以如果 SwiftUI 能实现一套代码在不同 Apple 平台上跑(这个我没了解过,我主要对框架设计思路感兴趣),那勉强也算个跨平台吧 ...
    我们把这一种框架称为“老实人框架”

    另一种就是我用平台原生的 API 帮我创建一个窗口,再让平台帮我在窗口里面搞一个 canvas (指代任意图形 API 的 context ),跑一个 event loop,然后就变身渣男把平台给踹飞了。窗口里面的控件则完全由 UI 库自己模拟出来。这种做的比较有名的,远有微软的 WPF ——虽然只能在一个平台上面跑,但是还是自己把 W in32 控件重新做了一遍 ... 然后到死都还有性能问题,近有 Flutter ( Flutter 用的应该是 Skia,Chrome 的 UI 应该也是这么画的,所以 Chrome 也 ...)
    实际上 Qt、GTK、Swing、JavaFX 都是这种方式,几乎所有的游戏也是这种方式( Apple 甚至默认了游戏可以随便折腾不用管他那一套理论)
    我们把这一种框架称为“渣男框架”

    现在我们来证明“老实人框架”和“渣男框架”是可以无限互相嵌套的 ...

    说到平台,这里的平台 API,在 Windows 指的是 Win32 那一套( CreateWindow 之类的),在 Mac/iOS 指的是 Cocoa/CocoaTouch,在 Android 指的是 ... 好吧就是 Android 那个 ... 我也不知道叫什么,可能谷歌起名部需要努把力了
    Linux 不存在(至少是不存在唯一的)平台原生 GUI API,非要说的话 libX11 算一个?好吧这个还是以你用 X 为前提的 ...

    这里有意思的是,如果你把 GTK 看成“ Linux 原生 API ”的话(毕竟 GTK 在其他平台使用的很少),那 GTK 就可以被归类为“老实人框架”了 ... 其实还是有一点区别的,因为这种情况下你就是在直接调原生 API,而没有在用额外的 UI 框架 ... 所以应该说是 gtkmm 属于“老实人框架” ... 不过 anyway,这里的启发是,Cocoa 和 Android 这些框架在 UI 方面的内部实现实际上可能和“渣男框架”区别并不大,只是人为原因(官方钦定硬点)把它放到了“平台原生”这一层里面

    有了上面的思考,现在我们就把 Android API 本身当成一个“第三方 UI 框架”,然后你写了个 Flutter 程序跑在 Android 上面,这就相当于你在一个“渣男框架”里面嵌套了另一个“渣男框架”
    你写了个 React Native 程序跑在 Android 上面,React Native 是创建 native 控件的,因此属于“老实人框架”,这个相当于你在“渣男框架”里面嵌套了一个“老实人框架”

    回到楼主的问题,首先 Web 这个东西可以被认为是一个拙劣的“渣男框架”
    这个和计算机中另外一个规律,“ Greenspun ’ 10th rule ” 是异曲同工的:“任何 C 或 Fortran 程序复杂到一定程度之后,都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是 bug 的、运行速度很慢的 Common Lisp 实现。”
    做过前端应该明白为什么 Web 可以被称为“拙劣的‘渣男框架’” ...

    DOM+CSS 可以被看作是 Web Native API,从这个角度讲,Angular/React/Vue 这些可以被视为建构于 Web 之上的“老实人框架”

    然后你在 Android 上面跑的 React Native 程序里面嵌套了一个 WebView,里面放了一个 React 应用,现在你在:
    一个渣男框架里面 ( Android API )
    嵌套了一个老实人框架 ( React Native )
    里面又嵌套了一个渣男框架 ( Web )
    里面又嵌套了一个老实人框架 ( React )

    有没有一点 “ Java 应用调用栈”( https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png )的意思?

    楼主的意思就是,我能不能在一个“渣男框架”里面再嵌套一个“渣男框架”,理论上显然是可以的,你甚至可以继续嵌套 ...
    至于实际有多大意义,那就是另一个话题了
    janus77
        24
    janus77  
       2019-08-23 21:28:33 +08:00
    你只讨论了 UI 部分
    我们说跨平台,不止包括 UI 部分,还有
    界面交互——输入和输出,随数据动态
    硬件交互——照相 定位 声音 还有各类设备上的独有功能(比如电话短信等)
    如果这些都交给 WAS 来做,那么就是传统的 VM 模式了
    如果这些交给设备本身来做,那就是目前的跨平台模式:在各设备里面嵌入一个处理层(比如手机上的 js 引擎),剩下的交给原生。
    areless
        25
    areless  
       2019-08-23 21:58:51 +08:00
    十多年前一个后端大佬看到我写前端,他说,你完全可以用 JS 生成并控制 DOM,这样更快。我还跟他争论前端讲究的是精简,class 或 id 用单字母就可以,能不使用 JS 就不使用,CSS 要兼容度 IE4.0 800 乘以 600 屏,2G 网络的 WAP 页要适配压缩中转后的一系列手机浏览器。
    agagega
        26
    agagega  
       2019-08-24 09:03:42 +08:00 via iPhone
    Flipboard 这样搞过。
    两年前也看过新闻,理论上 React 这种东西也可以输出到 DOM 以下的浏览器渲染层,不知道有没有下文。
    GzhiYi
        27
    GzhiYi  
       2019-08-24 09:44:32 +08:00 via iPhone
    @areless 单个字母的 id 和 class 认真的吗?
    wsxyeah
        28
    wsxyeah  
       2019-08-24 10:38:39 +08:00 via iPhone
    “用 wasm 做计算”具体是指计算啥?
    starsriver
        29
    starsriver  
       2019-08-24 17:46:33 +08:00 via Android
    现在 js 也可以多线程计算,至于 canvas,我曾经想过这么干,后来放弃了。本来浏览器内核就干了这么一回事,你再浪费资源进行渲染,简直疯了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1893 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 16:26 · PVG 00:26 · LAX 08:26 · JFK 11:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.