字节跳动最终面，面试官抛出一个“Flutter”我居然懵了

由于在业务开发过程中，开发者大部分的时间都专研于一种编程语言，如果想要掌握多端开发能力，则又稍显力不从心，因此大前端的概念应运而生。

大前端概念对于编程开发者来说早已耳熟能详，从我的角度来理解这个概念的话，主要是通过同一套编程代码，经过框架编译转化能够适应于多端平台的前端交互界面。

当然这里只介绍目前应用较广的三个方面，即 iOS、Andorid 和 Web H5，之后可以再延伸到小程序、TV、Watch 等其他智能设备，如下图所示。

多端平台的前端交互界面

**大前端的核心是为了解决多端不一致和人力的问题。**比如在一些交互复杂度不高的应用中，通过这种模式可以更好地节省人力成本，特别是在一些前期快速发展的创业公司，可以使用较少的人力来支撑一些核心业务功能。

跨端技术的发展

=====================================================================

移动端跨平台技术经过了一个漫长的发展史，如下图所示。下面主要介绍下在这个发展过程中跨平台技术有了哪些进步或者做了哪些优化。

跨端技术的发展过程

Ionic/Cordova（Hybrid）

在技术原理上的核心是，将原生的一些能力通过 JSBridge 封装给 Web 来调用，扩充了 Web 应用能力。但是这种方法有两个不足，一是依赖客户端，二是在性能和体验上都非常依赖于 Web 端。因此，整体上的体验不可预知。目前这个技术还经常被应用到，例如，当前 App 内会提供白名单域名和可调用的 JSBridge 方法，由此来增强 H5 与客户端交互能力，从而提升 App 内 H5 的灵活性。

React Native/Weex

在原来的 Hybrid 的 JSBridge 基础上进行改进，将 JavaScript 的界面以及交互转化为 Native 的控件，从而在体验上和原生界面基本一致。但因为是 JIT 模式，因此需要频繁地在 JavaScript 与 Native 之间进行通信，从而会有一定的性能损耗影响，导致体验上与原生会有一些差异。

Flutter

取长补短，结合了之前的一些优点，解决了与 Native 之间通信的问题，同时也有了自渲染模式（框架自身实现了一套 UI 基础框架，与原来的渲染模式基本一致）。从而在体验和性能上相对之前的两种框架表现都较好。

经过上面的技术原理和优缺点对比，Flutter 在各方面都表现出了突出的优势，因此， Flutter 成为入门大前端的核心框架。

为何选择 Flutter 作为大前端核心框架

========================================================================================

大前端这个概念从开始到现在已经有整整 10 年时间，那为什么到现在还没有一统江湖呢？因为多端或者智能设备的发展终究不会停止，也很难做到统一标准。那为什么我们还要选择 Flutter 来作为大前端核心框架呢？

事实上 Flutter 的确能够为我们解决一些场景问题，节省人力成本，同时不影响用户体验。

选择 Flutter 并不是为了代替 iOS 或者 Android，而是做一个技术互补，比如，Flutter 负责业务功能，而 iOS 和 Android 则负责部分的底层交互提供服务给到 Flutter 应用。Flutter 也是在这两年刚刚兴起的，在应用起步初期还需要部分底层的服务与原生平台进行交互。

相信再经过一段时间的发展，**Flutter 在这方面会不断地优化和提升，也将能够独立覆盖到更多复杂的业务场景。**因此希望你能够明白大前端的概念，以及 Flutter 对进击大前端的重要性。

下面我对目前的技术团队和未来技术团队进行一个简单分析，也可以认为是一个预测。如果你觉得有帮助，那么可以往这方面进行一些尝试，如下图所示：

大部分开发者会集中在跨端技术团队中；而另一部分核心技术攻坚则在相应的平台技术端（比如 Android 基础技术团队、iOS 基础技术团队或 Web 基础技术团队），为跨端技术团队提供基础技术服务支撑。当然如果跨端技术团队将组件完善并且可通用化，那么跨端技术团队的人员则可以更快地配置组装的方式构建业务功能。