Perfomance issue about kbone HOT 9 CLOSED

方便给一下完整可用的小程序代码包，构建完成之后，可以直接跑的就行。这里对 setData 调用有个聚合，我看看是不是和这里有关。

from kbone.

kbone-template-react.zip

Thanks @JuneAndGreen , 我仅仅删除了外层的 node_modules 减少体积，你可以 yarn 之后进行复现

from kbone.

查了下，这个应该是小程序的瓶颈，和框架无关。因为小程序本身没有 window.requestAnimationFrame，所以这里是 setTimeout 模拟的，16 ms 调一次。而小程序本身是双线程的限制，调 setData 到 webview 端会有一定的损耗，在低端机尤其明显，你看到的卡帧就是小程序 webview 端接收到数据有一定延迟，然后做组件树diff和渲染也有一些损耗导致。你可以尝试直接用 setTimeout 来调整时间间隔，看看能否符合预期（其实就是降低帧数的意思）。

如果实在不行的话，得等后续我们支持 wxs 响应事件这个特性再试试了（https://developers.weixin.qq.com/miniprogram/dev/framework/view/interactive-animation.html）。另外这个特性有一定的局限，它直接在 webview 执行，所以无法直接和 appService 端交互的。

from kbone.

谢谢回复

1. debug 性能下降非常明显，在 Android 尤甚
2. 小程序的 trace 好像不支持自定义组件，profile 是个难题，我直接用模拟器的 JavaScriptProfiler 有点效果，但是 trace 不到 app service 层的代码，目前看下来 onChildNodesUpdate 方法是 cpu 热点，主要应该是调用了过多的 setData 导致，还没想好怎么优化，有思路请分享一下，我去试试。

from kbone.

1. 另外我用原生小程序其实没有这个性能问题的
2. 之前requestAnimationFrame 尝试过降低帧数，有效果，但还是降低了体验，还是想看看有没有更根本的办法

from kbone.

原生小程序你是怎么做 requestAnimationFrame 的呢？我之前按照原样的结构和逻辑试了一下原生小程序是同样的效果的（11个anime组件，每隔16ms更新一次 translate）。这里你只是修改 style 的话，setData 数量应该是和原生小程序一样的多的，因为只有一个节点属性变更。

from kbone.

1. 一样使用 setTimeout 来进行模拟，16ms 一帧

from kbone.

方便给下你原生小程序尝试的代码么？我之前模拟看到是有同样的问题的。

from kbone.

暂无其他反馈，先 closed，后有复现可 reopen 或另建 issue。

from kbone.