自打出生的那一天起,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原始碼地址:
github.com/zwwill/yanx…
感謝【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
配置環境
你可以參考官方文件安裝必須的依賴環境weex.apache.org/cn/guide/se…,
也可以直接安裝以下環境
- node
- npm
- weex-toolkit
- Xcode
安裝Xcode IDE和Xcode的命令列工具(IOS開發依賴) - Android Studio
下載必須的外掛:
a) JDK1.8+
b) Show Package Details
c) Android SDK Build Tools
d) Android Support Repository
配置基礎環境:
a) ANDROID_HOME (如執行是遇到問題可參考此文www.jianshu.com/p/a77396301…)
b) JAVA_HOME
Hello 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 style="" 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,邏輯畫素
Type | iPhone 3G | iPhone 4 | iPhone 6 | iPhone 6Plus |
---|---|---|---|---|
物理畫素 | 320×480 | 640×960 | 750×1134 | 1080×1920 |
邏輯畫素 | 320×480 | 320×480 | 375×667 | 414×736 |
畫素比 | @1x | @2x | @2x | @3x |
類比在Weex中,如果所有的顯示寬度都是用預設值750,那麼顯示出來的實際畫素資訊為
Type | iPhone 3G | iPhone 4 | iPhone 6 | iPhone 6Plus |
---|---|---|---|---|
物理畫素 | 320×480 | 640×960 | 750×1134 | 1080×1920 |
顯示畫素 | 750×1125 | 750×1125 | 750×1134 | 750×1333 |
畫素比 | @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/App.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
複製程式碼
此時本地同時啟動一個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官方文件 – weex.apache.org/cn/referenc…
[ 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