落雨楓
332 posts
提到 web 的流畅，我讲点东西，和 flutter 没关系，和 react 有关系。
早期显示器基本都 60Hz。
所以浏览器提供了一个 API 叫 requestAnimationFrame，跟随屏幕刷新节奏。
所以这就是很多人都知道的 60帧那个事，如果 16.6ms 里没跑完，就会掉帧。
也就是 React 那个知名的发现时间快用完了就先暂停，把主线程还给浏览器，让它去画画，处理用户事件的行为。
今天的高刷显示器变多了，120Hz，144Hz，还有 240 和 360 的显示器（虽然我觉得意义不大了），意味着单个时间切片也变短了。
但 React 并没有继续跟随说把 16.6ms 继续切短，做更多调度，比如算成 8.3ms。而是改成了默认切片时间就是 5ms。
理由是这样的：
5ms 对于 60Hz，在一帧 16.6ms 里可以跑最多 3 个 5ms 的切片。
如果是 120Hz 的 8.3ms，跑 5ms 还有3.3ms 多余的时间，浏览器可以从容地去完成各种绘画和操作。
如果是 240Hz，4.1ms，5ms 稍微超时了一点点，但这时候人眼已经感知不出来了，所以也无所谓。
除非你是个电竞选手。
5ms 是个很好的 sweet spot。
这个细节可以自己去搜索下，官方有提过，也有不少文章讲过。如果你现在打开 #L16" target="_blank" rel="nofollow noopener">github.com/facebook/react… 也可以看到第 16 行的引入，指向了一个 5ms的 flag。
只不过很早以前在 scheduler 里好像是写死的，现在要处理的不只是浏览器，在不同环境编译时，可以更容易的调整这个参数。
——————
上面一大通其实和原 po 说的 flutter 没什么关系，只是今天正好复习到这里，看源码有一些东西发生了变化，就正好巩固下。
web 仍然有很多不如 native 丝滑的地方，w3c 的保守策略，历史欠债等，但一直有无数人在为了它的性能和表现在努力。
有很多地方确实不适合 web 方案，选 native 更合适。但我高度怀疑——可能有的开发者根本就不知道怎么用好 web 方案。
——————
我不是专业的前端开发，可能有不准或错误的地方，那就请大佬们指正。
akazwz@akazwz_
我用 flutter 写了一个简单的 web 应用，体验和原生一样，太强了，那种流畅感，和原生应用没有区别。
中文
日本語
