在學習Flutter之前，我們先從跨多終端技術發展歷程看看未來大前端的發展趨勢。
隨著網際網路技術的發展，業務平臺對多裝置、多終端的需求越來越多，因此，僅掌握單一平臺程式設計開發能力已經稍顯欠缺。由於在業務開發過程中，開發者大部分的時間都專研於一種程式語言，如果想要掌握多端開發能力，則又稍顯力不從心。因此大前端的概念應運而生，本課時主要介紹大前端的發展歷程，以及如何做好大前端技術的選型分析。
什麼是大前端大前端概念對於程式設計開發者來說早已耳熟能詳，從我的角度來理解這個概念的話，主要是通過同一套程式設計程式碼，經過框架編譯轉化能夠適應於多端平臺的前端互動介面。當然這裡只介紹目前應用較廣的三個方面，即 iOS、Andorid 和 Web H5，之後可以再延伸到小程式、TV、Watch 等其他智慧裝置，如圖 1 所示。
大前端的核心是為了解決多端不一致和人力的問題。比如在一些互動複雜度不高的應用中，通過這種模式可以更好地節省人力成本，特別是在一些前期快速發展的創業公司，可以使用較少的人力來支撐一些核心業務功能。
跨端技術的發展移動端跨平臺技術經過了一個漫長的發展史，如圖 2 所示。下面主要介紹下在這個發展過程中跨平臺技術有了哪些進步或者做了哪些優化。
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 基礎框架，與原來的渲染模式基本一致）。從而在體驗和效能上相對之前的兩種框架表現都較好，具體是如何做到的，我會在接下來的第 22 課時中詳細介紹。經過上面的技術原理和優缺點對比，Flutter 在各方面都表現出了突出的優勢，因此把 Flutter 作為入門大前端的核心框架。
選擇 Flutter 的思考大前端這個概念從開始到現在已經有整整 10 年時間，那為什麼到現在還沒有一統江湖呢？其實從我的角度來看，Flutter 也不會創造一統江湖的成果，因為多端或者智慧裝置的發展終究不會停止，也很難做到統一標準。那為什麼我們還要選擇 Flutter 來作為大前端核心框架呢？
事實上 Flutter 的確能夠為我們解決一些場景問題，節省人力成本，同時不影響使用者體驗。
選擇 Flutter 並不是為了代替 iOS 或者 Android，而是做一個技術互補，比如，Flutter 負責業務功能，而 iOS 和 Android 則負責部分的底層互動提供服務給到 Flutter 應用。Flutter 也是在這兩年剛剛興起的，在應用起步初期還需要部分底層的服務與原生平臺進行互動。相信再經過一段時間的發展，Flutter 在這方面會不斷地優化和提升，也將能夠獨立覆蓋到更多複雜的業務場景。因此希望你能夠明白大前端的概念，以及 Flutter 目前的應用場景。
分析完後，下面對目前的技術團隊和未來技術團隊進行一個簡單分析，也可以認為是一個預測。如果你覺得有幫助，那麼可以往這方面進行一些嘗試，如圖 3 所示。大部分開發者會集中在跨端技術團隊中；而另一部分核心技術攻堅則在相應的平臺技術端（比如 Android 基礎技術團隊、iOS 基礎技術團隊或 Web 基礎技術團隊），為跨端技術團隊提供基礎技術服務支撐。當然如果跨端技術團隊將元件完善並且可通用化，那麼跨端技術團隊的人員則可以更快地配置組裝的方式構建業務功能。
總結本課時首先介紹了大前端的概念以及發展歷程，以及從發展歷程來看我們選擇 Flutter 的原因，其次也分析了未來跨端框架的發展思考，從而得出新的大前端團隊架構體系。相信通過本課時的學習，你對大前端的概念和發展以及未來的前景有一定的認識，並且在看過本課時以後，應該要為大前端的方向上做一定的技術積累和沉澱。
下一課時，我將講解 Flutter 框架中使用的程式語言 Dart，為了方便你更好地理解，我將從 JavaScript 角度來講解。