鸿蒙最佳实践之优先使用@Builder方法代替@Component组件

前言

大家好，我是青蓝逐码组织的君莫笑。
今天给大家分享鸿蒙中最佳实践的知识点，优先使用@Builder代替@Component组件。

为什么我们要用@Builder代替@Component组件？

我们在实际开发中，大多数还是使用@Component来进行组件封装复用，因为其拓展性好，还能直接在内部修改状态变量，并且功能也比@Builder强大，拥有其没有的组件生命周期，那我们为什么还是推荐用@Builder代替@Component组件呢？
这里直接甩出官网的说明

其中的大意说白了就是用@Builder代替@Component组件能够去减少节点树。

因此，在应用开发时，减少自定义组件的使用，尤其是自定义组件在循环中的使用，将成倍减少FrameNode节点树上CustomNode节点数量，有效缩短页面的加载和渲染时长。当在应用中使用自定义组件时，可以优先考虑使用@Builder函数代替自定义组件，@Builder函数不会在后端FrameNode节点树上创建一个新的树节点（抄的官网的）

实验例子

我们通过官网给出的实验结论不难看出@Builder方法确实比@Component组件性能更好

结论

虽然@Builder比@Component组件性能更好，但是我们在实际开发中还是要根据场景来选择对应的方案，毕竟@Builder有着一些限制条件。

限制条件

• @Builder装饰的函数内部，不允许修改参数值，否则框架会抛出运行时错误。开发者可以在调用@Builder的自定义组件里改变其参数。请参考在Builder装饰的函数内部修改入参内容。
• @Builder通过按引用传递的方式传入参数，才会触发动态渲染UI，并且参数只能是一个。请参考按引用传递参数。
• @Builder如果传入的参数是两个或两个以上，不会触发动态渲染UI。请参考Builder存在两个或者两个以上参数。
• @Builder传入的参数中同时包含按值传递和按引用传递两种方式，不会触发动态渲染UI。请参考Builder存在两个或者两个以上参数。
• @Builder的参数必须按照对象字面量的形式，把所需要的属性一一传入，才会触发动态渲染UI。请参考Builder存在两个或者两个以上参数。

总结

因此如果你的数据需要进行状态变量的改变，并且类型不是复杂类型、参数不止一个，那么不建议使用@Builder方法进行复用了。

所以只有在你的数据不需要二次改变的情况下，使用@Builder方法代替@Component组件对性能更好！一些轻量级的封装组件（纯UI，无数据变化）以及不需要修改数据的组件就可以优化为@Builder方法。

最后

以上就是本次分享给大家的一些教学了，如果这个文章对你有帮助，恳请三连。