網易嚴選App感受Weex開發
自打出生的那一天起,WEEX就免不了被拿來同React Native「一決高下」的命運。React Native宣稱「Learn Once, Write Anywhere」,而WEEX宣稱「Write Once, Run Everywhere」。在我看來,並沒有誰更好,只有誰更合適。下面我將圍繞WEEX入門進行講解。
(如果你尚不了解React Native,並想簡單入門,可以閱讀【整理】ReactNative快速入門筆記)
網易嚴選App感受Weex開發
什麼都不說,先給你感受下weex的效果。以下就是我使用weex,4*8h(不連續)做出來的demo,其中還包括素材收集,踩坑總結等時間。
此處是github源碼地址:
https://github.com/zwwill/yanxuan-weex-demo感謝【Star】【Fock】支持
不得不說,使用Weex開發App對於我們純前端人員來說,是件很爽的事情,只要你熟悉了他的語法,基本可以做到一周上手寫app。極其適合交互要求不高,時間緊迫,人手不足的同構開發需求。
但是,當然有但是,如果你想寫出一個完美的app,你就需要在性能優化上下很大的功夫,包括動畫的優化,過場的優化,圖片的優化,細節的打磨等等,在這就是你需要掌握或者「能寫」一些原生的代碼,不然有些功能你是
實現不了的,比如status bar的屬性更改,開場動畫的製作,內存的回收,webview的監聽等等。下面我們具體講講入門知識
Write Once, Run Everywhere
Weex 提供了多端一致的技術方案。
- 首先 web 開發體驗在各端當中是相同的。包括語法設計和工程鏈路。
- 其次,Weex 的組件、模塊設計都是 iOS、Android、Web 的開發者共同討論出來的,有一定的通用性和普遍性。
- Weex 開發同一份代碼,可以在不同的端上分別執行,避免了多端的重複研發成本。
在同構這條路上,WEEX比ReactNative做得更徹底,他「幾乎」做到了,「你來使用vue寫一個webapp,我順便給你編譯成了ios和android的原生app」
至於為什麼要造這個輪子,官方給了以下說法
1、今天在技術社區有大量的 web 開發者,Weex 可以賦能更多的 web 開發者構建高性能和高體驗的移動應用。
2、Web 開發本身具有非常強的高效率和靈活性,這和 Weex 想解決的移動端動態性問題不謀而合。3、Web 標準和開發體驗是很多頂尖而優秀的科技公司共同討論和建設的結果,本身的設計和理念都有極高的4、品質保障,同時 Weex 也希望可以藉此機會努力為標準貢獻一點自己的微薄之力。
5、Web 是一種標準化的技術,標準本身就是一種力量,基於標準、尊重標準、貼近標準都意味著擁有更多的可能性。6、Web 今天的生態和社區是非常繁榮的,有很多成熟的工具、庫、工程體系、最佳實踐可以使用、引入和借鑒。
在我看來,WEEX其實是alibaba團隊提高生產效率的產物,在淘寶這類要求多端統一迭代快速的部門,三端約定一種便於統一的規範,在加上時間的發酵,漸漸的就有了此類腳手架的雛形,同時在臉書ReactNative開源帶來的極大轟動後,自己也坐不住了吧^_^
好了,閑話就說到這,下面就來讓我們解剖一下WEEX的優劣良莠。
預科
入門Weex前需要了解一下知識,這樣能幫助你更快的掌握
Node:Node.js 教程Vue:《Vue.js官方教程》ES6:《ECMAScript 6 入門》再者就是ios和android開發語法的入門和編輯器的使用,當然環境
系統環境要求
IOS : MacOS, 黑蘋果
Android :MacOS, Linux, Windows
配置環境
你可以參考官方文檔安裝必須的依賴環境http://weex.apache.org/cn/guide/set-up-env.html,
也可以直接安裝以下環境- node
- npm
- weex-toolkit
- Xcode安裝Xcode IDE和Xcode的命令行工具(IOS開發依賴)
- Android Studio
下載必須的插件:
a) JDK1.8+b) Show Package Detailsc) Android SDK Build Tools d) Android Support Repository配置基礎環境:
a) ANDROID_HOME (如運行是遇到問題可參考此文http://www.jianshu.com/p/a77396301b22)
b) JAVA_HOMEHello Weex
官方文檔上的入門Hello world是web端的,緊接著介紹了如何集成 Weex 到已有應用
但是,身為一個web前端開發者,如果你不懂原生語音的話,介紹這些並不能起到很好的引導作用,因為web前端開發者都有一統前端界的野心(Web+Android+IOS),「寄人籬下」只能是暫時的。
所以快速創建並運行一個純Weex App才是有意義的事兒。
如果你在官方教程里沒有找到創建工程的教程,可以閱讀此文《WEEX快速創建工程 Hello World》
Vue Native
Weex在迭代的過程中選擇了於Vue2.0握手,因為該版本的Vue加入了 Virtual-DOM 和預編譯器的設計,使得該框架在運行時能夠脫離 HTML 和 CSS 解析,只依賴 JavaScript,如此,Vue在和WEEX合作後,便獲得了使用JS預編譯原生的組件UI的能力。
同React Native一樣,有人也將WEEX叫做Vue Native。
如果你對Vue還不了解,可以先學習【預科】部分推薦的《Vue.js官方教程》。
那麼接下來我們講講,Vue在WEEX中的不同
Vue在WEEX中的不同
雖說WEEX使用vue語言寫的,但畢竟是需要在不同平台間運行的,雖然大部分語法都有支持,但是依然有部分語法是不同的
語法差異
1、「html標籤」
目前 Weex 支持了基本的容器 (div)、文本 (text)、圖片 (image)、視頻 (video) 等組件,注意是組件,而不是標籤,雖然使用起來跟html標籤很像,至於其他標籤基本可以使用以上組件組合而成。
2、Weex 環境中沒有 DOM
因為Weex解析vue得到的並不是dom,而是原生布局樹
3、支持有限的事件
並不支持 Web 中所有的事件類型,詳情請參考《通用事件》
4、沒有BOM但可以調用原生API
在 Weex 中能夠調用移動設備原生 API,使用方法是通過註冊、調用模塊來實現。其中有一些模塊是 Weex 內置的,如 clipboard 、 navigator 、storage 等。
《clipboard 剪切板》 《navigator 導航控制》 《storage 本地存儲 》為了保持框架的通用性,Weex 內置的原生模塊有限,不過 Weex 提供了橫向擴展的能力,可以擴展原生模塊,具體的擴展方法請參考《iOS 擴展》 和《Android 擴展》。樣式差異
Weex 中的樣式是由原生渲染器解析的,出於性能和功能複雜度的考慮,Weex 對 CSS 的特性做了一些取捨
1、Weex 中只支持單個類名選擇器,不支持關係選擇器,也不支持屬性選擇器。2、組件級別的作用域,為了保持web和 Native 的一致性,需要<style scoped>寫法
3、支持了基本的盒模型和 flexbox 布局,詳情可參考Weex 通用樣式文檔。但是需要注意的是,- 不支持display: none;
- 樣式屬性暫不支持簡寫(提高解析效率)
- flex布局需要注意web的兼容性
- 不支持css動畫和3D樣式
Weex開發&調試
vue語法
舉個栗子,以下是嚴選App Demo首頁的簡化代碼
<template> <div class="wrapper"> <text class="iconfont"></text> <home-header></home-header> <scroller class="main-list" offset-accuracy="300px"> <refresher></refresher> <div class="cell-button" @click="jumpWeb("https://m.you.163.com")"> <yx-slider :imageList="YXBanners" ></yx-slider> </div> <div class="cell-button"> <block-1 :title="block1.title" :items="block1.items"></block-1> </div> </scroller> </div></template><style scoped> .iconfont { font-family:iconfont; } .main-list{ position: fixed; top: 168px; bottom: 90px; left: 0; right: 0; }</style><script> var navigator = weex.requireModule("navigator"); import util from "../../src/assets/util"; import Header from "../components/Header.vue"; import refresher from "../components/refresh.vue"; import YXSlider from "../components/YXSlider.vue"; import Block1 from "../components/Block1.vue"; export default { components: { "home-header": Header, "refresher": refresher, "yx-slider": YXSlider, "block-1": Block1 }, data () { return { YXBanners: [ { title: "", src: "http://doc.zwwill.com/yanxuan/imgs/banner-1.jpg"}, { title: "", src: "http://doc.zwwill.com/yanxuan/imgs/banner-2.jpg"}, { title: "", src: "http://doc.zwwill.com/yanxuan/imgs/banner-3.jpg"} ] } }, methods: { jumpWeb (_url) { const url = this.$getConfig().bundleUrl; navigator.push({ url: util.setBundleUrl(url, "page/web.js?weburl="+_url) , animated: "true" }); } } }</script>
如果以上代碼脫離工程單獨出現,基本上是無法得知他是weex工程。此處可切實感受到weex的web開發體驗
名存實亡的<標籤/>
<template> <div> <text v-for="(v, i) in list" class=「text」>{{v}}</text> <image stylex="" src=「"></image> <video class="video" :src="src" autoplay controls @start="onstart" @pause="onpause" @finish="onfinish" @fail="onfail"></video> </div></template>
weex工程中常用的標籤有<div/>,< text/>,< image/>,< video/>(組件另算),由此四種標籤基本可以滿足絕大多數場景的需求,雖說此標籤同web工程下的標籤用法一致,但此處的標籤已不再是我們前埠中常提的html標籤,而且名存實亡的weex標籤,確切講是weex組件。
通過weex-loader、vue-loader、weex-vue-render的解析最終轉換輸出的便是實際的組件,有此設計只是為了完成「web開發體驗」的目標。但是我們身為上層的開發人員要清楚自己每天「把玩」的到底是個什麼「鬼」。
閹割版CSS
其實用閹割版來形容 weex 的 css 支持度並不合適,但如果從「web開發體驗」的角度來衡量,那麼這個形容詞也是可以理解的。(此處對weex寄有厚望^_^)
單位
weex 中的所有 css 屬性值的單位均為 px,也可省略不寫,系統會默認為 px單位。
選擇器
Weex 中只支持單個類名選擇器,不支持關係選擇器,也不支持屬性選擇器。
/* 支持單個類名選擇器 */.one-class { font-size: 36px;}/* 不支持關係選擇器 */.parent > .child { padding-top: 10px;}/* 不支持屬性選擇器,不支持 `v-cloak` 指令 */[v-cloak] { color: #FF6600;}
這個只是對樣式定義的限制,不影響樣式類名的使用,在標籤中可以添加多個樣式類名,如:
<template> <div class="one two three"><div></template>
盒模型
weex支持css基本的盒模型結構,但需要注意的是
- box-sizing 屬性值默認為 border-box
- margin,padding,border等屬性暫不支持合併簡寫
FlexBox
weex中對flexbox布局支持度很高,但依然有部分屬性並不支持,如 align-items:baseline;、align-content:space-around;、align-self:wrap_reverse;等。
具體weex對flexbox的支持和布局演算法,可通過此文進行了解由FlexBox演算法強力驅動的Weex布局引擎,此處便不再贅述。
顯隱性
在 weex 的 ios 和 android 端,並不支持 display 屬性。
因此,不能使用 display:none; 來控制元素的顯隱性,因此vue語法中的 v-show 條件渲染是不生效的。
我們可以使用 v-if 代替,或者用 opacity:0; 來模擬。
需要注意的是,ios和android端並不能使用 opacity:0; 來完全模擬 visibility: hidden;,因為,當opacity的只小於等於0.01時,native控制項便會消失,佔位空間還在,但用戶無法進行交互操作,點擊時會發生點透效果。
CSS 3
Weex支持css3屬性,雖然支持並不夠,但相較RN的「不能用」已經是強大很多了。
以下幾種屬性我們在開發前需要知道她的支持度
- transform:目前只支持2D轉換
- transition:v0.16.0+的SDK版本支持css過度動畫,可根據情況配合內建組件 animation 實現動畫交互
- linear-gradient:目前只支持雙色漸變色
- font-family:weex 目前只支持ttf和woff字體格式的自定義字體
第三方工具庫
由於使用了增強版的webpak打包工具weexpack,支持第三方框架也是件自然而然的事情。
常用的有 vuex、vue-router 等,可根據項目實際情況引入需要的第三方工具庫
npm包管理
npm 包管理是前端開發朋友們再熟悉不過的包管理方式了。這也是為什麼ReactNative和Weex都選擇這種管理方式的原因。
以下是本工程的 package.json 文件,這裡就不做講解了,不熟悉的朋友點這裡->NPM 使用介紹
{ "name": "yanxuan-weex", "version": "1.0.0", "description": "a weex project", "main": "index.js", "scripts": { "build": "webpack", "build_plugin": "webpack --config ./tools/webpack.config.plugin.js --color", "dev": "weex-builder src dist -w", "serve": "webpack-dev-server --config webpack.dev.js -p --open" }, "keywords": ["weex"], "author": "zwwill", "license": "MIT", "dependencies": { "vue": "^2.4.2", "vue-router": "^2.7.0", "vuex": "^2.1.1", "vuex-router-sync": "^4.3.0", "weex-html5": "^0.4.1", "weex-vue-render": "^0.11.2" }, "devDependencies": { "babel-core": "^6.21.0", "babel-loader": "^6.2.4", "babel-plugin-add-module-exports": "^0.2.1", "babel-plugin-transform-runtime": "^6.9.0", "babel-preset-es2015": "^6.9.0", "babel-runtime": "^6.9.2", "css-loader": "^0.26.1", "history": "^4.7.2", "quick-local-ip": "^1.0.7", "vue-loader": "^13.0.4", "vue-template-compiler": "^2.4.2", "webpack": "^2.7.0", "webpack-dev-server": "^2.4.2", "weex-builder": "^0.2.7", "weex-loader": "^0.4.5", "weex-router": "0.0.1" }}
UI尺寸適配
Weex 容器默認的顯示寬度 (viewport) 是 750px,頁面中的所有組件都會以 750px 作為滿屏寬度。
這很像移動設備的邏輯像,比如iPhone 6的物理像素寬為750,邏輯像素
TypeiPhone 3GiPhone 4iPhone 6iPhone 6Plus物理像素320x480640x960750x11341080x1920邏輯像素320x480320x480375x667414x736像素比@1x@2x@2x@3x
類比在Weex中,如果所有的顯示寬度都是用默認值750,那麼顯示出來的實際像素信息為
TypeiPhone 3GiPhone 4iPhone 6iPhone 6Plus物理像素320x480640x960750x11341080x1920顯示像素750x1125750x1125750x1134750x1333像素比@0.427x@0.85x@1x@1.44x
所以我們在使用weex做UI適配時就沒有所謂的@2x圖和@3x圖,所有的尺寸都是Weex幫我們根據750作為基數寬做的縮放。
當然,Weex 提供了改變此顯示寬度的API,setViewport,通過此方法可以改變頁面的顯示寬度,可以實現每個頁面根據自己的需求改變基數邏輯尺寸
因此對於一些固定的icon,不建議使用普通的靜態圖片或者雪碧圖,這裡建議使用矢量的字體圖片,有以下優點:
- 適量圖不會變糊
- 使用方便,通過css的字型大小控制大小,不用適配機型和屏幕尺寸
- 引用ttf文件,體積小,且容易更新
本地調試
Weex的調試方式有多種,如果說RN的調試模式是解放了原生開發的調試,那麼weex的調試方式可以說是賦予了web模式調試原生應用的能力。
方法一
此方法多用於解決bug,檢測控制項的布局問題
# 調試單個頁面$ weex debug your_weex.vue# 調試整個工程$ weex debug your/path -e App.vue
執行調試命令後,會將指定的文件打包成 JSBundle,並啟動一個 weex Devtool 服務(http://localhost:8088可訪問,如下圖),同時將 JSBundle 文件傳遞至該服務跟路徑下的weex文件夾內(http://localhost:8088/weex/Ap...,實際是下圖右邊二維碼的的內容)。
http://192.168.31.6:8088/weex/App.js?_wx_tpl=http%3A%2F%2F192.168.31.6%3A8088%2Fweex%2FApp.js (二維碼自動識別)
使用Weex Playground App掃下左二維碼進入調試模,見下圖
再次掃碼右方二維碼,點擊【inspector】即可進入調試模式。
每一個控制項都是相同的數據結構
<view class="WXText" frame="{{0,0},{414,736}}" hidden="NO" alpha="1" opaque="YES"></view>
- class:代表原聲空間類型
- frame:表示空間的坐標和大小
- hidden:代表顯隱性,css中visibility設置的值
- alpha:不透明度,css中opacity設置的值
- opaque:默認為YES,打開繪圖系統性能優化的開關,即不去計算多透明塊重合後的真正顏色,從而減小GPU的壓力,weex中具體有沒有地方可以設置這個開關暫時不清楚,有獵奇心的朋友可以研究下。
方法二
此方法多用於開發調試,試試觀察結果
$ weex your_weex.vue
如果出現access許可權報錯,使用管理員指令
$ sudo weex your_weex.vue
http://192.168.31.6:8081/home.weex.js?hot-reload_controller=1&_wx_tpl=http://192.168.31.6:8081/home.weex.js (二維碼自動識別)
此時本地同時啟動一個watch的伺服器用於檢查代碼變更,自動重新構建JSBundle,視覺同步刷新。
上圖看到的效果即為H5頁面的效果,我們一般在整個單頁編寫完成後在使用 Weex Playground App 掃碼查看真機效果,或者你也可以在編寫的同時使用真機觀察代碼的運行效果,每次重新構建包到重繪的速度還是很快的。
但前提是你要保證,你的手機和電腦的連在同一個區域網下,並且使用IP訪問。
Weex的原理
雖然說,weex可以抹平三端開發的差異,但是知其然也應知其所以然使用起來才能遊刃有餘。
打包
熟悉RN的人都知道,RN的發布實際上就是發布一個JSBundle,Weex也是這樣,但不同的是,Weex將工程進行分包,發布多個JSBundle。因為weex是單頁獨立開發的,每個頁面都將通過weex打包器將vue/we頁面打包成一個單獨的JSBundle,這樣的好處在於減少單個bundle包的大小,使其變的足夠小巧輕量,提高增量更新的效率。
# 僅打包$ npm run build# 打包+構建$ weex build ios# 打包+構建+安裝執行$ weex run ios
以上三種均會觸發weex對工程進行打包。
在我們執行了以上打包命令後,所有的工程文件將被單獨打成一個獨立的JSBundle,如下:打包後的JSBundle有兩種格式
# 由.vue文件打包出來的包格式(簡寫),使用vue2.0語法編寫// { "framework": "Vue"} /******/ (function(modules) { ......./******/ })# 由.we文件打包出來的包格式(簡寫),使用weex語法編寫// { "framework": "Weex" }/******/ (function(modules) { ......./******/ })
不同的頭部是要告訴使用什麼語法解析此JSBundle。
至此,我們準備「熱更新的包」就已經準備完畢了,接下就是發包執行了。
發包
打包後的 JSBundle 一般發布到發包伺服器上,客戶端從伺服器更新包後即可在下次啟動執行新的版本,而無需重新下載 app,因為運行依賴的 WeexSDK 已經存在於客戶端了,除非新包依賴於新的 SDK,這也是熱更新的基本原理。
【WeexSDK】包括
- 【JS Framework】JSBundle 的執行環境
- 【JS-Native Bridge】中間件或者叫通訊橋樑,也叫【Weex Runtime】
- 【Native Render Engine】解析 js 端發出的指令做原生控制項布局渲染
執行
Weex 的 iOS 和 Android 客戶端的【JSFramework】中都會運行一個 JavaScript 引擎,來執行 JS bundle,同時向各端的渲染層發送規範化的指令,調度客戶端的渲染和其它各種能力。iOS 下選擇了 JavaScriptCore 內核,而在 Android 下選擇了 UC 提供的 v8 內核(RN兩端都是JavaScriptCore 內核)。
JSBundle被push到客戶端後就會在JSFramework中執行,最終輸出三端可讀性的VNode節點,數據結構簡化如下:
{ tag: "div", data: { staticStyle: { justifyContent: "center" } }, children: [{ tag: "text", data: { staticClass: "txt" }, context: { $options: { style: { freestyle: { textAlign: "center", fontSize: 200 } } } }, children: [{ tag: "", text: "文字" }] }]}
有了統一的VNode節點,各端即可根據自己的方法解析渲染原生UI了,之前的所有操作都是一致的,包括文件格式、打包編譯過程、模板指令、組件的生命周期、數據綁定等。
然而由於目標執行環境不同(瀏覽器和 Weex 容器),在渲染真實原生UI的時候調用的介面也不同。
此過程發生在【Weex SDK】的【Weex Runtime】中。
最總【Weex Runtime】發起渲染指令callNative({...})有RenderEngine完成渲染
總結一下
- weex文件分包打包成單個JSBundle文件
- 發布到發包伺服器上,通過熱更新push到用戶的客戶端,交由【Weex SDK】執行解析
- SDK中的【JS Framework】執行Bundle腳本生成Virtual DOM
- Virtual DOM經由各端執行環境【Weex Runtime】解析翻譯成執行指令
- 【Native RenderEngine】接收到指令後執行渲染操作,作出渲染出完整的界面
官方配圖:
擴充配圖:
Weex 的工作模式
1. 全頁模式
目前支持單頁使用或整個App使用Weex開發(還不完善,需要開發Router和生命周期管理)。
本文先行的嚴選demo便是使用第二種全屏模式,使用Weex開發整個App,期間觸碰到Weex的在此模式下諸多不足,如StatusBar控制、Tab切換、開場動畫自定義、3DTouch、 Widget等等原生的特色功能沒有現成的API,需要我們自己擴展,甚至擴展不了。因此並不能完全「滅掉」原生。
所以,目前在阿里內部使用較多的是此模式中的單頁模式,這也是為什麼官方文檔在介紹原理後就直接奔入集成到原生應用的主題上去了。
2. Native Component模式
把Weex當作一個iOS/Android組件來使用,類比ImageView。這類需求遍布手淘主鏈路,如首頁、主搜結果、交易組件化等,這類Native頁面主體已經很穩定,但是局部動態化需求旺盛導致頻繁發版,解決這類問題也是Weex的重點。
3. H5 Component模式
在H5種使用Weex,類比WVC。一些較複雜或特殊的H5頁面短期內無法完全轉為Weex全頁模式(或RN),比如互動類頁面、一些複雜頻道頁等。這個痛點的解決辦法是:在現有的H5頁面上做微調,引入Native解決長列表內存暴增、滾動不流暢、動畫/手勢體驗差等問題。
另外,WVC將會融入到Weex中,成為Weex的H5 Components模式。
嚴選 App Demo 實現過程中的感想
Vue-Router & Tab
由於Weex沒有封裝Tab的組件,因此筆者使用了很多方法來實現Tab切換的功能。
1、vue-router:router思想方便管理,但是每次切換都是新的實例,沒有tab模式
2、opacity、visablity:此處需要注意,Weex的渲染機制和web是有區別的,對夫層設置opacity或者visiablity隱藏是無法同時隱藏定位為position:fixed; 的子元素。3、position、transform:改變tab層的位置,此方法在定位為position:fixed; 的子元素上依然無效。image & iconfont
Weex中所有的靜態資源基本都是網路資源,包括圖片、字體圖片等,所以使用iconfont圖標是再合適不過的了。
此demo中所有的icon均使用的iconfont。
此處強烈推薦一個站點www.iconfont.cn。
在此平台你可以找到幾乎所有你需要的icon,你也可以上傳自己的icon到自己創建的項目中。同時該系統還提供生成ttf、woff資源,並且做了cdn加速和gzip壓縮,是不是跟weex很配呢?
不過也有風險,就是,如果哪天阿里不在維護並回收該平台的資源了,你的app可能就會變成這樣,全是方框,或者padding掉你H5的頁面
當然,這種及情況出現的幾率很小,如果你是一個大公司,你手上有更好的資源急速方案,那就自己保存吧。
webview
UIWebView是我們開發App常用的一個控制項,不過Weex幫我們封裝好的API明顯時不夠用的,目前只有pagestart 、pagefinish、error ,並沒有封裝像RN那樣的onShouldStartLoadWithRequest攔截地址請求的API,在我看來,這有些不合理,並不清楚輪子的製造者是什麼意圖。
性能
性能是一個大課題,在此就不做展開了,只稍微提及一些我們開發需要注意的幾點
- 性能影響點:UI更新>UI事件響應>後台運算
- 合理優化過場&動畫,過場和 console 容易引起 app crash 需要注意
- 降低 js <-> native 的通信頻率
- 優化list結構,降低重排重繪壓力
- 把優先順序低且耗時較長的工作推後處理
Weex的現狀
Weex解決了的
我的發布我做主(熱更新)
腳本語言天生自帶「熱更新」,Weex針對RN的熱更新策略做了優化,將WeexSDK事先綁到了客戶端上,並且對JSBundle進行分包增量更新,大大提高了熱更新的效率。
但優點也是缺點,如果新包依賴於心的SDK,此情況下,我們需要發布還有新SDK的app到應用市場,用戶也須從市場更新此app。不夠隨著WeexSDK版本的穩定後,相信此策略的優勢就會凸顯出來。
性能問題
Weex是一種輕量級、可擴展、高性能框架。集成也很方便,可以直接在HTML5頁面嵌入,也可嵌在原生UI中。由於和ReactNative一樣,都會調用Native端的原生控制項,所以在性能上比Hybrid高出一個層次。
統一三端
雖說這是一個大膽的實踐,但對於大前端社區的統一有著推動作用,顯然阿里在這一方面已經邁出了第一步。基本解決了三端同等需求導致資源浪費的痛點。
但後期可能會出現這種現象,開發一個三端的App會從原來的個人變成四個人,多出來的那一個人負責開發Weex單頁。
意思就是,三端統一的不夠徹底,但就目前的環境下,這一句是最優方案了,卻是提高了開發效率。大前端將來將如何一統三國我們且行且觀望吧。
做遊戲
對於一些交互視覺統一且沒有很大的性能需求的遊戲,Weex還是可以勝任的。
近期筆者將嘗試發布一款純Weex構建的益智小遊戲,敬請期待。
朋友們可以用這個demo體驗下Weex 版掃雷遊戲開發
Weex 「暫時」放棄的
雖然說大一統事件百利的事,但並非無一害。
差異化
對於一些有差異化完美體驗追求的項目就只能收斂或者放棄了。
獨立的bug修復
對於三端同時上線,一端存在bug的情況,Weex並不能保證做到牽一髮而不動全身。
個性化功能
比如安卓的波紋按鈕、3DTouch、 Widget、iWatch版本等,目前這些功能還是沒有的,不知道以後Weex是否將其加入到官方文檔中。
聲明
以上均為個人見解,不代表官方。如有不當之處還望指正。
參考
[ 1 ] Weex官方文檔 - http://weex.apache.org/cn/references/
[ 2 ] 場景研讀 - Native 性能穩定性極致優化 - https://yq.aliyun.com/articles/69005[ 3 ] 門柳 - 詳解 Weex JS Framework 的編譯過程 - https://yq.aliyun.com/articles/59935?spm=5176.8067842.tagmain.66.1QA1fL[ 4 ] 阿里百川 - 深度揭秘阿里移動端高性能動態化方案Weex - https://segmentfault.com/a/1190000005031818[ 5 ] 一縷殤流化隱半邊冰霜 - Weex 是如何在 iOS 客戶端上跑起來的 - http://www.jianshu.com/p/41cde2c62b81推薦閱讀: