带你重新“玩转”Flutter _Flutter

带你重新“玩转”FlutterFlutter作为一项已经逐渐进入规模化实践的技术，它的价值已经初步获得认可，后续应该有不错的生命力。作为较早期的Flutter实践者，我一直在思考Flutter的技术价值以及如何释放这些价值，本篇尝试从一个新的视角去结构化的梳理Flutter的技术价值并做对应的应用分析。
这里不会涉及到Flutter具体领域的技术点，但是会结合我们团队过去的探索实践，在技术使用策略的层面做一些总结，希望能帮助到小伙伴们在开发实践中思考提炼，抬头看路，仰望星空，找到未来的创新方向。

前端有些啥问题要溯源Flutter, 就得从前端说起了。这里的前端是相对于后端的概念，大概泛指通过图形界面实现用户交互的终端技术。这个领域一直很有活力，伴随着互联网一路走来，很多新思路和新技术都有点眼花缭乱：上古的MVC已经不大提起了，老一辈的MVP,MVVM也逐渐暗淡，新一辈的Vue,Angular,React方兴未艾，还有Redux, Mobx, Hooks推波助澜。这些技术都像是一个个有感情的小生命，有的热情，有的文艺，有的高冷，十分热闹。也许你会想：它们都在说个啥？它们都想解决一个啥问题？

节点，连接和网络互联网是这一切存在的大背景，互联网有3个大要素：节点，连接和网络拓扑结构。每一个要素的进化都会给前端带来升级和变革：从PC互联网到移动互联网再到物联网是节点在进化；充满想象的5G时代是连接在进化；从中心化到分布式是网络拓扑结构在进化。前端的使命是让用户(人)高效的嵌入到网络之中，让人和设备融合为一个有生命的网络“节点” 。

文章插图
PS：网络模型可以适配到前端的很多场景，里面的“节点”可以代指手机设备，应用程序，进程，页面，甚至组件。

节点与前端技术前端技术是用户(人)与设备的粘合剂，让二者有机的构成一个网络节点。我尝试剖析下前端技术在节点中的形态：首先它需要提供界面给用户，并响应用户的交互；需要管理和远端节点的通信，交换信息；还需要管理当前节点的信息状态；最后，为了方便的嵌入到网络中，节点需要一个友好的“外观”，就是生命周期。生命周期描述了节点的诞生，消亡，所拥有的权益，和所承担的责任。

文章插图
PS：这个分治模型也具有一定的通用性，可以适用在应用程序，页面，或者组件。

前端要解决的问题当然，前端技术作为一种软件技术，在日常的工程开发中也需要基础的构建部署支撑。那么，综合前面的讨论，前端要解决的基础要素问题有：
•远端通信
•界面管理
•生命周期
•状态管理
•构建部署
这里面生命周期管理是一个比较“隐形”的问题，它其实就是构建“外观”描述，也就是“组件化” 。这些基础要素问题的结构关系大概是：

文章插图
这几个基础要素问题的解决往往不能孤立的进行，在设计解决方案的时候需要彼此配合。前端领域的技术方案通常都会合并解决其中的几个问题，比如：React解决界面管理和生命周期；Vue解决了界面管理,状态管理,和生命周期；Redux专注解决状态管理；GraphQL，BFF,Serverless解决远端通信；webpack解决构建部署等等...
那么，Flutter解决了什么问题？或者，Flutter可以解决哪些问题呢？

Flutter都有些啥有趣的技术方案应该有自己旗帜鲜明的个性，做架构设计往往是遇到了独特的问题或者发现了更好的工具。因此，使用Flutter做解决方案的时候，应该梳理下Flutter都带来了些什么。一般来说，主要有Dart语言，Dart运行时(VM)，GUI框架，和相关的开发构建工具。

Dart语言Dart语言不好说有多优秀，总的来说是一门工程“友好”的现代语言。也许感觉平淡无奇，但官方在介绍Flutter的时候，还略有“骄傲”的展示了它的包容性：它能较为原生的支持声明式，过程式，面向对象，函数式，和响应式等业务场景，它给技术方案实现提供了很自由的范式空间，这是值得发掘和尝试的。结合我自己的实践，有几个点值得一说：
•支持类似“协程”处理（async/await/yield）：Dart是单线程的，但是支持异步。这一点需要在使用中去体会，不展开说，理解深了以后，可能对很多问题都有新解法。