簡直是神仙打架! 多端統一框架哪家強?

目前市面上端的形態多種多樣,Web、App 、微信小程序等各類端大行其道,當業務要求同時在不一樣的端都要求有所表現的時候,針對不一樣的端去編寫多套代碼的成本顯然很是高,根源在於傳統網頁開發受瀏覽器能力限制太大,尤爲是各家瀏覽器的不一樣實現、離線能力和性能上的缺陷致使 App 很難知足用戶體驗的需求。

跨端」是目前前端界比較流行的一個詞彙。跨端框架本質上是將終端能力以一種形式提供業務開發使用,能夠無限制地使用全部終端能力的同時,儘可能讓業務開發只編寫一套代碼,這樣既能知足性能需求,又能減小開發成本。


但縱觀整個社區內的跨端開發框架,仍舊存在兩個主要問題:

    1.跨端框架對前端開發者來說難度較高,若是不具有移動終端開發能力,很難上手;
javascript


   2.平臺差別大,相同功能甚至要爲不一樣的平臺使用不一樣的接口編寫大量平臺相關代碼。css


出現上述問題的緣由,是由於目前業內的跨端框架,大部分由終端開發者主導開發,並非從前端開發者角度出發的,因此對於前端開發者來講不夠友好。


因而,市面上前後出現了很多跨端技術:uni-app 、Flutter、 WePY、 React Native  


而本文主要介紹的,是國內幾個大廠推出的解決方案:HippyChameleon TaroWeex前端




騰訊跨端框架- Hippy



當前star:4.5k
Github :https://github.com/Tencent/Hippy

去年2月20日,騰訊QQ瀏覽器部門發起的開源跨端框架 Hippy。在騰訊內部,Hippy 已運行3年之久,跨 BG 共有 18 款線上業務正在使用 Hippy,日均 PV 過億,且已創建一套完整生態。相較於其餘跨端框架,Hippy 對前端開發者更友好:緊貼 W3C 標準,聽從網頁開發各項規則,使用 JavaScript 爲開發語言,同時支持 React 和 Vue 兩種前端主流框架。java


Hippy 實現了相似 Flutter 的引擎直通架構(在 React Native 中的 Fabric 架構),經過 C++ 開發的模塊直接插入 JS 引擎中運行,繞過了前終端通信編解碼的開銷,有效提高了 JS 前端代碼和終端的通信性能。在此基礎之上,Hippy 正在實現高性能自繪,以提供更強的性能和更好的用戶體驗。react


hippy-react 從語法上更加接近終端底層,某種程度上語法接近 React Native,同時經過官方提供了 hippy-react-web 組件庫,也能夠方便地生成 Web 版網頁。android


特徵:

  • 爲傳統 Web 前端設計,官方支持 React 和 Vue 兩種主流前端框架。webpack

  • 不一樣的平臺保持了相同的接口。ios

  • 經過 JS 引擎 binding 模式實現的前終端通信。git

  • 提供了高性能的可複用列表。github

  • 皆可平滑遷移到 Web 瀏覽器。

  • 完整支持 Flex 的佈局引擎。


項目架構:


例:全民 K 歌:react + hippy-react + hippy-react-web




滴滴跨端框架 - Chameleon



當前star: 7.3k
GitHubhttps://github.com/didi/chameleon

Chameleon(簡寫 CML )中文名卡梅龍,中文意思:變色龍,意味着就像變色龍同樣能適應不一樣環境的跨端總體解決方案。工程化設計,豐富的基礎庫,首創多態協議,提供標準的 MVVM 架構開發模式統一各種終端。



對上圖各層定義以下:

  • API 接口協議(Library):定義基礎接口能力標準。
  • 內置組件協議(Library):定義基礎 Ui 組件標準。
  • 框架協議(Framework):定義生命週期、事件、路由等框架標準。
  • DSL 協議(Language):定義視圖和邏輯層的語法標準。
  • 多態實現協議(Interface):定義容許用戶使用差別化能力標準。

支持平臺:
w eb、微信小程序、支付寶小程序、百度小程序、android(weex)、ios(weex)、qq 小程序、字節跳動小程序、快應用、持續更新中


代碼示例:
<template> <view> <text>{{title}}</text><text>{{reversedTitle}}</text> </view></template>
<script>class Index { data = { title: "chameleon" } computed = { reversedTitle: function () { return this.title.split('').reverse().join('') } } mounted() {} destroyed() {}}export default new Index();</script>

網頁編程採用的是 HTML + CSS + JS 這樣的組合,一樣道理,chameleon 中採用的是 CML + CMSS + JS。

JS 語法用於處理頁面的邏輯層,與普通網頁編程相比,本項目目標定義標準 MVVM 框架,擁有完整的生命週期,watch,computed,數據雙向綁定等優秀的特性,可以快速提升開發速度、下降維護成本。

CML(Chameleon Markup Language)用於描述頁面的結構,咱們知道 HTML 是有一套標準的語義化標籤,例如文本是<span> 按鈕是<button>。CML 一樣具備一套標準的標籤,咱們將標籤訂義爲組件,CML 爲用戶提供了一系列組件。同時 CML 中還支持模板語法,例如條件渲染、列表渲染,數據綁定等等。同時,CML 支持使用類 VUE 語法,讓你更快入手。

CMSS (Chameleon Style Sheets)用於描述 CML 頁面結構的樣式語言,其具備大部分 CSS 的特性,而且還能夠支持各類 css 的預處語言less stylus


特色:

1. 多端高度一致
深刻到編程語言維度保障一致性,包括框架、生命週期、內置組件、事件通訊、路由、界面佈局、界面單位、組件做用域、組件通訊等高度統一

2. 組件
在用 CML 寫頁面時,chameleon 提供了豐富的組件供開發者使用,內置的有 button switch radio checkbox 等組件,擴展的有 c-picker c-dialog c-loading 等等,覆蓋了開發工做中經常使用的組件。

3. API
爲了方便開發者的高效開發,chameleon 提供了豐富的 API 庫,發佈爲 npm 包chameleon-api,裏面包括了網絡請求、數據存儲、地理位置、系統信息、動畫等方法。

4. 自由定製
基於多態協議,可自由擴展任意 API 和組件,不強依賴框架的更新。各端原始項目中已積累大量組件,也能直接引入到跨端項目中使用,可充分隔離各端差別化實現。

5. 智能規範校驗
代碼規範校驗,當出現不符合規範要求的代碼時,編輯器會展現智能提示,不用挨個調試各端代碼,同時命令行啓動窗口也會提示代碼的錯誤位置

6. 漸進式跨端 
不只能夠用 cml 開發頁面,也能夠將多端重用組件用 cml 開發,直接在原有項目裏面調用。





京東跨端框架 - Taro



當前star:24.5k
GitHub: http://github.com/nervjs/taro

Taro 是由京東 - 凹凸實驗室打造的一套遵循 React 語法規範的多端統一開發框架。


一套代碼,經過 Taro 的編譯工具,將源代碼分別編譯出能夠在不一樣端(微信小程序、H五、App 端等)運行的代碼。同時 Taro 還提供開箱即用的語法檢測和自動補全等功能,有效地提高了開發體驗和開發效率。

和微信自帶的小程序框架不同,Taro 積極擁抱社區現有的現代開發流程,包括但不限於:
  • NPM 包管理系統

  • ES6+ 語法

  • 自由的資源引用

  • CSS 預處理器和後處理器(SCSS、Less、PostCSS)


對於微信小程序的編譯流程,Taro的靈感來源於 Parcel ,自研了一套打包機制將 AST 不斷傳遞,所以代碼分析的速度獲得了很大的提升。一臺 2015 年 的 15寸 RMBP 在編譯上百個組件時僅須要大約 15 秒左右。

在 Taro 中,你不用像小程序同樣區分什麼是 App 組件,什麼是 Page 組件,什麼是 Component 組件,Taro 全都是 Component 組件,而且和 React 的生命週期徹底一致。能夠說,一旦你掌握了 React,那就幾乎掌握了 Taro。一樣使用聲明式的 JSX 語法。相比起字符串的模板語法,JSX 在處理精細複雜需求的時候會更駕輕就熟。

// 一個典型的 Taro 組件
   
     
   
   
    
    
    
    
import Taro, { Component } from '@tarojs/taro'import { View, Button } from '@tarojs/components'
export default class Homeextends Component{  constructor (props) {    super(props)    this.state = {      title: '首頁',      list: [1, 2, 3]    }  }
  componentWillMount () {}  componentDidMount () {}  componentWillUpdate (nextProps, nextState) {}  componentDidUpdate (prevProps, prevState) {}  shouldComponentUpdate (nextProps, nextState) {    return true }
  add = (e) => {    // dosth }
  render () {    const { list, title } = this.state    return (      <ViewclassName='index'>        <ViewclassName='title'>{title}</View>        <ViewclassName='content'>          {list.map(item => {            return (              <ViewclassName='item'>{item}</View>            )          })}          <ButtonclassName='add'onClick={this.add}>添加</Button>        </View>      </View>    )  }}

Taro已有功能相對完善的IDE:
錯誤語法觸發報錯,並給出報錯信息和一個文檔地址描述:



自動補全功能:





阿里無線前端 - Weex



當前star: 17.6k
GitHubhttps://github.com/alibaba/weex

Weex 是阿里巴巴開源的一套構建高性能,可擴展的原生應用跨平臺開發方案。
在 2016 年阿里雙十一中,Weex 在阿里雙十一會場中的覆蓋率接近 99%,頁面數量接近 2000,覆蓋了包括主會場、分會場、分分會場、人羣會場在內幾乎全部的阿里雙十一會場業務。阿里雙十一主會場秒開率97%,所有會場頁面達到 93%。


特色:

1. 頁面的開發目前支持Rax和Vue
Weex 也不是隻支持 Vue 和 Rax,你也能夠把本身喜歡的前端框架集成到 Weex 中,有一個文檔擴展前端框架描述瞭如何實現,可是這個過程仍然很是複雜和棘手,你須要瞭解關於 js-native 之間通訊和原生渲染引擎的許多底層細節。

2. 一次編寫,三端(Android、iOS、前端)運行
前提是都集成了 weex sdk,另外視覺表現作不到徹底同樣,有的會有一些差別,須要作一下適配。因此寫 weex 頁面的時候,若是支持三端,便須要在三端都進行自測。

3. 通訊
UI 的繪製經過 native 的組件,JavaScript 邏輯在 JS 引擎裏運行,二者經過 JavaScriptCore 通訊

4. 支持 Native 擴展
能夠將 native 的 UI 組件封裝成 component,將 native 的邏輯代碼封裝成 module。從而在 weex 裏能夠進行使用。這裏的 natiev UI 組件包括 modal、webview、image 等,這裏的 native 邏輯代碼包括 storage、network 等。

5. 視圖
每一個 weex 頁面會被打包成一個 js 文件,weex sdk 將 js 文件渲染成一個 view
weex 的打包經過 webpack,將每一個頁面打包成獨立的一個 js 文件,weex sdk 會將 js 進行解析,將 UI 部分繪製成一個 view, 再綁定 view 的事件與 js 代碼綁定。

6. 調試
均可以在chrome中調試JS代碼,weex支持在chrome中預覽頁面dom節點

7. 頁面開發
weex提供了一個playground,能夠方便的預覽正在開發的頁面

8. 即時預覽
weex和ReactNative都有提供hot reload功能,能夠邊更改代碼,邊在手機上看到效果 

9. 打包
weex默認打的js bundle只包含業務js代碼,體積小,基礎js庫包含在weex sdk中

10. 異步
weex只支持callback

例:



代碼:
   
     
   
   
    
    
    
    
<template>    <div class="wrapper">        <div class="login">            <div class="input-wrapper">                <input οnchange="onchangeUserNumber" class="input" type="text" placeholder="手機號" autofocus="true" value=""/>                <image class="input-img" src="resources/img/login_input_user_img.png"></image>            </div>                             //......                  </div>        <toast id="toast"></toast>    </div></template>
<script>    module.exports = {        data:{            userNumber:'',            userPassword:''        },        methods:{            onchangeUserNumber:function (event) {                this.userNumber = event.value;            },            onchangeUserPassword:function (event) {                this.userPassword = event.value;            },                        //......        } }</script>
<style> ......</style>





寫在最後

目前你們可能會有一些疑問,好比跨端技術之後是否會取代原生開發?對於這個一直爭議不斷的問題,筆者認爲,從目前的發展趨勢來看,並無取代一說,跨端的靈活與低成本,大多數應用場景是在一些變化較快的常規業務開發中,而原生開發中,好比定製化的視頻渲染,覆文本閱讀器,高響應度複雜動畫,各種傳感器好比 藍牙,陀螺儀,距離感應等等,這些關乎到交互體驗的細膩程度,目前仍是得以原生開發來處理。因此與其說取代,不如說二者相輔相成,互相配合,發揮出最高效率,纔是正確操做。

這麼多跨端技術,各有優劣,不能一句話去評判哪一個好與很差,至於選擇哪個,得考慮自家系統的現有架構,還得考慮開發人員的配置,因此適合本身,纔是選擇的標準。相信之後相似框架會愈來愈多,愈來愈成熟,學習成本也會愈來愈低,而就目前而言,國內這幾家的跨端開源框架,你更看好哪一個呢?

若是以爲文章對你有收穫,請點贊在看,分享。

◆ ◆ ◆ ◆ 

推薦閱讀:


玩轉VS Code

VS Code · 編程開發 · 業界資訊

本文分享自微信公衆號 - 玩轉VS Code(vs_code)。
若有侵權,請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」,歡迎正在閱讀的你也加入,一塊兒分享。

相關文章
相關標籤/搜索