2020，有个渲染梦

如题，俺又开始做梦了……大家都知道我写了个前端框架叫 fre，还把 fre 轻松地跑在 worker 和 jscore 中，还搞了双线程的小程序引擎……

曾经有一次面试支付宝，面试官问我，为什么你对小程序这么有执念，我告诉她，因为这是我计划中的一环

在单线程的环境中，我搞了 fre 和 fiber，然后我搞了双线程的小程序引擎，猜猜下一个是啥？

那肯定是三线程的渲染引擎啦

讲道理，对着这张图，我一直在思考……毕竟这图上是真的什么都没有

首先，js 层，也就是 js 引擎和前端框架，我到底用不用 fre 呢？

fre 是一个超级赞的框架，它只有 400 行，，却有着高度的抽象，所以用来做渲染实在是非常合适

但，我，不想这样

因为 fre 其实是一个针对浏览器做了高度优化的框架，fiber 也是在浏览器这种特定场景下应运而生的

我不是很喜欢浏览器的调度策略，也不乐意复现它

那么问题来了，fiber 真的不要了吗？异步渲染真的不要了吗？

当然要

我们只是在 js thread 不做 fiber 了，但是我们到 shadow thread 还是要实现一套调度呀

要么实现 event loop，要么实现 fiber

也就是说，渲染器原生支持 fiber，不再需要前端框架去搞了

这听起来很不可思议不是吗？

flutter 的 widgets tree，RN 的 shadow tree，反正只要涉及到 UI，大家统统都是树树树

殊不知，但凡可以用树描述的东西，都可以转换为链表

所以在这一层，我准备用链表去描述 UI，因为本来嘛，好不容易夺回调度权，那么肯定要将很多东西拿到这一层

有了链表，做异步渲染就很轻松了……

这也是我敢写出来的原因，因为实际上国内做渲染的人很多，他们都只追求性能和功能，从来没人考虑过这种最底层的数据结构的东西

但偏偏是这种最底层的东西，才是最重要的，因为无论是啥，一旦成型，很难撼动

然后就是主线程了

其实现在有两个比较合适的方案，一个是 skia 的方案，也就是 canvas

一个是 dom 方案，也就是实现一组命令式的 api，实现类似 dom 的标准

这个我也研究了许久，我甚至还企图使用 rust 画 UI，然后失败了

当然这两种方案其实都可行，我更倾向于前者

最近 esbuild 的案列大家也感受到了，语言的天赋真的很不一般！

所以这个项目我准备使用多种语言，js，c，rust

js 负责 js 层的 runtime 框架，c 负责底层库，rust 负责将它们组合起来

总结

综上所述，说了一堆语无伦次的话，其实重点就是，我要搞个三线程的渲染引擎，重点在 shadow thread，要用链表去描述视图，要走 fiber 的调度思路，要……

说白了就是实现一个完全不一样的浏览器调度机制