作者 | 曹陽(染陌)
跨端一直都是一個前端開發者繞不開的話題，無論是基于研發效率的考量還是從業務場景的需求出發，跨端都是一個“剛需”。從最早的 PC 時代到移動時代，從移動時代到 IOT 時代，不斷地湧現各種端，除了最常見的智能手機，它可能是小到一塊智能手表，也可以是大到一個大屏終端 IOT 裝置。而層出不窮的跨端技術，也為我們跨端方案提供了更多的選擇。
那麼我們究竟要跨哪些端？
- PC 端與移動端：從最早期的 PC 時代過度到移動時代，開發者希望通過一套代碼同時在 PC 跟移動兩端複用，于是産生了響應式等技術，使業務在 PC 發展的同時，也完成了在移動端的布局，保證業務不會在移動時代落後。
- Native 與 Web：最常見的兩種智能手機的作業系統 Android 與 iOS，Android 應用是用 JAVA 編碼的，而 iOS 使用 oc 或者 Swift 編碼的。同樣，基于降級政策以及外放的考慮，我們也希望一套代碼可以同時運作在 Web 上，而 Web 則是使用 JavaScript 編碼的。天然的差異需要我們在端上适配時提供多套不同的代碼實作，這使得研發周期加長，研發工作量劇增。
- IOT 裝置：随着進入萬物互聯的時代，越來越多的 IOT 裝置湧現在我們的生活中，随處可見的大大小小的帶屏終端裝置，都是新的“端”，譬如智能家具、可穿戴裝置以及車載裝置等等。跨端早就不隻是 Android 跟 iOS 的事情了，各種各樣的裝置終端帶來的新的挑戰。
- 小程式、輕應用：各種标準以及 DSL 誕生了新的“端”。
- APP：各種 APP 之間互相投放。
- and more......
跨端技術的演進
本着對研發效率以及使用者體驗的極緻追求，跨端技術也随着曆史的浪潮不斷地發展。從最早的 H5 方案到 Hybrid 方案，以及後來的 Weex/React Native 方案，到現在如火如荼的 Flutter。
每個方案的演進都是為了解決當下方案的一些已知問題，但需要考量的因素都逃不過這些方面——渲染一緻性、性能、體驗、研發效率。我們并不希望需要去為不同的作業系統分别開發兩份不同的 UI，期望可以通過一份代碼使他們的渲染結果完全一緻。同時，我們希望可以直接使用強大的生态去支撐我們的開發，擁抱标準，使得每次更新方案不需要對現有代碼或者方案做一次大規模的重構。同樣，性能與體驗，也是端上繞不開的話題，這直接影響到我們的使用者體驗。
那麼，下面來介紹一下跨端技術演進的幾個重要階段。
Web 以及 Hybrid APP
其實大家熟悉的 Web 就是最成功的跨平台方案之一，它與生俱來的跨平台能力、開放的标準以及強大的生态使它成為赤手可熱的容器之一。
但是 Web 本身還是存在一些問題：
- 記憶體消耗大、GPU 使用率低、長清單滾動等，這使得它在移動端的表現并不盡人意。
- 由于各個浏覽器廠商實作标準的疊代節奏慢，相容性差，往往我們無法在 Web 上使用一些較新的能力，這使得我們的業務開發非常受限。
- 性能差，盡管網絡以及硬體的發展給了性能足夠多的紅利，但是日益複雜的業務總能把已有的性能吃透。
- 由于 Web 需要向前相容，有着非常重的曆史包袱，一些古老的或者低性能的 CSS 可能會導緻相當複雜的布局計算邏輯，消耗大量的時間。
于是在 Web 之上，衍生出一系列增強 Web 能力的方案：
- Hybrid App：依賴原生容器提供給 Web 更多的能力，包括 prefetch、離線化等。
- PWA：提供了離線緩存、系統通知等能力，但是目前在國内發展不容樂觀。
- PHA：使用 Hybrid 的手段讓 Web 的體驗更加趨向 Native。
但是 Web 的方案還是存在性能問題，但是原生開發我們需要适配多端開發多端代碼，于是我們需要尋求一個性能與研發效率的平衡點，于是産生了 Weex 以及 React Native 等方案。
Weex/React Native
Weex 等方案通過 DSL 與 W3C 标準的子集向上結合了前端開發的生态，使我們熟悉的任何前端相關的工具都可以直接使用，保證了研發效率。而向下則是調用了系統自帶的原生空間，使用原生渲染保證了性能與體驗。
用前端代碼開發原生 UI，這是一個非常美好的願景，但是事與願違，實際上還是存在一些問題。Weex 方案并沒有抹平多端的差異，而是把差異的問題放在了容器側去解決。由于底層直接調用了原生元件，而原生元件本身就存在一些限制，有限的能力不能滿足開發者所有的需求，是以在實作 W3C 标準時有些牽強，會有一些在多端表現不一緻的行為，沒法保證完全的多端一緻性。
Flutter
Flutter 可以說是這兩年跨端方案的新寵，它既不使用原生元件，也不依賴 WebView，而是通過自己的高性能渲染引擎直接調用底層的 Skia 進行自繪渲染，保證了多端的渲染一緻性。
Flutter 使用 Dart 語言進行開發，Dart 既支援 AOT 也支援 JIT，在開發時可以使用 JIT，這使得我們可以直接使用 HMR，保證良好的開發體驗。但是在運作時它是在 AOT 模式下的，這也使得它在運作時會有更佳的運作效率。
但是對于前端開發者來說， Widget 這種基于狀态驅動的開發模式已經是非常熟悉，同時學習一門 Dart 語言的成本也不算高。但是對于已有前端生态與基建等的替換成本卻是無法接受的，同時，它本身不支援動态化在複雜多變快速疊代的業務中并不能很好的勝任。是以在 Flutter 的基礎上，也出現了非常多與 Web 結合的方案的探索，比如說 Kraken、WFlutter 等。通過對接 W3C 标準，保證上層直接使用 Web生态，底層使用 Flutter 的自繪渲染保證多端的渲染一緻性。
跨端中的變與不變
各種新的技術層出不窮，在技術的疊代演進中，也演化出了各種新的技術方案以及新的容器。技術在演進，容器在發展，這是“變”。
那麼什麼是不變？容器那麼多，如何進行适配，是否每出現一種新的容器，我們必須要把目前的所有業務代碼進行重構才能保證在新的容器上穩定運作呢？我們的上層所有基礎設施是否需要重新開發？我們怎麼樣快速複用我們的強大的前端生态保證我們的開發效率？任何軟體工程遇到的問題都可以通過增加一個中間層來解決，我們通過 Rax.js 等研發架構，抹平了不同容器的差異，向上提供了同一套 DSL 給開發者，實作 “Write once, run everywhere”。
當然，标準化也是未來的趨勢，标準化的流程可以使未來各種新的方案無縫銜接。提到标準，前端開發者自然會想到 W3C，各種容器各種端，最終會殊途同歸，擁抱 W3C 标準，向标準化邁出一大步。
機遇與挑戰
無論方案怎麼變，我們無非是想要在性能、體驗、研發效率以及渲染一緻性這幾個緯度中找到一個最佳的平衡點。在跨端的浪潮中前端開發者如何找準方向，以及将會遇到怎麼樣的機遇與挑戰呢？
歡迎關注第十五屆D2前端技術論壇跨端技術專場，我們将邀請一線技術專家，為各位帶來有關跨端研發解決方案的新思路、新進展、新挑戰，結合真實業務場景共同剖析跨端研發提效、性能優化的最佳實踐。
以全球 Web 角度談前端性能的更新與趨勢
Palances Liao / Google 資深 Web 技術專家
前端性能一直以來都是一個艱深的話題，除了各家都有自己不同的量測标準之外，怎樣取得更精确的真實使用者性能資料及通過工具的輔佐讓我們更快速的調試成為了性能優化的一大難點。本專題會注重在 Google 如何定義性能名額，采集及提供優化性能的工具鍊如何幫助所有開發者快速調優前端性能，帶來 Google 的最新研究。
盒馬中背景跨端方案探索
孫偉偉（景莊） / 阿裡巴巴前端技術專家
實體零售數字化過程中，盒馬對人貨場進行了全新的重構，在多元的業态和作業場景中，傳統中背景的體驗邊界也進一步被延展，前端不再單一面向單一類型裝置進行開發與傳遞，而是需要觸及到 TVPCPadPhonePOSRFWatch 等更多的智能裝置。在盒馬，我們通過建構多端體驗産品 Hippo 去解決新零售科技場景下的多端内容傳遞與體驗一體化的問題，本次分享主要介紹盒馬的中背景跨端探索過程，包括多端統一的設計體系，可跨裝置複用的元件架構，以及支援跨端協同的應用架構。
跨端的另一種思路
佘錦鑫（當軒） / 阿裡巴巴前端技術專家
Write Once, Run Everywhere 是諸多跨端方案的最終理想，然而理想和現實往往存在差距，跨端方案本身在帶來提效的同時也伴随着相應的成本。本次分享主要介紹從場景出發，以 Flutter 和 Web 的邏輯跨端為例，介紹除 Write Once, Run Everywhere 之外的另一種思路。
關注「Alibaba F2E」
把握阿裡巴巴前端新動向