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

高性能界面需求怎么选前端

  •  
  •   southcat996 · 166 天前 · 4418 次点击
    这是一个创建于 166 天前的主题,其中的信息可能已经有所发展或是发生改变。

    公司有个项目,每秒接收大概 1700 万字节的数据,会分成六个波形图,要求客户端能维持 60 帧,目前公司前端只有 vue,调研了下好像用 vue 没办法做到

    40 条回复    2024-06-13 12:47:46 +08:00
    tool2dx
        1
    tool2dx  
       166 天前
    用 ffmpeg steaming 在服务期实时合成和推送 60 帧画面,用 vue 来显示,应该能做到。
    wu67
        2
    wu67  
       166 天前
    个人看法. 看到什么帧之类的, 看看 canvas 而不是 vue/react
    rabbbit
        3
    rabbbit  
       166 天前   ❤️ 3
    1 在 Vue 里写原生代码看能不能抗住,例如用 canvas 啥的
    2 数据太多了,让后端处理一下在抛给前端
    3 后端画,前端仅负责展示
    4 不行就商量着改需求
    总之商量着来,别到最后像 V2 某贴一样解决方法是:我们放弃了 react ,开除了前端。
    Kalan
        4
    Kalan  
       166 天前
    图像渲染跟 vue 框架没任何关系,数据量大一般策略都是通过时间段这种合并处理,前端图像渲染的方向有 canvas 、webgpu 这种,60 帧问题不大。
    lasuar
        5
    lasuar  
       166 天前
    客户端不是服务器,不要脑补客户端是很好的性能,所以不能实现这么大数据量的实时渲染。需求本身要改变
    b821025551b
        6
    b821025551b  
       166 天前
    这个瓶颈在于这么大数据量的解析而不是绘图吧,可以在后端做些数据修剪,只抛出绘图必要的数据,按横向 1920 像素点计算,不极限压缩的情况下每秒约( 4*4*6*1920*60 ) 5kb 的数据量用于绘图精度就够了。
    tool2dx
        7
    tool2dx  
       166 天前
    @Kalan OP 说的每秒 1700 万字节,相当手机要长期占满 200M 带宽了。

    客户端毕竟不是 PC ,光处理数据流都够呛,别说 60 帧渲染了。
    sagaxu
        8
    sagaxu  
       166 天前
    人类的眼睛和大脑处理得了 17M/s 的数据吗?
    zephyru
        9
    zephyru  
       166 天前
    1700 万字节? 约 16mb ,如果不是局域网的话,这个数据量,几乎不太可能在前端做这种处理...这是要把本来由客户端展示的内容搬到网页上么..
    这和 vue 之类的展示框架其实没啥关系了...不太可能在 dom 上干这种事情...
    绘制一般是 canvas ,webgl ,数据处理如果计算量非常大,可以放在子线程里或者上 wassm
    和后端商量着来吧,非要前端处理看看能不能从数据与图形之间的关系入手吧,简化需要处理的数据和绘制
    lyxxxh2
        10
    lyxxxh2  
       166 天前
    传输:原生 websocket 。
    60fps 的波形图: 自己找插件,伪造些数据,测试插件是否能 60fps 。
    或者 canvas, 不可能 60fps 都画不出来吧。

    至于 vue,这跟 vue 没关系吧。
    1700 万字节等于大约 16.25 兆字节( MB )。(吐槽 能不能用 kb 或者 mb 作为单位)

    服务器带宽也是个问题,可以将数据作为 json 文件,服务器内网上传 oss 。
    发送 oss 路径给前端即可。
    shadowyue
        11
    shadowyue  
       166 天前
    canvas 来绘图,后端把图表数据处理好给你直接用,按这个思路试试
    laobobo
        12
    laobobo  
       166 天前
    #4 +1 ,这玩意应该和框架关系不大,应该是图像渲染方面的,canvas 相对成熟方案较多,WebGPU 出来时间较短,可能差点
    erwin985211
        13
    erwin985211  
       166 天前
    跟框架没一点关系。可以参考无限滚动的实现方式。只渲染用户能看到的部分,就如大家所说的人脑根本处理不了这么多数据。
    gbw1992
        14
    gbw1992  
       166 天前
    一秒 16mb 的数据,感觉压力也没不是很大的说
    先假设用前端来做,自己部署一个 influxdb 试试,用自带的面板 1s 一刷新看看效果
    Leon6868
        15
    Leon6868  
       166 天前   ❤️ 1
    vue 、react 只是来处理 dom 的,你要的渲染和处理这些框架一点都帮不上忙,你应该去了解 canvas 、skia-wasm 这种数据渲染器。而且如此大量的数据根本不可能通过推流推到客户端网页,再在网页端处理。处理思路应该是在服务器端收集数据,解码成简单的波形数据,然后通过 sse 、websocket 实时推送到前端,再在前端展示。
    danbai
        16
    danbai  
       166 天前
    上游戏引擎
    danbai
        17
    danbai  
       166 天前
    @danbai 每秒接收大概 1700 万字节的数据 肯定需要采样重新取数
    ipwx
        18
    ipwx  
       166 天前   ❤️ 10
    少年,1080p 的屏幕,6 张波形图。我们假设一行 3 张,每张波形图一共占据 1920/3 = 640 个像素。

    我们假设一个像素上面能显示一根线,那么 640 个像素你能显示 640 个频率的强度,再多了你显示器都没有那么多像素点。那么 640 个频率,每个频率我们假设 32 位采样,也就是 4 个字节。一张图在一个瞬间需要的数据量等于 640 x 4 = 2560 字节。6 张图也就是 2560 * 6 = 15360 字节,也就是 16K 左右。

    那么 6 张波形图的一帧,可以被显示器分辨率所显示的信息量只有 16K 。如果算 60 帧,那就是 900K 。

    你给的 1700 万字节,约等于 16M 。

    所以哪怕不谈绘图,你这里有效的数据量本来就应该不到每秒 1M 。记得把传输效率先优化一下。
    weixind
        19
    weixind  
       166 天前
    数据处理肯定要放到后端处理的。js 性能顶不住 17M/s 。上 wasm 不太值得。后端这种采样的解决方案应该会有很多。
    渲染的话,600 个波形图算是高性能需求。6 个不算。
    LandCruiser
        20
    LandCruiser  
       166 天前
    你服务端每秒接收多少字节都和前端没关系,需要你每秒给前端推送 60 * 6 张图片而已(最垃圾的解决方案),优化一下就是每秒给前端返回 60 * 6 组点阵数据( x ,y )。
    ipwx
        21
    ipwx  
       166 天前
    okakuyang
        22
    okakuyang  
       166 天前
    ....前端 vue ,但是可以用原生 js 啊,不清楚你波形图要画成什么样子,但是跑个 50 帧应该没问题。
    danbai
        23
    danbai  
       166 天前
    kneo
        24
    kneo  
       166 天前 via Android   ❤️ 1
    一个波形图有必要 60 帧?你眼睛多快啊?难道你们在开发一个反应速度游戏吗?比如某模式模型图出现 10ms 内不按按钮就爆炸?
    ck65
        25
    ck65  
       166 天前   ❤️ 1
    这调研/产品设计粒度也太粗了,咋从 raw data 一步跳到 UI library 去了。。
    xiangyuecn
        26
    xiangyuecn  
       166 天前
    海量数据的基本处事原则:你糊弄我 我糊弄你。没人会去一个数据一个数据去对的 只要不是偏的离谱就行 尤其是这种画图的 有个大概的曲线就成 搞定 打钱
    thtznet
        27
    thtznet  
       166 天前
    说句实话,这个需求偏工业化,在 C#平台里好像不是很难的事情。另外为啥说到前端一定等于 WEB ? C/S Client 也可以是前端啊。
    ajaxgoldfish
        28
    ajaxgoldfish  
       166 天前 via Android
    态势相关的?就是 cesium +echarts ?军工 BS ?如果相关的话这个领导是半瓶子醋
    ajaxgoldfish
        29
    ajaxgoldfish  
       166 天前 via Android
    为什么这么说呢,因为我也曾经也遇到过。主要渲染引擎出来的数据。
    Adelell
        30
    Adelell  
       166 天前 via iPhone
    服务端直接渲染成视频流发给浏览器,浏览器就是个视频播放器。
    lm930129
        31
    lm930129  
       165 天前
    我理解,应该是后端是个物联网系统,每秒收到 1700 万字节的数据,然后这个数据后端要处理成 6 个波形图,然后前端 60 帧的刷新率来刷新拿数据,如果是这样,应该前端压力不大吧,就是用 websocket 每 15 毫秒这样刷新一下数据。我觉得,压力最大的在后端。
    asdjgfr
        32
    asdjgfr  
       165 天前
    我觉得六楼说得对,瓶颈不在渲染上,应该是数据解析的问题,看看有没有 cpu 密集型的任务,比如要转换每条数据里的日期之类的
    hi2hi
        33
    hi2hi  
       165 天前
    楼主应该不是前端;;; vue (包括 react 这些)只是一个开发工具,她是开发人员提升效率的工具,而不是浏览器的性能瓶颈(框架瓶颈确实有,但有优化方案,不在这个讨论范围)。
    1700 万字节只是数据量,单纯在其中进行数据调用,问题不大;;性能瓶颈会卡在数据汇总和数据索引这部分,哪怕你要求渲染到 120 帧,但也只是展示一秒的数据,这里的 60 帧只是视觉上的丝滑(浏览器在这方面并不一定靠谱,想要稳定的渲染:1 )他们说的方案,直接输出视频; 2 )一个好的渲染引擎;
    LLaMA2
        34
    LLaMA2  
       165 天前
    方法总比困难多!!!


    1.客户测能否接受插件?
    2.绘制后的波形图是否由后续交互(点击波形图有其他功能,举例而已)?
    3.波形图的显示和数据生产方是否要尽可能低的延迟,能接受的最大延迟是多少?
    4.客户测使用的设备类型?设备是否能够配合项目保证最低性能线



    如果能接受插件,
    那就将数据接受处理放到插件中计算,
    计算后在本地启动 websocket,然后启动网页连接本地的 websocket 通讯,
    前端真的只是展示!,甚至于 v 友提到的合成视频播放都可以

    数据传输时是否有非必要的数据,能否预处理,能否压缩传输,感觉制约你的是这 17000 万 Byte
    realJamespond
        35
    realJamespond  
       165 天前
    数据量大和前端没关系,数据要后端处理过最后再通过 websocket 发到前端 canvas 展示
    southcat996
        36
    southcat996  
    OP
       165 天前
    @lm930129 是个示波器,目前就是后端给前端的数据就是每秒 1700 万字节,目前选 qt 去做,但是我们这边都不大会 qt
    douxc
        37
    douxc  
       165 天前
    服务端 ffmpeg 推流,前端直接 video 播放视频?直播?
    ipwx
        38
    ipwx  
       164 天前
    @southcat996 你用 C++ 写个服务器把它降采样到合适的码率再推给 Vue 呗。
    kkhaike
        39
    kkhaike  
       164 天前
    vue offscreencanvas + worker 可以做到
    tzxxxx
        40
    tzxxxx  
       164 天前
    后端应该先根据预期的显示尺寸降采样,计算压缩显示结果,再给前端显示,主要的处理在后端
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   931 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 22:19 · PVG 06:19 · LAX 14:19 · JFK 17:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.