不是有一个 onMessage 的 api 吗？按道理把更新页面的函数扔进去就好了。我写纯 js 也是把页面更新的 callback 放到 ws 的 onMessage 内

1. 还没过第一年，大问题还没爆发。但总体来说还是不错的
2. 散热极限就是 Intel 标准设计，但 14nm 实在是太热了，日常使用都会觉得腕托部分温热的
3. 如果不想用 ARM 或者没完全过度完成不打算使用 ARM 版，还是值得入手的

arm 上跑原生 win 估计可能不大，但虚拟机估计没啥问题。最终体验取决于未来操作系统们对 arm 的支持力度。

我用过联想的 ssd，黑苹果没多久就挂了。但本身硬盘就垃圾，所以硬盘锅更大。

感觉 chrome 在 mac 上显卡支持都很一般，我写的图表页面，chrome 跑起来卡卡的，套 webview 反而很流畅

@bluehtt
看游戏，如果游戏场景需要大量载入素材（开放世界游戏）的很容易掉帧，我玩的游戏像 dota2 或者神谕：原罪 2 毫无压力。rx590 跑原罪 2 最高可以到 4k，5700xt 估计 5k 无压力。

usb 网卡其实在高速传输时候会有包间隔时间会有明显抖动，能走 pcie 都走 pcie 把

@NeoChen
放弃抵抗+1，但个人并不是不爽损耗带来的续航影响，而是可预见要换电池带来的时间成本和环境成本

当年 10 系不也一样吗？ 1060 打 980 毫无压力。

@96412hj
go 有个库就叫 webview，你搜一下就知道了。但我觉得这个做小工具还行，大项目还是不要了，api 极其简陋。因为不同操作系统下对 webview 有各种限制。在 macOS 下连复制粘贴都不行，alert 更是不行。更没有 electron 那样不同进程相互调用，我自己手写 websocket 的 rpc 。v 友写过一个 deskgap，但已经停止开发了。我也考虑给 deskgap+1s，无奈不会 Windows 下的编程。

@zjsxwc
imgui 在高分辨率下很容易糊，非常蛋疼。不过真的非常小。

@shanghai1998
100m 肯定是 electron，不是 webview 套壳，而是把整个浏览器扔进去了。

我用 Webview 包了一个 app，可惜快捷键用不了，但体积小。实时图表更新比 chrome 还要丝滑，这一点非常不解。

@est
历和史是不一样的，lz 的定义是历，你的补充其实是史。其实最好加上前提：后人以官方身份保存下来的记录。这就是为什么古时候会有史官一职。因此明官写元史，清官写明史。非官方记载统称为野史。至于历的真实性，都是要后人重新考究。史观都是某一权威在其推理之后得出结论，无可避免参杂很多主观成分。

理论上具备，实际上不完全具备。

我一直用 moshi 的清洁套装，只能说还行（当时 jd 搜到直接买的）。

@williamfzc
因为我们公司就是习惯工程就是一个文件夹加一堆源码，每次有改动更新依赖和版本就各种问题。最好有类似前端的脚手架自动创建工程。脚手架安装好了，那么工程肯定没有问题。