你这个时间太赶了吧

@miniliuke 好也自渲染,坏也自渲染.
好在不用 JSB 调度多一层,性能确实快一点
坏在没有原生操作体验...如滚动

相当于 12 次抛硬币全是正面 hhhh

@windstyle2 flutter 跨 mac&win 没有 electron 好开发，主要是社区不太够打。

我从黑果换到白果，系统调度更稳定一点。

黑果的系统兼容性比较差，比如关机自动重启，蓝牙连接，usb 识别等，能用，但是不太稳。

内存得 32g 起步，跑虚拟机占用高，16g 不够吃满会很卡。

@lynan 哈哈哈哈 因为效果设置到导航栏了，还会跟随滚动计算背景模糊，我说怎么这么卡😂

@okakuyang flutter ios

@wpzz 是这里吧，filber 并发更新。

// If a render is in progress, and we receive an update from a concurrent event,
// we wait until the current render is over (either finished or interrupted)
// before adding it to the fiber/hook queue. Push to this array so we can
// access the queue, fiber, update, et al later.
const concurrentQueues: Array<any> = [];
let concurrentQueuesIndex = 0;

let concurrentlyUpdatedLanes: Lanes = NoLanes;


而且开发模式下不太准， 源码中有很多地方判断了__DEV__

"
If something is offscreen, we can delay any logic related to it. If data is arriving faster than the frame rate, we can coalesce and batch updates. We can prioritize work coming from user interactions (such as an animation caused by a button click) over less important background work (such as rendering new content just loaded from the network) to avoid dropping frames.

To be clear, we are not taking advantage of this right now. However the freedom to do something like this is why we prefer to have control over scheduling, and why setState() is asynchronous. Conceptually, we think of it as “scheduling an update”.
"

如果某些内容在屏幕外，我们可以延迟与其相关的任何逻辑。如果数据到达速度快于帧速率，我们可以合并并批量更新。

感谢回复，邀请链接 已发送～ 🎉

有任何反馈都可以联系我们的团队邮箱📮～

📮 [email protected] 📮

cc
@Simonxxl
@xieyqxie
@liangguan5
@amrice
@yanghongye
@TuringHero
@JRChuan
@zons