原生革命--跨平臺開發技術解析

時間 2019-11-08

標籤原生革命跨平臺開發技術解析简体版

原文原文鏈接

這篇文章，我將着重分析當前主流跨平臺開發解決方案（偏架構）如Flutter、RN、Weex、Hybrid App，並對新晉跨端解決方案Fusion和Chameleon作一些分析，在傳統原生開發不斷被唱衰、大前端試圖一統天下的今天，瞭解這些知識是有必要的.javascript

原生開發

Native App是一種基於智能手機本地操做系統如iOS、Android、WP並使用原生程式編寫運行的第三方應用程序,也叫本地app。通常使用的開發語言爲Java、C++、Objective-C。自iOS和Android這兩個的手機操做系統發佈以來，在互聯網界今後就多了一個新的名詞：App意爲運行在智能的移動終端設備第三方應用程序)。 Native App由於位於平臺層上方，向下訪問和兼容的能力會比較好一些，能夠支持在線或離線，消息推送或本地資源訪問，攝像撥號功能的調取。html

優點

一、相比於其它模式，提供最佳的用戶體驗，最優質的用戶界面，最華麗的交互;
二、針對不一樣平臺提供不一樣體驗;
三、可節省帶寬成本，打開速度更快;
四、功能最爲強大,特別是在與系統交互中,幾乎全部功能都能實現.

原生開發痛點

實時性限制&&新功能依賴升級
- 一些實時性或者緊急需求必須經過App直接發版來解決問題，發佈週期長，應用市場審覈很浪費時間，並且用戶升級率不高；
- 當產品策劃提到一些新功能場景時，都必須經過一個完整的迭代流程來進行開發，最終經過發佈新版原本讓用戶使用到新的功能，開發和測試周期長。同時，用戶若是想使用新功能，必須依賴升級。沒法讓舊版本的用戶使用到新功能。
Bug沒法熱修復
- 移動開發過程當中常常會出現由於考慮不周致使的一些線上邏輯問題或者崩潰問題，通常狀況下都會經過從新打包發佈應用市場來解決，目前也有更方便的經過補丁來解決問題。經過動態化方案也能夠更好的經過熱發的方式來修復bug。簡單高效。
- App Store 2017年3月要求開發者移除熱更新代碼，2017年6月下架大量應用 2018年11月27日拼多多，搜狗導航，荔枝FM等被下架
多端協做成本高，不能跨平臺
- 目前整個移動市場是分爲android和ios，當需求提出的時候，會同時通知到android和ios兩位開發，進行需求評審和功能迭代，在需求溝通和實現過程當中總會出現各類溝通問題致使需求實現效果不統一，同時兩位開發也會很浪費人力。經過動態化方案，兩端能夠共用同一套代碼，來解決各自的邏輯，可以節省不少人力。

Android 系統架構

爲了能讓你們總體上大體瞭解Android系統涉及的知識層面，先來看一張Google官方提供的經典分層架構圖，從下往上依次分爲Linux內核、HAL、系統Native庫和Android運行時環境、Java框架層以及應用層這5層架構，其中每一層都包含大量的子模塊或子系統。前端

Linux內核層

Android系統創建在Linux 2.6之上，這一層爲Android設備的各類硬件提供了底層的驅動(Linux內核提供了安全性、內存管理、進程管理、網絡協議和驅動模型等核心系統服務)。
Linux內核也是系統硬件和軟件疊層之間的抽象層。vue

硬件抽象層 (HAL)

硬件抽象層 (HAL) 提供標準接口，HAL包含多個庫模塊，其中每一個模塊都爲特定類型的硬件組件實現一組接口，好比WIFI/藍牙模塊，當框架API請求訪問設備硬件時，Android系統將爲該硬件加載相應的庫模塊。java

Android Runtime & 系統庫

每一個應用都在其本身的進程中運行，都有本身的虛擬機實例。ART經過執行DEX文件可在設備運行多個虛擬機，DEX文件是一種專爲Android設計的字節碼格式文件，通過優化，使用內存不多。ART主要功能包括：預先(AOT)和即時(JIT)編譯，優化的垃圾回收(GC)，以及調試相關的支持。這裏的Native系統庫主要包括init孵化來的用戶空間的守護進程、HAL層以及開機動畫等。啓動init進程(pid=1),是Linux系統的用戶進程， init進程是全部用戶進程的鼻祖。react

Framework層

應用程序框架層提供開發Android應用程序所需的一系列類庫，使開發人員能夠進行快速的應用程序開發，方便重用組件，也能夠經過繼承實現個性化的擴展。linux

豐富而又可擴展的視圖(Views)，能夠用來構建應用程序，它包括列表(lists)，網格(grids)，文本框(text boxes)，按鈕(buttons)，甚至可嵌入的web瀏覽器；
內容提供器(Content Providers)使得應用程序能夠訪問另外一個應用程序的數據(如聯繫人數據庫)，或者共享它們本身的數據；
資源管理器(Resource Manager)提供非代碼資源的訪問，如本地字符串，圖形，和佈局文件( layout files )；
通知管理器 (Notification Manager) 使得應用程序能夠在狀態欄中顯示自定義的提示信息；
活動管理器( Activity Manager) 用來管理應用程序生命週期並提供經常使用的導航回退功能。

App層

Android平臺的應用層上包括各種與用戶直接交互的應用程序，或由java語言編寫的運行於後臺的服務程序。例如，智能手機上實現的常見基本功能程序，諸如SMS短信，電話撥號，圖片瀏覽器，日曆，遊戲，地圖，web瀏覽器等程序，以及開發人員開發的其餘應用程序。android

JNI

Java層與Native(C/C++)層之間的紐帶webpack

ios系統架構

iOS基於UNIX系統，iOS的系統架構分爲四層，由上到下一次爲：可觸摸層（Cocoa Touch layer）、媒體層（Media layer）、核心服務層（Core Services layer）、核心操做系統層（Core OS layer），以下圖：ios

note.youdao.com/yws/public/…

觸摸層

爲應用程序開發提供了各類經常使用的框架而且大部分框架與界面有關，本質上來講它負責用戶在iOS設備上的觸摸交互操做。如NotificationCenter的本地通知和遠程推送服務，iAd廣告框架，GameKit遊戲工具框架，消息UI框架，圖片UI框架，地圖框架，鏈接手錶框架，自動適配等等

媒體層

提供應用中視聽方面的技術，如圖形圖像相關的CoreGraphics,CoreImage,GLKit,OpenGL ES,CoreText,ImageIO等等。聲音技術相關的CoreAudio,OpenAL,AVFoundation,視頻相關的CoreMedia,Media Player框架，音視頻傳輸的AirPlay框架等等。

核心服務層

提供給應用所須要的基礎的系統服務。如Accounts帳戶框架，廣告框架，數據存儲框架，網絡鏈接框架，地理位置框架，運動框架等等。這些服務中的最核心的是CoreFoundation和Foundation框架，定義了全部應用使用的數據類型。CoreFoundation是基於C的一組接口，Foundation是對CoreFoundation的OC封裝。

核心操做系統層包括

包含大多數低級別接近硬件的功能，它所包含的框架經常被其它框架所使用。Accelerate框架包含數字信號，線性代數，圖像處理的接口。針對全部的iOS設備硬件之間的差別作優化，保證寫一次代碼在全部iOS設備上高效運行。CoreBluetooth框架利用藍牙和外設交互，包括掃描鏈接藍牙設備，保存鏈接狀態，斷開鏈接，獲取外設的數據或者給外設傳輸數據等等。Security框架提供管理證書，公鑰和私鑰信任策略，keychain,hash認證數字簽名等等與安全相關的解決方案。

跨平臺開發

跨平臺開發的目的

write once，run everywhere
線上動態性，不須要頻繁更新版本便可實現新業務的上線
增長代碼複用，減小開發者對多個平臺差別適配的工做量，解決多端不一致的問題
提升業務專一的同時，提供比web更好的體驗
下降開發成本

跨平臺開發流派

Web 流：也被稱爲 Hybrid 技術，它基於 Web 相關技術來實現界面及功能
Cordova，AppCan，小程序，快應用
代碼轉換流：將某個語言轉成 Objective-C、Java 或 C#，java2OC，OC2Java，java2C#,Dart2Js，而後使用不一樣平臺下的官方工具來開發
Flutter Web（Dart2Js）
編譯流：將某個語言編譯爲二進制文件，生成動態庫或打包成 apk/ipa/xap 文件
Xamarin（iOS 下是以 AOT 的方式編譯爲二進制文件的）
虛擬機流：經過將某個語言的虛擬機移植到不一樣平臺上來運行
Flutter，Titanium，React Native，Weex

百度吳多益2015年準確預測了RN成爲跨平臺開發主流技術
 數據-2017年三月跨平臺App分佈

跨平臺開發主流技術

Flutter（Google）
ReactNative（FaceBook）
Weex（Alibaba）
Hybrid App
Cordova（原PhoneGap，Adobe）
小程序，快應用

比較

解決方案	ReactNative	Weex	Flutter	Hybrid App
平臺實現	JavaScript	JavaScript	無橋接，原生編碼	無橋接，原生編碼
引擎	JSCore	JS V8	Flutter engine	原生渲染
核心語言	React	Vue	Dart	Java/Obeject-C
上手難度（原生角度）	較高	通常	通常	容易
框架程度	較重	較輕	重	-
特色	適合開發總體App	適合單頁面	適合開發總體App	適合開發總體App
社區	豐富，FaceBook重點維護	有點殘念，託管apache	剛出道小鮮肉，擁護者衆多	豐富
線上動態性	✅	✅	❎	❎
跨平臺支持	Android、iOS	Android、iOS、Web	Android、iOS	Android、iOS

Flutter

閒魚、美團，餓了麼、NOW直播（騰訊）、京東金融

Flutter是谷歌的最新移動UI框架。Beta1版本於2018年2月27日在2018 世界移動大會公佈，Beta2版本2018年3月6日發佈。開發者可使用 Flutter 在 iOS 和 Android 平臺上開發原生應用。它也是將來的Google新操做系統 Fuchsia 應用的主要開發方式。

Flutter是一種新型的「客戶端」技術。它的最終目標是替代包含幾乎全部平臺的開發：iOS，Android，Web，桌面；作到了一次編寫，多處運行。

Google 出品，Dart語言，Flutter Engine引擎，響應式設計模式，原生渲染

優勢

熱重載（Hot Reload），利用Android Studio直接一個ctrl+s就能夠保存並重載，模擬器立馬就能夠看見效果，相比原生冗長的編譯過程強不少；
一切皆爲Widget的理念，對於Flutter來講，手機應用裏的全部東西都是Widget，經過可組合的空間集合、豐富的動畫庫以及分層課擴展的架構實現了富有感染力的靈活界面設計；
藉助可移植的GPU加速的渲染引擎以及高性能本地代碼運行時以達到跨平臺設備的高質量用戶體驗。簡單來講就是：最終結果就是利用Flutter構建的應用在運行效率上會和原生應用差很少。

缺點

不支持熱更新；
三方庫不多，須要本身造輪子；
dart語言編寫，掌握該語言的開發者不多。

理念架構

Flutter 主要分爲 Framework 和 Engine，咱們基於Framework 開發App，運行在 Engine 上。Engine 是 Flutter 的獨立虛擬機，由它適配和提供跨平臺支持，目前猜想 Flutter 應用程序在 Android 上，是直接運行 Engine 上因此在是不須要Dalvik虛擬機。（這是比kotlin更完全，拋棄JVM的糾纏？）
得益於 Engine 層，Flutter 甚至不使用移動平臺的原生控件，而是使用本身 Engine 來繪製 Widget （Flutter的顯示單元），而 Dart 代碼都是經過 AOT 編譯爲平臺的原生代碼，因此 Flutter 能夠直接與平臺通訊，不須要JS引擎的橋接。同時 Flutter 惟一要求系統提供的是 canvas，以實現UI的繪製。

FrameWork層

Flutter的頂層是用drat編寫的框架（SDK），它實現了一套基礎庫，包含Material（Android風格UI）和Cupertino（iOS風格）的UI界面，下面是通用的Widgets（組件），以後是一些動畫、繪製、渲染、手勢庫等。這個純 Dart實現的 SDK被封裝爲了一個叫做 dart:ui的 Dart庫。咱們在使用 Flutter寫 App的時候，直接導入這個庫便可使用組件等功能。

Engine層

Skia是Google的一個 2D的繪圖引擎庫，其前身是一個向量繪圖軟件，Chrome和 Android均採用 Skia做爲繪圖引擎。Skia提供了很是友好的 API，而且在圖形轉換、文字渲染、位圖渲染方面都提供了友好、高效的表現。Skia是跨平臺的，因此能夠被嵌入到 Flutter的 iOS SDK中，而不用去研究 iOS閉源的 Core Graphics / Core Animation。Android自帶了 Skia，因此 Flutter Android SDK要比 iOS SDK小不少。
第二是Dart 運行時環境
第三文本渲染布局引擎。

繪圖基本原理

提到原理，咱們要從屏幕顯示圖像的基本原理開始談起。咱們都知道顯示器以固定的頻率刷新，好比 iPhone的 60Hz、iPad Pro的 120Hz。當一幀圖像繪製完畢後準備繪製下一幀時，顯示器會發出一個垂直同步信號（VSync），因此 60Hz的屏幕就會一秒內發出 60次這樣的信號。而且通常地來講，計算機系統中，CPU、GPU和顯示器以一種特定的方式協做：CPU將計算好的顯示內容提交給 GPU，GPU渲染後放入幀緩衝區，而後視頻控制器按照 VSync信號從幀緩衝區取幀數據傳遞給顯示器顯示。

因此，Android、iOS的 App在顯示 UI時是如此，Flutter也不例外，也遵循了這種模式。因此從這裏能夠看出 Flutter和 React-Native之衆的本質區別：React-Native之類只是擴展調用 OEM組件，而 Flutter是本身渲染。

Flutter繪製流程

Flutter只關心向 GPU提供視圖數據，GPU的 VSync信號同步到 UI線程，UI線程使用 Dart來構建抽象的視圖結構，這份數據結構在 GPU線程進行圖層合成，視圖數據提供給 Skia引擎渲染爲 GPU數據，這些數據經過 OpenGL或者 Vulkan提供給 GPU。

因此 Flutter並不關心顯示器、視頻控制器以及 GPU具體工做，它只關心 GPU發出的 VSync信號，儘量快地在兩個 VSync信號之間計算併合成視圖數據，而且把數據提供給 GPU。

Flutter for Web

在前些日子舉辦的Google IO 2019 年度開發者大會上，Flutter web做爲一個很亮眼的技術受到了開發者的追捧。這是繼Flutter支持Android、IOS等設備以後，又一個里程碑式的版本，後續還會支持windows、linux、Macos、chroms等其餘嵌入式設備。

經過對比，能夠發現，web框架層和mobile的幾乎如出一轍。所以只須要從新實現一下引擎和嵌入層，不用變更Flutter API就能夠徹底能夠將UI代碼從Android / IOS Flutter App移植到Web。Dart可以使用Dart2Js編譯器把Dart代碼編譯成Js代碼。大多數原生App元素可以經過DOM實現，DOM實現不了的元素能夠經過Canvas來實現。

成熟案例

閒魚 - Release Flutter的最後一千米

React Native

墨刀，京東，手機百度 ,騰訊QQ，QQ空間，Facebook及旗下應用

React Native (簡稱RN)是Facebook於2015年4月開源的跨平臺移動應用開發框架，目前支持iOS和安卓兩大平臺。RN使用Javascript語言，相似於HTML的JSX，以及CSS來開發移動應用，所以熟悉Web前端開發的技術人員只需不多的學習就能夠進入移動應用開發領域。React Native着力於提升多平臺開發的開發效率 —— 僅需學習一次，編寫任何平臺

Facebook 出品，JavaScript語言，JSCore引擎，React設計模式，原生渲染

優勢

效率體驗接近原生應用質量，發佈和開發成本低於原生App；
支持熱更新，快速迭代；
社區活躍，基本坑點都能解決；
代碼跨越雙平臺

缺點

RN 的開源庫質量良莠不齊；
RN 運行時的初始化太慢，首次渲染時間慢（須要從主線程 -> JS -> Yoga -> 主線程）；
調試困難，JSCore 在 iOS / Android 上不一致（Android 上是 RN 本身 bundle 的），很難 debug 這種坑

理念架構

「Learn once, write anywhere」，表明着 Facebook對 react native 的定義：學習 react ，同時掌握 web 與 app 兩種開發技能。 react native 用了 react 的設計模式，但UI渲染、動畫效果、網絡請求等均由原生端實現。開發者編寫的js代碼，經過 react native 的中間層轉化爲原生控件和操做，比ionic等跨平臺應用，大大提升了的用戶體驗。
總結起來其實就是利用 JS 來調用 Native 端的組件，從而實現相應的功能。
以下圖所示，react native 的跨平臺是實現主要由三層構成，其中 C++ 實現的動態連結庫(.so)，做爲中間適配層橋接，實現了js端與原生端的雙向通訊交互。這裏最主要是封裝了 JavaScriptCore 執行js的解析，而 react native 運行在JavaScriptCore中，因此不存在瀏覽器兼容的問題。
其中在IOS上直接使用內置的javascriptcore，在Android 則使用webkit.org官方開源的jsc.so。

實現原理

和前端開發不一樣，react native 全部的標籤都不是真實控件，JS代碼中所寫控件的做用，相似 Map 中的 key 值。JS端經過這個 key 組合的 Dom ，最後Native端會解析這個 Dom ，獲得對應的Native控件渲染，如 Android 中標籤對應 ViewGroup 控件。
在 react native 中，JS端是運行在獨立的線程中（稱爲JS Thread ）。JS Thread 做爲單線程邏輯，不可能處理耗時的操做。那麼如 fetch 、圖片加載、數據持久化等操做，在 Android 中實際對應的是 okhttp 、Fresco 、SharedPreferences等。而跨線程通訊，也意味着 Js Thread 和原生之間交互與通信是異步的。
能夠看出，跨平臺的關鍵在於C++層，開發人員大部分時候，只專一於JS 端的代碼實現。在原生端提供的各類 Native Module 模塊（如網絡請求，ViewGroup控件），和 JS 端提供的各類 JS Module（如JS EventEmiter模塊），都會在C++實現的so中保存起來，雙方的通信經過C++中的保存的映射，最終實現兩端的交互。

Virtual Dom

虛擬DOM是一種使用js對象來描述真實DOM的技術，主要是運用一種diff的算法，高效完成局部數據刷新。網頁實際上都是解析成dom的格式被加載渲染，可是每次渲染都是dom數據的重載，而virtual dom則是實現了部分從新加載這樣就大大提升了高效性。經過這種技術，一方面咱們能精確知道哪些真實DOM改變了，從而儘可能減小DOM操做的性能開銷。另一方面因爲真實DOM都經過js對象來描述了，因此咱們能夠嘗試使用數據來驅動DOM開發，好比著名的react就是這樣作的。

//virtual dom
 {
    tag: 'div'
    data: {
        class: 'outer'
    },
    children: [
        {
            tag: 'div',
            data: {
                class: 'inner'
            }
            text: 'Virtual DOM'
        }
    ]
}

// 真實 dom
<div class="outer">
    <span class="inner">Virtual DOM</span>
</div>

複製代碼

//Js代碼 Text被編譯成Android的TextView
render() { 
        return (<View > 
                <Text >Hello,World</Text>
         </View>); 
}
複製代碼

成熟案例

京東618：ReactNative框架在京東無線端的實踐

WEEX

淘寶，天貓，支付寶，網易考拉，網易嚴選

2016年4月21日，阿里巴巴在Qcon大會上宣佈跨平臺移動開發工具Weex。Weex框架可以完美兼顧性能與動態性，讓移動開發者經過簡捷的前端語法寫出Native級別的性能體驗，並支持iOS、安卓、YunOS及Web等多端部署。Weex基於開源的Vue.JS，相比於 RN來講入門簡單，容易上手。目前阿里系的不少產品好比淘寶，支付寶和一些小公司app都在用WEEX。

Alibaba 出品，JavaScript語言，JS V8引擎，Vue設計模式，原生渲染

優勢

單頁開發模式效率極高，熱更新發包體積小，而且跨平臺性更強

缺點

社區沒有RN活躍，功能尚不健全，暫不適合徹底使用Weex開發App

理念架構

「Write once, run everywhere」, weex的定義就像是：寫個 vue 前端，順便幫你編譯成性能還不錯的 apk 和 ipa（固然，現實有時很骨感）。基於 Vue 設計模式，支持 web、android、ios 三端，原生端一樣經過中間層轉化，將控件和操做轉化爲原生邏輯來提升用戶體驗。
在 weex 中，主要包括三大部分：JS Bridge、Render、Dom，分別對應WXBridgeManager、WXRenderManager、WXDomManager，三部分經過WXSDKManager統一管理。其中 JS Bridge 和 Dom 都運行在獨立的 HandlerThread 中，而 Render 運行在 UI 線程。
JS Bridge 主要用來和 JS 端實現進行雙向通訊，好比把 JS 端的 dom 結構傳遞給 Dom 線程。Dom 主要是用於負責 dom 的解析、映射、添加等等的操做，最後通知UI線程更新。而 Render 負責在UI線程中對 dom 實現渲染。
以下圖，是生成dom，dom的解析，映射，添加，渲染的流程。

如上可知，由於JS端運行於獨立的單線程中，因此爲了保證運行的流暢性，通常須要避免在JS端執行耗時操做，好比：網絡請求，圖片加載等，其實都是在原生端完成，js端執行的是發起一個請求和響應一個結果。同時由於原生端與JS端是經過JS Bridge通信，因此也須要儘可能避免大數據和頻繁的通信，致使響應的延遲。
原生端的dom的加載解析映射，也是性能的一大瓶頸。通常而言，Weex在Web端生成的，是經過webpack的webConfig打包成單頁面的index.web.js文件；而在原生端，通常會經過webpack的weexEntry配置成多頁面形式：即每個須要獨立的.vue的頁面，最終會被打包成一個.js文件。因此打開每一個頁面時加載對應的js文件，這很好的減少了須要加載的文件大小，提升了dom的解析效率。最後，Weex默認打的js只包含業務js代碼，基礎js庫已經被包含在weex sdk中，也使得體積會小不少。

實現原理

和 react native同樣，weex 全部的標籤也不是真實控件，JS 代碼中所生成存的 dom，最後都是由 Native 端解析，再獲得對應的Native控件渲染，如 Android 中標籤對應 WXTextView 控件。
weex 中文件默認爲 .vue ，而 vue 文件是被沒法直接運行的，因此 vue 會被編譯成 .js 格式的文件，Weex SDK會負責加載渲染這個js文件。Weex能夠作到跨三端的原理在於：在開發過程當中，代碼模式、編譯過程、模板組件、數據綁定、生命週期等上層語法是一致的。不一樣的是在 JS Framework 層的最後，web 平臺和 Native 平臺，對 Virtual DOM 執行的解析方法是有區別的。

實際上，在 Native 中對 bundle 文件的加載大體經歷如下階段：

weex 接收到 js 文件之後，JS Framework 根據文件爲 Vue 模式，會調用weex-vue-framework 中提供的 createInstance方法建立實例。(也多是Rax模式)
createInstance 中會執行 Js Entry 代碼裏 new Vue() 建立一個組件，經過其 render 函數建立出 Virtual DOM 節點。
由JS V8 引擎上解析 Virtual DOM ，獲得 Json 數據發送至 Dom 線，這裏輸出 Json 也是方便跨端的數據傳輸。
Dom 線程解析 Json 數據，獲得對應的 WxDomObject，而後建立對應的WxComponent 提交 Render 。
Render在原生端最終處理處理渲染任務，並回調裏JS方法。

得益於上層的統一性，只是經過 weex-vue-framework 判斷是由Vue.js 生成真實的 Dom ，仍是經過 Native Api 渲染組件，weex 必定程度上上，用JS 實現了 vue 一統天下的效果。 weex 在原生渲染 Render 時，在接收到渲染指令後，會逐步將數據渲染成原生組件。Render 經過解析渲染數據的描述，而後分發給不一樣的模塊。
好比控件渲染屬於 dom 模塊中，頁面跳轉屬於navigator模塊等。模塊的渲染過程並不是一個執行完，再執行另外一個的流程，而是相似流式的過程。如上一個的組件還沒渲染好，下一個'div'的渲染又發了過來。這樣當一個組件的嵌套組件不少時，或者能夠看到這個大組件內的UI，一個一個渲染出來的過程。
weex 比起react native，主要是在JS V8的引擎上，多了 JS Framework 承當了重要的職責，使得上層具有統一性，能夠支持跨三個平臺。總的來講它主要負責是：管理Weex的生命週期；解析JS Bundle，轉爲Virtual DOM，再經過所在平臺不一樣的API方法，構建頁面；進行雙向的數據交互和響應。

成熟案例

Weex在內涵段子發現頁中的工程實踐

Hybrid App（Android/iOS+Html5）

微信，愛奇藝，我愛我家

Hybrid App主要以JS+Native二者相互調用爲主，從開發層面實現「一次開發，多處運行」的機制，成爲真正適合跨平臺的開發。Hybrid App兼具了Native App良好用戶體驗的優點，也兼具了Web App使用HTML5跨平臺開發低成本的優點。

基於WebView UI，原生渲染

優勢

兼具了Native App良好用戶體驗的優點；
提高了開發效率，h5能夠多平臺複用，由服務器快速迭代；
實現簡單，且原生與h5開發人員充沛。

缺點

體驗比不上原生,webView性能差；
適用部分展現頁面，複雜交互仍須要原生開發；
須要對應平臺人員配合，jsApi因需求須要調整，版本迭代並不自由.

理念架構

做爲一種混合開發的模式，Hybrid APP底層依賴於Native提供的容器（UIWebview），上層使用Html&Css&JS作業務開發，底層透明化、上層多多樣化，這種場景很是有利於前端介入，很是適合業務快速迭代。

技術原理

Hybrid App的本質，實際上是在原生的 App 中，使用 WebView 做爲容器直接承載 Web頁面。所以，最核心的點就是 Native端與 H5端之間的雙向通信層，其實這裏也能夠理解爲咱們須要一套跨語言通信方案，來完成 Native(Java/Objective-c/...) 與 JavaScript 的通信。這個方案就是咱們所說的 JSBridge，而實現的關鍵，即是做爲容器的 WebView，一切的原理都是基於 WebView 的機制。

App中H5的接入方式

在線H5，這是最多見的一種方式。
咱們只須要將H5代碼部署到服務器上，只要把對應的 URL地址給到客戶端，用 WebView 打開該URL，便可嵌入。
該方式的好處在於:
- 獨立性強，有很是獨立的開發/調試/更新/上線能力；
- 資源放在服務器上，徹底不會影響客戶端的包體積；
- 接入成本很低，徹底的熱更新機制。
  但相對的，這種方式也有對應的缺點:
- 徹底的網絡依賴，在離線的狀況下沒法打開頁面；
- 首屏加載速度依賴於網絡，網絡較慢時，首屏加載也較慢；

一般，這種方式更適用在一些比較輕量級的頁面上，例如一些幫助頁、提示頁、使用攻略等頁面。這些頁面的特色是功能性不強，不太須要複雜的功能協議，且不須要離線使用。在一些第三方頁面接入上，也會使用這種方式，例如咱們的頁面調用微信JS-SDK。

內置包H5，這是一種本地化的嵌入方式，咱們須要將代碼進行打包後下發到客戶端，並由客戶端直接解壓到本地儲存中。一般咱們運用在一些比較大和比較重要的模塊上。其優勢是:
- 因爲其本地化，首屏加載速度快，用戶體驗更爲接近原生；
- 能夠不依賴網絡，離線運行；
  但同時，它的劣勢也十分明顯:
- 開發流程/更新機制複雜化，須要客戶端，甚至服務端的共同協做；
- 會相應的增長 App 包體積；

這兩種接入方式均有本身的優缺點，應該根據不一樣場景進行選擇。

成熟案例

閱文 - 起點海外版 Hybrid App－內嵌頁優化實踐

Hybrid 開發框架

Cordova

Apache Cordova是一個開源移動開發框架。它容許您使用標準Web技術 - HTML5，CSS3和JavaScript進行跨平臺開發。如 Android 和 iOS 。儘管你在開發中仍然須要用到該平臺特定的技術，例如 Android SDK 或 Xcode ，你也無需再編寫任何 Android 或 iOS 代碼就能完成應用開發。 Cordova 可以將你的 HTML/JS 代碼打包在一個原生的容器中運行，並依賴符合標準的API綁定來訪問每一個設備的功能，如傳感器，數據，網絡狀態等。基本功能徹底具有，對於底層，如攝像頭之類的，須要插件。

優勢

寫一次代碼，多個平臺都適用（iOS，Android，Blackberry，Symbian，WP等）。
基本功能徹底具有，對於底層，如攝像頭之類的，須要插件。

缺點

運行速度相對較慢
Web開發者需掌握部分原生開發知識，增長學習成本

架構

用 Cordova 和 Vue.js 構建一個 APP

1.安裝Cordova CLI（cordova命令行界面）
2.建立應用程序
3.添加平臺
4.添加插件（讓應用具有訪問設備級功能）
5.使用合併自定義每一個平臺
6.更新Cordova和項目
7.打包

Hybrid 其餘框架

AppCan

AppCan是基於HTML5技術的Hybird跨平臺移動應用開發工具。開發者利用 Html5+Css3+JavaScript技術，經過AppCan IDE集成開發系統、雲端打包器等，快速開發出Android、iOS、WP平臺上的移動應用。

Titanium

Titanium移動平臺是全部移動開發平臺中比較另類的，它將JavaScript和本地庫連接在一塊兒，編譯成字節碼，針對iOS以及Android兩個平臺分別構建一個軟件包。應用程序使用HTML， JavaScript和CSS進行開發，並支持PHP，Ruby和Python。應用程序可使用 Appcelerator API 訪問本地特性。並提供Appcelerator Studio開發環境，因爲編譯成本地代碼，因此用戶體驗是最好的。

Xamarin

Xamarin 是微軟子公司提供的一個跨平臺開發軟件，經過使用 C＃/.NET 共享的代碼庫，開發人員能夠在 Xamarin 工具上，使用本地用戶界面編寫原生的 Android、iOS 和 Windows 應用程序，並跨多個平臺（包括 Windows 和 macOS）共享代碼。

小程序、快應用

小程序

小程序開發本質上仍是前端 HTML + CSS + JS 那一套邏輯，它基於 WebView 和微信本身定義的一套 JS/WXML/WXSS/JSON 來開發和渲染頁面。微信官方文檔裏提到，小程序運行在三端： iOS、Android 和用於調試的開發者工具，三端的腳本執行環境以及用於渲染非原生組件的環境是各不相同的：

在 iOS 上，小程序的 JavaScript 代碼是運行在 JavaScriptCore 中，是由 WKWebView 來渲染的，環境有 iOS 8+；
在 Android 上，小程序的 JavaScript 代碼是經過 X5 JSCore 來解析，是由 X5 基於 Mobile Chrome 53/57 內核來渲染的；
在開發工具上，小程序的 JavaScript 代碼是運行在 nwjs 中，是由 Chrome Webview 來渲染的。

快應用

2018 年 3 月 20 日，小米、中興、華爲、金立、聯想、魅族、努比亞、OPPO、vivo、一加，共十家手機廠商在北京聯合召開快應用標準啓動發佈會，基於硬件平臺共同推出的新型應用生態。
快應用使用前端技術棧開發，原生渲染，同時具有 HTML 5 頁面和原生應用的雙重優勢。用戶無需下載安裝，即點即用，享受原生應用的性能體驗。快應用框架深度集成進各廠商手機系統中，能夠在操做系統層面實現用戶需求與應用服務間的無縫鏈接，提高用戶的使用體驗和應用服務的轉化效率，同時支持生成桌面圖標等留存能力。（快應用應該不能稱爲是跨平臺開發方案，它只是國內手機廠商聯合主導的在安卓系統層面提供快捷服務，旨在與小程序抗衡）

Chameleon （DiDi出品）

背景：

雖然不一樣各端框架環境變幻無窮，不管各種小程序、Weex、React-Native、Flutter、快應用，它們萬變不離其宗的是MVVM架構設計思想。Chameleon但願既能用一套代碼完成全部端需求，將相同的業務邏輯完成收斂到同一層系統裏面，又不會由於項目的抽象一致致使可維護性變差。

Chameleon原理

讓MVVM跨端環境大統一：以各個跨端技術(Weex、React-Native、WebView瀏覽器、Flutter)和產品業務(微信小程序、快應用、支付寶小程序、百度智能小程序、今日頭條小程序、其餘各種小程序)的共同技術特色——MVVM架構設計，以統一MVVM跨端架構平臺爲目標的程序語言框架Chameleon(任意使用MVVM架構設計的終端，都能以Chameleon開發並運行)。

View:
ChameleonSDK包括各種小程序、web端、客戶端(React-Native、Weex、Flutter)，目前支持微信小程序、Web、Weex三類，後續支持更多MVVM爲標準的端。

View Model:
CML(Chameleon MarkupLanguage)是框架設計的一套標籤語言，結合基礎組件、事件系統、數據綁定，能夠構建出頁面的結構。同時爲了下降學習成本支持類VueTemplate。

uni-app（DCloud）

uni-app 是一個使用 Vue.js 開發跨平臺應用的前端框架，開發者編寫一套代碼，可編譯到iOS、Android、H五、小程序等多個平臺。

uni-app能力

功能框架

uni-app在跨平臺的過程當中，不犧牲平臺特點，可優雅的調用平臺專有能力，真正作到海納百川、各取所長。

Fusion (Alibaba出品)

阿里中後臺UI解決方案
Fusion 不只僅是組件庫，其核心是經過可配置工具實現快速定製和品牌化
Fusion 不只僅是爲前端服務的，還面向設計師，促進二者間的協做，下降溝通和複用成本
Fusion 組件庫是基於 React 技術棧實現的。

1.Fusion出現背景

PC端瀏覽器的UI場景，交互功能都是類似的，但樣式差別卻很大，這些年PC端的UI變化中，變得更多的也是樣式，而非交互。隨着一個公司業務線的持續增加，須要創建多套網站，網站個性化需求龐大，若是每次翻新網站或者建立新的網站都須要從0~1去實現，那麼人力成本，工做量無疑是巨大的，並且重複性的工做將會很是大，阿里爲了解決多業務線龐大的組件需求研發了Fusion.

通常一個項目的上線流程基本都要經歷，評審、設計、開發、測試這幾個階段。

評審：業務交互，業務邏輯的評審；
設計：設計規範，視覺設計，標註稿；
開發：前端通常都會有一套組件庫；可是組件庫可能和本身業務線的品牌並非對應的，因此第一步須要在組件層面作 UI 的定製，而後是業務邏輯的開發；
測試：最多見的就是設計師和前端坐在一塊兒兩天專門作 UI 還原度 review；業務邏輯測試是比作流程很少說。 重複工做
標黃的部分是各個業務棧間的重複工做，包括交互規範、設計規範、視覺還原、組件開發多是重複性工做。

協同問題（UI設計師和前端人員）

由於使用的工具不一樣對概念的認知不一樣；
設計師的理想和前端的現實問題之間的差異
每隔一段時間品牌就會升級一次，基礎 UI 翻新，會有較大的工做量
設計師間約定的規範沒有很好的落實，已經設計好的設計稿你們共享不便
已經開發好的組件沒有造成很好的複用

2.Fusion能力

工做流

去除重複流程，只關注業務
- 設計師 使用的同一套規範的組件，產出的設計稿都是同一套規範。（這裏使用sketch插件名字叫FusionCool)
- 前端不須要關注組件 UI 還原度。（還原度有問題 = 設計配置的問題）
不須要再作從0~1的事情
- 設計端使用 sketch 插件（FusionCool）在 sketch 既能設計頁面，又能沉澱已經設計完成的模板
- 開發端使用開發工具（Iceworks）在項目中既能使用現成的模塊，又能沉澱已經開發完成的模塊

組成

Fusion組成
一個組件庫：@alifd/next
@alifd/next 是一套基於 React 的組件庫, 咱們內部稱之爲骨架 DPL(Design Pattern Library)。

一個平臺：fusion.design
站點提供三種能力：文檔編輯、主題管理、物料託管。

兩個工具：
  設計師工具 FusionCool Sketch插件
        主題發佈完成後就到了 Sketch 的插件端 FusionCool，設計師能夠在 FusionCool 裏面搜索 iconfont 全部素材、使用配置好的組件、使用站點的模塊模板。
  開發者工具 Iceworks客戶端
        Iceworks 是淘寶飛冰團隊開發的面向前端開發者的 GUI 工具，開發者無須關注環境的問題，而且有海量物料可用。目前已經和 Fusion 的物料體系打通，能夠輕鬆使用 Fusion 站點的物料。

如何保證開發對設計的無差別實現

經過抽象骨架 DPL -> 經過平臺定製產出定製好UI的組件、模板 -> 流入設計師的工具裏面直接拖拽使用 -> 前端直接使用定製好的組件（不需關注組件UI）

1.fusion.design 能夠定製本身的 Design System（如下簡稱DS），配置主題等
2.站點主題發佈完成，設計師在 Sketch 的插件端 FusionCool裏面搜索 iconfont 全部素材、使用配置好的組件、使用站點的模塊模板，自定義配置本身的網站；
3.開發者接收設計師的Config樣式包的倉庫。開發者能夠在上面預覽到設計師更新設計的全部組件樣式，以及API，只須要拷貝API到代碼中，就能完整還原構建者設計的組件，不須要開發新的。

3.Fusion的技術實現

前端 Next 組件
Fusion Next 是基於 React 實現的一套 PC 端的組件庫，這套組件庫已經在阿里內部服務了三年。github 地址：github.com/alibaba-fus… 此次開源出來的版本是最近一年基於以前兩年的使用經驗、問題反饋進行從新整理和優化過。
設計師 FusionCool Sketch插件
FusionCool 底層使用 Airbnb 提供的 react-sketch 能力寫成的一份 Next 組件，直接經過 DesignToken（通用變量+組件變量）覆蓋默認變量，最終在 Sketch 端實時渲染。