Flutter为什么把很多属性类的东西做成组件？

flutter为什么把很多属性类的东西做成组件？

哈喽，我是老刘
在Flutter中，布局确实是通过一系列的组件来实现的，如Align、Padding等。
这种设计方式虽然初看可能让人困惑，但实际上它带来了一系列的好处。

从底层看

站在Flutter渲染的三棵树的角度，我们写代码写的各种Widget并不是每一个都真正绘制在屏幕上的。
比如常见的Align、Padding等组件，都是为了调整真正绘制出来的元素的位置、大小等属性。
所以可以理解为Widget树上的很多节点的功能就是为其包裹的子节点提供配置信息的。

从开发者角度看

1. 组件不可变

在传统的平台如Android中，UI组件如Text可以通过setter方法动态修改其内容。
而在Flutter中，组件是不可变的。
这意味着一旦一个组件被创建，它的状态就不能被改变。
取而代之的是，在状态发生变化时，我们需要创建一个新的组件实例。
这种不可变性带来了几个显著的优势：

• 简化状态管理：由于组件不可变，状态管理变得更加直观和容易。开发者只需关注如何根据状态创建新的组件实例，而无需担心组件状态的内部变化。
• 优化性能：还是前面说的三棵树。在Widget树中，每次状态更新都会创建一个新的Widget实例，但在Render树中，如果状态变化不影响布局或绘制，相应的Render对象可以被重用，从而优化性能。

2. 降低API冗余

Flutter的设计哲学之一是减少API的冗余。
通过使用组件来实现布局，Flutter避免了在每个组件的构造函数中提供大量重复的参数。
例如，Padding组件可以被任何需要内边距的组件重用，而不是每个组件都单独实现内边距功能。

3. 降低调试复杂度

当布局问题出现时，如果只有少数组件会影响布局，那么调试和定位问题将会变得更加容易。
在Flutter中，由于布局是通过组件来实现的，开发者可以快速定位到影响布局的组件，并进行调整。

4. 简化心智模型

Flutter通过统一UI层面的API维度，将所有UI元素都视为组件，这大大简化了开发者的心智模型。
一旦熟悉了这种组件化的思维方式，开发者在开发过程中就不需要过多地考虑布局的细节，而是可以专注于组件的组合和交互。
这种简化的心智模型有助于：

• 提高开发速度：开发者可以更快地构建和迭代UI，因为组件化的思维方式让UI构建变得更加直观。
• 促进创新：简化的心智模型让开发者有更多空间去思考如何创新和改进应用的用户体验。

虽然Flutter中使用组件来完成布局的设计带来了前面说的那些优势，但这种设计也确实存在一些潜在的缺点，需要我们在实际应用中加以注意。

这样做的缺点

学习曲线更陡峭

由于Flutter采用了一种全新的组件化设计哲学，对于初学者来说，这可能会使得学习曲线显得较为陡峭。

• 新概念的理解：开发者需要理解组件、Widget、Element、RenderObject等新的概念，以及它们之间的关系和作用。
• 组件化的思维方式：与传统的布局方式相比，组件化的思维方式需要时间去适应和掌握，尤其是在组合多个组件以构建复杂布局时。

过度封装问题

虽然组件化带来了代码复用和简化心智模型的好处，但过度封装有时也会导致问题。

• 灵活性降低：在某些情况下，过度封装的组件可能限制了开发者对布局细节的控制，使得定制化布局变得更加困难。
• 性能考虑：虽然Flutter通过优化三棵树的机制来提升性能，但在某些极端情况下，过度的组件嵌套和重用可能会对性能产生影响。

解决方案

为了应对这些潜在的缺点，我觉得可以采取以下一些措施：

1. 逐步学习和实践：一定要增加学习中的实践环节，这样可以加快适应Flutter的设计哲学，从而降低学习曲线。
2. 深入理解原理：深入理解Flutter的工作原理，包括组件生命周期、渲染机制等，可以帮助开发者更好地掌握组件化的设计方式。
3. 合理使用组件：在实际开发中，合理地使用组件，避免过度封装。
4. 性能优化：对组件的使用和布局进行性能优化，例如通过使用const构造函数创建不可变组件，以及合理地使用ListView.builder等懒加载组件来提高性能等。

总结

总之，使用组件的方式完成布局参数的设定，有其合理性，但同时也会引入一些问题。
这是任何一种框架，任何一种方案选择所必须面对的情况。
对于开发者来说，如何扬长避短就是考验开发者功力的时候了。
如果看到这里的同学有学习Flutter的兴趣，欢迎联系老刘，我们互相学习。
点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》