整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
eex對顏色和長度單位支持情況和標準CSS不同，如果程序中使用了weex程序不支持的樣式單位，程序運行會出現異常，頁面無法正常渲染。
weex demo page
weex支持的樣式單位具體如下：
支持以下寫法：
.classA {
/* 3-chars hex */
color: #0f0;
/* 6-chars hex */
color: #00ff00;
/* rgb */
color: rgb(255, 0, 0);
/* rgba */
color: rgba(255, 0, 0, 0.5);
/* transparent */
color: transparent;
/* Basic color keywords */
color: orange;
/* Extended color keywords */
color: darkgray;
}
注意：不支持 hsl(), hsla(), currentColor
6-chars hex是性能最好的顏色使用方式。除非有特殊原因，請使用6-chars hex格式。
在 Weex 中，我們只支持 px 長度單位。
.classA {
font-size: 48px;
line-height: 64px;
}
不支持類似 em，rem，pt 這樣的 CSS 標準中的其他長度單位，百分比目前也不支持。
number可用于以下CSS屬性：
期H5和Hybrid方案的本質是，利用客戶端App的內置瀏覽器（也就是webview）功能，通過開發前端的H5頁面滿足跨平臺需求。比如PhoneGap cordova ionic ……
該方案提升開發效率，同時也滿足了跨端的需求。但有一個問題就是，前端H5的性能和客戶端的性能相差甚遠。Facebook 推出ReactNative
關于RN，安利下《ReactJS到React-Native，架構原理概述》
Weex與ReactNative 都是基于Yogo渲染骨架做的 跨端框架，一個基于React，一個基于Vue，個人偏好RN，但是Weex 貌似更香。
相對于ReactNative的“learn once write anywhere”，weex的: “write once run anywhere”，牛皮更寬廣
關于Weex的使用，還是看官方文檔好：https://weex.apache.org/zh/guide/introduction.html
Weex的源文件(最新的Weex版本支持的是Vue文件)，如果想用React， 也可以用Rax(兼容React接口), 甚至如果可能，可以支持更多的前端框架。因為根據Weex設計前端框架僅僅是語法層(或者叫DSL)， 它與原生渲染引擎是分離的。當然自己擴展支持另一套前端框架也比較麻煩，需要做不少工作。
在初始化階段, WEEX SDK 會準備好一個js的執行環境。因為我們是要在客戶端跑js 代碼的，所以需要一個js執行環境，這個執行環境類似于瀏覽器的v8 引擎， 在IOS 上，則是客戶端自帶的 js core。
這個js執行環境，可以看成是一個在客戶端上的沙盒，或者是一個虛擬機。
為了提升性能，js 執行環境只用在初始化的時候初始化一次，之后每個頁面都無須再初始化了。也就是說不管客戶端打開多少個weex頁面，多個頁面的 JS 都是跑在同一個js執行環境中的。
weex-vue-framework 框架 是什么呢？
你可以把 weex-vue-framework 框架當成被改造的Vue.js。語法和內部機制都是一樣的，只不過Vue.js最終創建的是 DOM 元素，而weex-vue-framework則是向原生端發送渲染指令，最終渲染生成的是原生組件。
同時，Weex為了提高Native的極致性能，做了很多優化的工作。前端優化性能時，會把業務代碼和 vue.js 這類的依賴包分開打包，一個份是業務代碼，一份是打包的框架依賴。
weex 把weex-vue-framework 這類框架依賴內置到了SDK中，客戶端訪問Weex頁面時，只會網絡請求JS Bundle。由于JSFramework在本地，所以就減少了JS Bundle的體積，每個JS Bundle都可以減少一部分體積，從而提升了性能。
WXBridge 是 weex 實現的一種 js 和 客戶端通信的機制。
js 執行環境和客戶端是隔離的，為了和外界客戶端的世界通信，需要有一個通信的橋梁。weex 實現了 WXBrigde, 主要通過 callJS 和 callNative 兩個核心的方法，實現 js 代碼和客戶端代碼雙向通信。
在完成了上面的初始化之后，weex已經做好了準備，只等著下載 JS bundle 就可開始渲染頁面了。
weex 能讓一套代碼能做成 native 級別的app，主要是做了三件事：
整體工作可以分為三個部分
1、轉換 <template> 為 類JSON的樹狀數據結構, 轉換數據綁定 為 返回數據的函數原型。#####
<foo a="{{x}}" b="1" /> --> {type: "foo", attr: {a: function () {return this.x}, b: 1}}.2、轉換 <style> 為 類JSON的樹狀數據結構。
.classname {name: value;} --> { classname : { name : value } }.3、 把上面兩部分的內容和 <script> 中的內容結合成一個JavaScript AMD（AMD：異步模塊規范） 模塊。#####
<template>
<foo a="{{x}}" b="1" class="bar"></foo>
</template>
<style>
.bar {width: 200; height: 200}
</style>
<script>
module.exports={
data: function () {
return {x: 100}
}
}
</script>將轉換為:
define('@weex-component/main', function () {
module.exports={
data: function () {
return {x: 100}
}
}
module.template={
type: "foo",
attr: {
a: function () {return this.x},
b: 1,
classname: ['bar']
}
}
module.style={
bar: {width: 200, height: 200}
}
})
bootstrap('@weex-component/main')說明1：除此之外,轉換器還會做一些額外的事情: 合并Bundle ,添加引導函數，配置外部數據等等。
說明2：案例來自Weex的官方文檔。當前大部分Weex工具最終輸出的JS Bundle格式都經過了Webpack的二次處理，所以你實際使用工具輸出的JS Bundle會和上面的有所區別。
實際上當WEEX SDK獲取到JS Bundle后，第一時間并不是立馬渲染頁面，而是先創建WEEX的實例。
每一個JS bundle對應一個實例，同時每一個實例都有一個instance id。
我們上文中說過，由于所有的js bundle都是放入到同一個JS執行引擎中執行，那么當js執行引擎通過WXBridge將相關渲染指令傳出的時候，需要通過instance id才能知道該指定要傳遞給哪個weex實例
在創建實例完成后，接下來才是真正將js bundle交給js執行引擎執行。
在實例創建完成后，接下來就是執行JS bundle 了。JS bundle 的結果是生成Virtual DOM ，然后去patch 新舊 Vnode 樹，根據diff 算法找出最佳的DOM操作，唯一和瀏覽器不同的是，調用的是 Native app api ，而不是瀏覽器里面對DOM節點增刪改查的操作。
Weex 的渲染流程如下圖：
Virtual DOM ->
-> Build Tree -> Apply Style -> Create View -> Update Frame -> Attach Event ->CSS Layout ->Update Frame
->Native/H5 View
輸入：虛擬DOM
輸出：Native UI 頁面
參考文章：
Weex 2：淺說Weex工作原理 https://www.jianshu.com/p/32285c709682
深入理解weex內核原理 https://zhuanlan.zhihu.com/p/71064826
轉載本站文章《Weex原理及架構剖析》,
請注明出處：https://www.zhoulujun.cn/html/webfront/AppDev/Weex/8495.html
文從內核角度切入，為大家帶來Weex技術演進之路的分享。
隨著Weex業務規模的擴大和業務覆蓋場景的豐富，Weex 不僅在性能穩定性上面臨越來越大的挑戰，在安全隔離方面，也遇到前所未有的風險。
性能方面：例如，去年的“雙11”和今年“雙11”主會場規模對比，去年整個會場的JS Bundle大小控制在250K以內，今年主會場頁面平均達到500K+，業務復雜度增加了接近2倍，Weex 的加載性能跟JS bundle 的大小基本成正相關；
穩定性方面：業務場景覆蓋面的提升，從原來的偏展示的場景到偏交互場景的業務，以及一些常規業務的接入；新的業務場景，必然導致新的穩定性方面的挑戰，事實也如此；
富交互：引入Gcanvas、AR/VR等富交互場景，對Weex js-native的通信效率要求極高；
安全性：舊引擎的安全漏洞的問題，以及業務之間存在相互污染，無法做到安全隔離的問題；
證書問題：Yoga引擎的證書授權問題；
從三個方面來闡述Weex 在內核重要方向的演進：JS引擎、Layout 引擎、WeexCore架構的演進；
JS引擎: 我們的目標是更快、更穩定、更安全、更??；其一：我們投入大量資源在JS引擎的優化上，從JS引擎的替換，由原來舊版本的V8 換成最新版本JavaScriptCore；其二：我們開創性地將JS Runtime 運行于獨立的進程里，不僅保證主進程的穩定性，而且加入了智能恢復的能力；其三：重新考慮Weex 業務隔離的安全問題，開發設計了多Context 隔離的方案，保證避免業務間互相污染；其四：瘦身，包的精簡；
Layout引擎：Weex項目成立以來，我們一直借用的Facebook的Yoga項目作為我們的布局引擎，但是Layout引擎對于Weex 項目又是如此重要，所以，我們今年10月份開始計劃開發全新的Layout引擎開發的項目，來替換yoga引擎。第一，Layout 引擎作為核心模塊，我們希望去主導演進的路線； 第二，Facebook的證書風險不能回避；所以我們決定重新開發自己的Layout 引擎，并爭取做到更高性能，支持更多布局方式；
WeexCore架構：今年我們討論最多的就是Weex 后續如何演進，在性能穩定性方面如何做的更優，在復雜業務的支持方面如何做的更好。WeexCore 首先是高性能的，用以滿足更復雜場景業務開發，以及提升業務開發體驗；其次是一個跨平臺的內核，從DSL的跨平臺到內核的跨平臺。
JS引擎技術
眾所周知，JS 引擎至于Weex至關重要，是Weex 最重要的一個核心模塊，2017年，我們在JS 引擎的投入也是非常大：
2017-3月～2017-7月：對最新版本的V8和最新版本的JavaScriptCore 做來全面的profile，讓profile數據告訴我們去選擇哪個引擎作為Weex新一代的JS 引擎。經過4個月的努力，終于將最新版本的JavaScriptCore 在手機淘寶正式版本上線，同時Weex也是第一個將JavaScriptCore引擎（javascriptcore引擎apple維護的，很少在android平臺商業化過）集成到手機淘寶這樣體量的App中，中間遇到的兼容性的問題也是我們最大的挑戰。最終性能提升還是比較明顯的，手淘上Weex整體業務首屏加載時間提高了40%+，并全面支持ES6特性；
2017-7月～2017-10月：新版本的JavaScriptCore 上線以后，Weex的穩定性native crash 占比5%左右，按照手淘的穩定性要求(<1%)還是有比較大的差距，這個將是我們2017年雙十一前最大的挑戰。當時Weex穩定性小組的同學出于焦慮中，隨著雙十一臨近，不斷有新Weex 業務上線，伴隨著冒出一些的兼容性的問題出來，始終看不到收斂的趨勢。一方面，我們正向地去解決這些適配的問題，另一方面，我們也討論如何徹底地解決JS引擎的穩定性的問題；后來，我們想到將JS 引擎獨立運行到單獨的進程里去，這個方案帶來最大的好處，就是Weex 業務的crash 不會影響主程序的穩定性；這個方案也成了雙十一Weex穩定性保障的救命稻草。最終這個方案在10月份前正式上線，效果非常明顯，Weex 引起的native crash占比一下子從5%下降到0.5%左右。
2017~11月～至今：雙十一之后，JS 引擎項目主要在做兩個事情，一個Weex安全隔離方案，另一個是包精簡優化方案；Weex安全隔離方案主要解決頁面隔離的問題，雙十一當天也遇到一個非常嚴重的全局污染的案例，某個業務不小心污染了全局對象，導致所有的Rax的頁面出現白屏的問題；針對這些案例，我們重新設計了Weex 安全隔離的方案，目前安全隔離方案已經內部灰度中，預計2月份正式社區發布；
包精簡優化方案：主要解決Weex sdk集成了最新版本的JavaScriptCore以后，包大小增大一倍的問題（4.2M左右）,包的增大直接增大了App接入的門檻，特別是對包大小非常敏感的App。目前同步一下信息：精簡優化方案目前也基本開發完畢，預計可以減少到2.6M左右，預計也是2月份上線；
獨立進程化
問題
同一個進程中，與主App存在資源競爭，尤其是內存問題比較突出，JavaScriptCore雖然執行性能提升了，但對內存的消耗也同時增大不少，所以替換成JSC以后，Weex的內存問題導致Crash也明顯上升；
獨立進程的方案本身比較Hack，再加上Android生態的碎片化，開發過程中也遇到很多適配問題，比如在某些機型上獨立進程拉不起來，導致業務渲染失??；
JavaScriptCoe引擎本身對android平臺適配比較差，沒有比較大體量的App在線上應用過；
優勢
進程獨立以后，完全和主App的進程隔離，避免了進程資源競爭導致crash的問題，Weex的crash也不會引起主進程的crash；
Weex 原有的三個線程架構，JS 線程任務被并行成兩個，JS獨立的進程和原來JS線程，整體增強了JS任務執行的并發性，抵消了方案本身的IPC通信的性能損耗；
獨立進程后，我們加入了自修復的能力，增強了JS Runtime進程的自動重置功能，解決JS Runtime 異常后的無法自動恢復的問題，極大地保障業務的穩定性；
SandBox機制
Weex 原有的設計，所有Weex頁面包括JSFrameWork 都是運行在同一個JS Context里，并在JS層面，對全局的JS 變量做了freeze操作，防止被其他業務頁面污染。這個設計主要還是出于高性能和安全性的綜合考量。
2017年雙十一出現的全局污染的問題，讓我們重新思考Weex Context的安全隔離的方案，安全穩定高于一切。經過新的討論后，我們決定針對每個Weex頁面都創建一個JS Context 作為獨立的運行環境，頁面依賴的全局對象由Global Contex統一生層并傳遞給每個頁面的Contex；傳輸的過程，我們做了兩個非常重要的操作：
1)對傳輸的對象做freeze操作；
2)在javaScript引擎層面，通過native的SetPrototype接口切斷原型鏈的關系；這樣就徹底解決了頁面間互相污染的問題。該方案預計2月份正式上線。
Layout 引擎
全新的Layout引擎參考了 Google的FlexLayout的算法流程，重新實現了Weex的 Flex布局，目前性能和功能方面基本和yoga保持一致，后續會做一些性能優化。至于未來如何演進，團隊同學討論幾個關鍵的步驟：
自主開發全新的高性能的跨平臺Layout引擎，統一由C++實現，IOS／android 兩端復用同一套代碼；
擴展更多的布局方式，比如Gird布局、Absolute布局等
編譯器或服務端做預布局，提升端測的布局效率等；
該方案預計2月份正式上線。
Weex 作為一個跨平臺的開發框架，在Android/ IOS/HTML 三端實現跨平臺一致性非常重要。目前Weex 核心渲染流程分平臺實現，不僅多人維護導致不可避免的邏輯實現差異，而且對于后續新平臺擴展成本也非常高(核心渲染流程需要重新實現)。因此，想到抽象統一Weex 核心解析渲染流程，通過C + + 語言實現，實現 ios、android 平臺核心邏輯統一，不僅可以增強平臺間的一致性，降低維護成本，以及擴展平臺的成本。通過C+ +代碼執行效率要高于JAVA，同時還可提高Android端的代碼執行性能。
提供標準的Weex Dom API Layer，簡化DSL的接入成本，將大部分JSFramework native化；
抽象Weex平臺無關的、核心的處理邏輯，android和IOS的porting層盡量做薄，一方面提高代碼的復用率，另一方面降低新平臺的擴展成本；
架構設計上的高可用，通用的模塊可插拔，例如JS engine 模塊和Layout engine模塊能低成本地切換；
核心技術模塊比如JS engine 等能標準化輸出，服務更多的業務場景；
（本文作者飲源，阿里巴巴技術專家）
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
