kbone页面节点1000左右的时候，小程序就会变卡顿吗，即使没有在setData，滑动都感觉不流畅

[JimmyVV]

已经收到哦~~~~

[JuneAndGreen]

一般来说不会，有监听滚动事件并在里面做什么操作么？

[1679236695]

我们有个popup组件，点击之后反应很慢，观察了setData，次数只有三次，数据量也不大，修改的组件的层级也不深，之前是挂载到了body下，现在是挂载到了一个element自定义组件下，但是感觉几乎没有什么优化，还有什么解决办法吗

[JuneAndGreen]

看描述不太明白，看标题说是没有 setData 滚动不流畅，但是实际上是有 setData，从触发点击事件到渲染完成比较慢？

这里滚动与渲染是属于两个不同的问题，具体的问题是指哪一块？

[1679236695]

其实滚动还好，真正卡顿的是点击popup要等待1s甚至更长的时间才能出来，就是触发点击事件到渲染完成比较慢，我在miniprogram-element/base里的callEvent中进行打印，发现是在小程序中进行打印，得过一段时间才能执行到这里，所以感觉时间都消耗在小程序点击-触发事件这个过程，有什么解决办法吗，还是说就到瓶颈了，目前页面上1600个节点，已经无法正常交互了，在八九百节点的时候，点击等待1s左右还能反应

[JuneAndGreen]

其实对于页面节点数量过多且又亟需性能的场景，是更推荐原生开发的：

不过按你描述耗时在 callEvent 也不太对劲，你可以在 miniprogram-element/base 里的这里开始打点看看：

看是小程序点击到触发 onTap 慢，还是开始调 callEvent 到触发 addEventListener('click') 慢？按道理虽然 callEvent 本身会有冒泡/捕获处理，但不至于慢这么多，kbone 的性能瓶颈应该在渲染上。

[1679236695]

嗯，感觉有可能就是渲染时候有问题，因为页面上的滚动事件触发的很及时，没有卡顿，可能是开发者工具的打印的有问题。

[1679236695]

我想kbone有没有可能像taro一样重写react的renderer，因为现在使用react的时候的路径为 react的虚拟dom-kbone模拟的虚拟dom-小程序的dom 如果能重写renderer，可以直接在render里进行setData,将react的虚拟dom转化为小程序的dom，这样会不会相对提高一些性能，

[JuneAndGreen]

我想kbone有没有可能像taro一样重写react的renderer，因为现在使用react的时候的路径为 react的虚拟dom-kbone模拟的虚拟dom-小程序的dom 如果能重写renderer，可以直接在render里进行setData,将react的虚拟dom转化为小程序的dom，这样会不会相对提高一些性能，

理论上当然可以这么做，不过 kbone 一开始的设计就是不耦合任何 Web 框架，只是纯粹提供一个类 jsDom 一样的使用方式（方便接入各种各样的 Web 框架）。如果只是为了优化渲染性能的话，我们通常不会去引入第三方框架再在第三方框架上进行优化，而是直接优化小程序框架本身，比如近期小程序中的组件框架就有升级计划 —— 将 exparser 替换成 glass-easel

[1679236695]

如果我使用这个属性generate.wxCustomComponent 页面上有一半程序原生组件和一半kbone混合渲染，性能会不会比只用kbone大幅度提高

[JuneAndGreen]

如果我使用这个属性generate.wxCustomComponent 页面上有一半程序原生组件和一半kbone混合渲染，性能会不会比只用kbone大幅度提高

是说页面苛求性能那一部分用原生实现，然后作为第三方自定义组件被 kbone 接入么？这种方式确实是一个比较推荐的性能优化渠道，所以是可以这么做的。相关文档

不过需要明确的是单个页面内的自定义组件实例不能太多，不然有可能本末倒置了（不过正常来说一个页面中也不会有太多第三方自定义组件，如果有太多第三方自定义组件的场景其实就不如直接换成整个页面原生实现更优了）