2016iweb峯會參會總結

時間 2019-11-08

標籤 2016iweb iweb 峯會總結欄目程序員峯會简体版

原文原文鏈接

2016年8月27日去國家會議中心參加iweb峯會。
8點半開始簽到入場，8點20分排隊簽到的人已經排到另外一個門口，人超級多啊。
9點一如既往的由h5女神娜姐開場。css

上午場

基本是各公司的大佬們介紹各公司產品，回收往事如何抓住機遇，如何賺的人生第一桶金，如何規避風險等。宣傳性質居多。html

首先是蝴蝶互動ceo 凌海，《HTML5發行的力量》

表明遊戲 傳奇世界 千年
身爲一個程序媛妹子，我基本上是不怎麼玩遊戲的，對遊戲的理解也限於日常身邊男同事的聊天中，對遊戲很少說。
印象最深的是凌海說的如何規避風險，如何作時間管理，舉例說明了有投資方要求360出3年規劃，3年對互聯網來講時間太長了，3年可能發生不少事，風險是沒法預知的；列舉本身針對一個須要90天的項目，他們公司每每是比較慎重的，他們會把時間細化到30分鐘，相比90天或者3年30分鐘的風險是基本能夠徹底把控的。

白鷺時代CEo 陳書藝《2016:完成生態閉環，向全行業致敬》

一個領先的html5移動技術與服務提供商，erget開放平臺，出款多個遊戲，什麼暗黑之王，亂彈三國，稀有神傳，小小戰爭，三國魂等，支持多種動畫解決方案，平滑動畫，可視化代碼，專業遊戲引擎。
h5遊戲行業有機遇也有挑戰，性能的大幅提高和微信帶來的流量都是h5遊戲行業的機遇（流量變現等）

觸控科技副總裁王哲《天下武功，惟快不破》

他從h5遊戲的性能方面作了分析，對於h5的將來，他報以謹慎樂觀的態度
分析了h5遊戲的性能方面
1. webGL性能提升 5~10倍 
2. Canvas 髒矩形算法 性能提升2倍
3. 內存佔用下降5%
4. 包體減少30%
5.

很快ceo 李明《社交生態下的HTML5遊戲辛新契機》。

「很快」鼓勵開發者將技術轉化爲流量，並現場宣佈，和9g合做，啓動了億元流量計劃，爲開發者提供流量

WeX5 CEO 馬科《HTML5和Docker容器如何重構和顛覆應用產業》

首先這位被娜姐介紹說是「90後」ceo，引發現場一片轟動，90後出道的~ 哈哈
從互聯網的擴大入口：h5會致使病毒式傳播，造成閉環，不像傳統app的場景分割。還有云計算即將來和對新技術的思考：要從應用場景切入，而不是重複造輪子。
對比了優秀app和傳統app的區別， devops區別，這位乾貨不少

英特爾 web技術研發總監江小丹《web技術：一個挑戰極限的創新平臺》

提到了web前沿技術：web assembly nodejs 還有Intel在虛擬現實的技術嘗試和酷炫的體驗前端

野狗實時聯合創始人肖光宇《web 前端的是實時化》

野狗是國內領先的實時後端雲;
野狗api--最實時通訊api來了，應用於各大場景，可實時同步數據，網頁通訊，實時遊戲，運用於汽車，實現實時同步汽車數據等
使用野狗API,能夠得到實時後端雲的兩大功能
1. 實時通訊 ，包括消息訂閱，推送，雙向通訊等功能。網絡延遲小，服務響應速度快，API簡單易用。
2.數據存儲，提供了一個Key-Value的雲端數據存儲，直接經過API就能夠對數據進行存取操做。操做簡單，按需擴展。

Dcloud CEO 王安《移動互聯網下半場-不用好HTML5，大部分公司都會死》

互聯網下半場，原生應用成本高，留存率低等問題已經顯現。如何用HTML5解決這個問題呢？他提供的答案就是流應用啦~

LayaBox的CEO謝成鴻《H5遊戲進入精品時代》

這個比較接地氣，說什麼目的都是能掙錢，第一桶金開發一款小遊戲賺到一點小錢650萬
LayaBox闡述了將來遊戲市場將呈現頁遊、手遊、HTML5多端融合的趨勢，強調了HTML5技術跨端、多屏、免下載等特色給遊戲行業帶來的革新性變化。在LayaBox看來，HTML5遊戲是遊戲市場上一課冉冉升起的新星，即將迎來爆發。同時，LayaBox也詳細介紹了旗下第二代HTML5遊戲引擎LayaAir，其支持Flash頁遊、APP手遊、HTML5遊戲 三端同發的特色和超越Unity3D的性能贏得了現場陣陣掌聲。目前，LayaBox業務涵蓋了引擎提供、遊戲發行、遊戲渠道、IP合做、項目投資、教育培訓6大板塊，是一家綜合性的遊戲服務企業。

下午場（由於去的人太多了，工具一專場爆滿，下午場一直在工具一）

《高性能HTML5 APP 開發雲實踐——基於徹底開源的WeX5開發框架》王潔 Wex5

主要對原生APP和hybrid app的比較，簡述爲解決白頁多webview 實現轉場動畫等， 複雜效果native 實現，簡單效果h5實現「重混」 - wex5 「輕混」，只需前端調用，提供打包平臺
WeX5的可視化操做，同咱們公司Hy框架比較來講，wex5基於phonegap 源碼改造，組價可拖拽組成頁面，HY是本身實現的一套，組件開發參考phonegap
wex5，一個純h5app開放平臺，組件風格分離，基於css3，引入bootstrp資源，可快速開發。一次開發，全面擁有安卓app，蘋果app，微信服務號。真正的html5 app開發雲。

Hybrid App走向「輕混」，剖析WeX5開源高性能HTML5 App開發框架

由於去年參加完D2大會後，我在公司內部作過一次Hybird的分享，主要對百度BlendUI和其餘框架對比展開，當時雖然查了不少資料，單因爲實際使用很少，對hybird只知其一;不知其二，分享效果很不理想，我亦耿耿於懷很多天，可是當時的辛苦沒有白費，昨天再聽到wex5 王潔講述Hybird的時候，易於接受不少~ 因此啊，別因你當下的努力沒有效果就懊惱~ 因爲本人演講時易緊張，不善措辭，想用本身的話把wex5解釋明白有點困難，遂轉載以下文章，供我的參考學習 [http://www.weixinla.com/document/22647975.html]html5

一. Hybrid App從「重混」到「輕混」的技術發展歷程

基本上從早期的多元化走向了只有Android和iOS兩個系統的環境。對於開發者來講，就意味着一個App須要制定兩套實現方案，這對開發成本和維護成本都是很是大的挑戰。基於這樣一個現實，其解決方案就是想辦法實現套代碼跨端運行，因此Hybrid APP混合應用模式應運而生

在Hybrid APP發展早期，Web運行性能是當時的主要的瓶頸。Web在性能方面有缺陷，Web不夠就用Native來湊，就是選擇了用原生技術來彌補Web上的性能不足，其實就是多WebView。混合的單WebView最大的障礙就是頁面切換，閃白很明顯。手機裏面又講究用戶交互體驗，從一個頁到另外一個頁想作個平滑的動畫，用純Web技術在當時的條件下是很是難以實現的，其實目前大多數框架也是這麼作的，就是採用多WebView，這樣能夠平滑的轉場。

由於早期硬件比較差，瀏覽器性能也通常般，因此有一些比較複雜的組件在實現一些功能的時候，速度比較慢。當時框架裏是用NativeUI組件來彌補的，配合Web來實現這些功能。這種模式被定義爲「重混」，用原生的能力去彌補UI，或者技術更偏Native的框架就被定義爲重混的Hybrid App框架。
重混框架優缺點很明顯，優勢是提高了運行性能、加強了交互。缺點是Web和Native技術交叉混雜，增長了開發人員的工做難度。可是，當下的手機硬件配置已經有了很大的改善，包括瀏覽器技術的發展也很重要，在GS引擎方面都有長足的進步。實現功能的時候用Web的技術的前提下已經再也不須要Native技術來彌補了，隨着技術的發展，性能已經再也不是瓶頸。

另外一個改變了移動應用這一領域的進程事件是，自從微信推出之後，至關於從新定義了移動應用的概念，經過它的服務號、公衆號、企業號，微信自己變成了一種應用平臺。包括微信最新的版本更新，它瀏覽器內核的升級，包括對遊戲的支持，都和大量的移動App開發有着莫大的關聯。而這個時候重混的框架就顯得多餘了，由於在重混框架裏面不少性能的解決是依賴Native的原生部分。而到了微信裏面，多WebView和NativeUI都沒有了。原來在重混框架裏面很強的一些能力徹底就消失了，這時候在微信裏面就有不少能力就不能用了。

因而輕混就成了目前真正要跨端Hybrid App的必然選擇，這時候輕混的UI部分必須用純Web技術，在底層的設備接口上，GS沒法完成的原生部分須要Native技術來彌補。須要強調的是，Native的技術是不該該去侵入UI的，這樣的一個框架就是咱們所說的輕混Hybrid App框架，這纔是真正的HTML5 App框架。
![](media/14723796454471/14723805778403.jpg)

二.構建高性能HTML5 App跨端框架

伴隨着以上的觀點，接下來談談如何構建輕混模式下的HTML5 App框架。這種混合框架很簡單，首先要有一個內置了瀏覽器的外殼，在瀏覽器裏提供網頁運行環境，同時在這個外殼上提供不少插件，可讓網絡經過GS進行操做。
基於這樣的認識，王潔說，在選擇HTML5框架設計的時候，要解決兩個框架的問題，一個是HTML5的框架，一個是Native的框架。首先看Native框架的選擇，選擇PhoneGap框架，受到了業內主流廠商支持，微軟也是用Cordova，它的插件框架是開放的，很容易自定義。
另外就是要解決HTML5的一些性能問題，若是不採用重混架構的話，在頁面切換仍是會有一些障礙，王潔說到，WeX5採用SPA單頁應用模式，它是基於傳統的頁面加載模式MPA，頁面之間互相獨立。可是SPA的不一樣之處在於，其框架裏整個頁面是由外殼頁面框架組成的，是用AJAX技術完成的，AJAX在桌面時代就存在，經過局部刷新來提高用戶體驗。可是把AJAX技術最大化來使用，整個頁面框架都用AJAX來實現，每一個頁面的加載都是這樣的方式。

對設備的局部渲染，能夠在加載的時候在後面預加載再作轉場動畫，並且還不須要依賴多Web應用，不須要依賴Native就能夠完成。並且在加載多頁框架時每一個頁面的共用功能要重複加載。因此從各方面來講SPA相對於MPA是有極大的性能提高的。
SPA確實很好用，可是在設計產品的時候須要考慮到多人協做過程當中，支持複雜應用的開發過程當中，會不會出現多個ID會衝突，樣式衝突，JS衝突等等致命問題？因此下面就談到了頁面隔離的問題。

解決這樣棘手的問題，王潔說，首先要考慮到HTML元素ID衝突的問題，由於是可視化工具，因此ID屬性的設計是拖到一個屬性欄裏去定義ID，這時候恰好能夠用一個替換原則，用了XID來替換，不會直接設定ID屬性。這樣到內存裏，會動態的生成真實的ID，會在XID後面加一個頁面標誌，這樣能夠保證多人寫的頁面在加載內存裏ID是不相同的，也就不存在衝突。固然提供一些API的時候是能拿到真實ID，對應相應的元素，不影響訪問。在整個組件體系裏，開發者利用很簡單的方法就能夠拿到組件，能夠很平滑的解決掉ID衝突的問題。
CSS樣式衝突問題分爲兩類，一類樣式是共用樣式，多頁面引用同一個頁面；另外一類樣式被定義爲私有樣式，只使用頁面，但不但願這個頁面干擾到其餘頁面。這時候給每一個頁面都配了一個CSS文件，定義私有樣式，限定在當前頁面。實現起來也很簡單，經過對工具的編譯，把私有CSS文件裏的全部樣式加一個頁面標誌，在頁面節點的屬性上加一個標誌，這樣就使得class只能做用於當前頁面的HTML元素，這就成爲了一個私有樣式。
而後是JavaScript問題，如今JavaScript模塊化技術很流行，借用JavaScript模塊化技術，解決JavaScript隔離問題。王潔在這裏順便把RequireJS簡單的提了一下，經過define能夠定義模塊，在RequireJS定義裏，這個大括號裏的纔是模塊裏的代碼。無論是方法仍是變量，都封裝在閉包裏，每一個代碼都是寫在define的模塊裏，這樣就把代碼天然隔離了。
![](media/14723796454471/14723810488469.jpg)

王潔說他們在外圍還作了一些工做，首先是實現完整的外殼管理，Shell類提供外殼管理。爲了防止信息泄露，在配置的時候確實會把頁面完整卸載掉。當加載頁面片段時，會從當前外殼數把JS刪掉，頁面加載的時候建立的JS對象都會完整的釋放掉，這是由框架來保證的。另外是路由的問題，在SPA單頁面框架里路由是很重要的，由於是單頁面應用，加載的頁面都是片段，其實UI地址一直是外殼的地址。

下圖是總體框架的架構。黃色部分用的是Cordova，解決安卓和蘋果的原生調用問題。同時要兼容微信，因此上面把Cordova和微信又作了封裝，抽象成統一的HTML5 API。若是經過統一的Native API去拍照，會自動根據頁面環境，經過Cordova接口調用，這樣能夠更方便的實現一次開發，多端運行，代碼不須要改，既能夠運行在原生App裏，也能夠運行在微信裏。包括拍照、GPS地圖，一系列的API均可以進統一分裝。

Bootstrap在這裏提供了幾個能力。一個是樣式美化，扁平化風格，另外響應式佈局。基於Bootstrap設計的頁面，運行在不一樣的設備上不須要考慮分辨率，會自動處理設備分辨率。再上面實現了WeX5的組件框架和數據框架，頁面上不只有交互的UI組件，頁面裏面還有數據。接下來是業務框架層，即SPA單元頁面框架。在服務端WeX5還提供了XBaaS服務，負責後端數據存取、邏輯，還有第三方地圖、支付等功能實現。WeX5提供多語言實現，提供了不一樣語言的版本，開發者能夠針對本身的版原本集成到本身的框架裏。

3、WeX5可視化快速開發實踐

在分享的最後，王潔給你們展現了基於WeX5這樣的框架所開發出來的一些功能。首先是可視化的快速開發程度，幫助開發者經過可視化開發定義頁面，框架能夠保證運行體驗，必須能快速加載，並且各類首試、硬件能力的是一體化集成的。把組件拖到表單上定義佈局，設置屬性，便可獲得最終頁面，設計室和運行室相鄰，徹底所見即所得。

豐富多樣的組件，足以適應各類複雜表單的組合。經過把常見功能組件封裝，能夠極大減輕開發者的開發工做量。最關鍵的是整個組件框架徹底開源，除了WeX5提供的上百個組件之外開發者還能夠本身定義這個可視化組件，甚至能夠繼承第三方組件，經過規範的方式封裝成HTML5的可視化組件。
編程問題也是重點，WeX5的定位是可視化程度更高的前端編程工具。不只能夠可視化設計，編程也是便捷。它能實現代碼的智能提示、代碼模板，還內致了Emmet框架。隨後考慮的是調試問題，WeX5是一體化的環境，不只要解決開發、編程，還要解決調試的過程，既能夠在Web瀏覽器上調試，也能夠連到手機上調試，全部代碼都是開源的，底層內庫也是開放的。最後就是打包的問題，打包要考慮不少插件的配置，參數，資源在命令行的配合。WeX5提供了一個打包的嚮導，徹底本地打包，不須要依賴雲打包服務，只須要把打包過程當中要設置的東西徹底工具化，能夠設置應用版本、證書、LOGO、圖片、插件裏的參數，最後就能夠應用到App上。

《web技術推動多樣化人機交互方式》Intel的軟件工程師吳棟夏女

講述了Intel的各類「黑科技」，還介紹了關於深度加強攝像，場景感知與模型，crosswalk，nw.js

crosswalk

nwjs

nwjs是在英特爾開源技術中心建立的，它是基於谷歌瀏覽器核心引擎和nodejs運行，你能夠經過nwjs技術使用html和js語言編寫本地應用程序，它也可讓你直接從DOM調用nodejs模塊，使用一種新的方式與全部的Web技術編寫本地應用。它主要有如下6個特色：

（1）以網絡最流行的技術編寫原生應用程序的新方法
（2）基於HTML5, CSS3, JS and WebGL而編寫
（3）徹底支持nodejs全部api及第三方模塊
（4）可使用DOM直接調用nodejs模塊
（5）容易打包和分發
（6）支持運行環境包括32位和64位的Window、Linux和Mac OS

《Yo-去哪兒移動UI框架》-杜瑤

瑤姐機智自沒必要說，網紅魅力；
開場前有蹲在我旁邊的妹子跟同伴聊天說「瑤姐，原來是個男的啊」，後面還有一位男生聽到是去哪兒的遂說「去哪兒的杜瑤是要講avalon吧「，我和胖子王濤笑哭，不知司徒聽到這話會不會哭node

雖然用了很長時間Yo，既然是寫參會總結，我在這裏在整理一下：

YO 一款基於Sass開發的css框架，用於快速構建移動UI項目react

mobile First

why mobile First (以mobile做爲基準的設計爲出發點)
1. 公司戰略轉移
2. 新戰場須要有力的框架抹平平臺切換所帶來的適應過程
3. pc端已有成熟的解決方案，無需推倒重來
4. 專一於某一具體的領域更能變得專業
mobile First 的好處

能夠減小對歷史問題的考慮，不如不用考慮IE
保證交互方式的單一性，不用考慮PC上的交互行爲
更及時的應用上新技術
代碼更輕量jquery

ios 默認風格

why ios
1. 巨量的ios用戶（超過50%）
2. 安卓碎片化太重，不易挑選標示
3. ios的交互及展示更具有普適性webpack
  
  Pure CSS 純粹的css 框架
  why pure css

職能更分明
能被使用在任何項目中
不緊密捆綁UI組件ios

分層設計

Yo將不一樣的功能拆解成結構清晰的類別分散到不一樣的層去進行處理css3

yo|---usage
|---lib

分層設計的意義
1. 清晰的依賴
2. 高度解耦
3. 高度複用
4. 高可移植性
5. 結束混亂的文件引用
  
  rem+px
邊框厚度使用px單位
字體，大小等除邊框厚度外的定義使用rem
解決實現retina屏真正的1px 邊框問題

封裝了豐富的常規問題解決方案

下面是瑤姐展現的一些demo：
大體是使用scss語法 @include XX（yo定義好的插件模塊eg： circle(2rem) ellipsis）

獨立配置層設計 config
廠商前綴
iconfont
響應式

元件

擴展超擴展

動畫庫

《手機QQ react web極致優化》Alloyteam工程師李成熙

講述了手機QQ在react框架下的全家桶開發套件，以及踩過得各類坑和性能的極致優化
資料參考http://dev.qq.com/topic/579083d1c9da73584b02587d

react 全家桶

在手Q家校羣重構以前，其實咱們已經作了一版PC家校羣。當時將native的頁面所有web化，直接就採用了React比較經常使用的全家桶套裝：
• 構建工具 => gulp + webpack
• 開發效率提高 => redux-dev-tools + hot-reload
• 統一數據管理=> redux
• 性能提高 => immutable + purerender
• 路由控制器 => react-router(手Q暫時沒采用)

構建工具目錄結構

React 優化三大方向

狀態/數據管理優化

針對React的這個數據比較的深比較deepCompare，要點有2個：
•   儘可能使傳入的數據扁平化一點
![](media/14723796454471/14723916417700.jpg)
![](media/14723796454471/14723917054772.jpg)
•   比較的時候作一些限制，避免溢出棧

渲染性能優化
首屏性能優化

針對有cgi請求，須要吐大量數據的頁面--同構直出
有幾點值得說明：
1. 比改造之前的項目，作直出更容易
2. 減小的是首屏顯示實踐，而非首屏可交互時間
3. 頁面吐出html字符串以後，還須要在客戶端，加載react包，進行事件綁定
4. 作bigPipe之類的優化較難
5. 。。。沒看清
  react同構直出文章
  《React同構直出優化總結》http://www.alloyteam.com/2016/06/react-isomorphic/?utm_source=tuicool&utm_medium=referral
  《騰訊新聞React同構直出優化實踐》 http://www.alloyteam.com/2016/06/tencent-news-react-isomorphic-straight-out-optimization/?utm_source=tuicool&utm_medium=referral
- 拆包
  不用react-router，如何拆包？
非基礎功能，如運營活動 ---輕量化類react方案
Preact---壓縮後只有10kb，gzip後3kb
1. 開源社區有較多的star（承認）
2. 較好的性能和兼容性
3. api跟React接近
4. 足夠的框架周邊，配置redux，router等使用，還有同構直出的插件
5. 團隊成員有能力維護的
  做者參考文章《Preact-React的輕量解決方案》https://github.com/lcxfs1991/blog/issues/13?utm_source=tuicool&utm_medium=referral
簡單回購
Starter-Kit
steamer-react
https://github.com/SteamerTeam/steamer-react/tree/react-preact
web分支，同構分支，preact兼容分支
騰訊發起的交流會將於2016-10-23 日舉行

《手機淘寶營銷互動頁面的最佳實踐》-來自阿里巴巴的呆萌前端工程師黃華健

他鼓勵前端開發者們沉澱出本身的最佳實踐，同時你們能夠去看一下他們開源的解決方案：站在巨人的肩膀上才能看得更遠
對比之前需求來了-幹活的工做模式，工程化-自動化工做流能提升效率即新一代構建工具 rollup （參考文章 http://jixianqianduan.com/frontend-build/2016/01/20/next-generation-js-module-bunlder.html?utm_source=tuicool&utm_medium=referral）

解析ES2015Module
Tree-shaking

這裏實在看不清楚

再來總結下rollup： - 支持ES6模塊規範打包成其它任一格式規範 - 支持tree-shaking方式打包 - 方便接入構建，如gulp - 須要書寫配置任務

索性github上有demo，我尚未來的及實踐，拋連接
手機淘寶營銷互動腳手架 https://github.com/amfe/activity-template

《從MI Cloud的架構變遷看大型spa的複雜工程如何化簡》-小米的高級前端工程師陳愷睿

ppt 地址 https://pan.baidu.com/s/1kVwbDsV
Mi Cloud的主站就是這樣的一個大型的SPA，它主要定位於PC端，PC端包括Web版和桌面應用，同時也兼顧一下移動端。Mi Cloud也正在基於electron開發一個桌面應用

第一次重構
用CommonJS和browserify實現模塊化方案，基於grunt實現自動化構建流程替代以前滿屏jquery 操做dom
第二次重構
又對工程基礎作了進一步的升級，採用標準的ES6的模塊規範，加上更強大的webpack實現模塊化方案，基於gulp實現自動化構建流程，徹底是流式處理，減小硬盤IO，開發環境下進行一次實時編譯從原來的20s左右壓縮到1s內。最近幾年，前端領域新技術層出不窮，其中不乏實實在在能提升生產力的方案，從browserify+grunt到webpack+gulp就是這樣一個典型的例子，從backbone到angular再到react+redux也是一個典型的例子。
而後開始拿業務層開刀。當時剛好有一個業務要作比較大的改版，因而我開始基於Backbone實現MVC架構。
獲得的是一個基於Backbone的MVC架構

完整的流程：
首先用戶操做了界面，好比一個點擊，view層拋出事件告訴controller，controller調用model層某個實例的方法，讓model層向服務器操做，完了以後，model層拋出事件告訴controller，controller調用view層某個實例的方法，更新界面。
其實，我在實踐這套MVC架構的時候，也一直以爲controller部分太複雜，仔細分析一下，controller內主要分爲兩套流程：步驟2，3是一套流程；步驟5，6是另外一套流程。這兩套流程實際上是互相獨立的、互不干涉的，但都流經同一個節點，這無疑加重了這個節點的複雜度。

model層和view層不知道彼此的存在，甚至不知道controller的存在，它們只是經過拋出事件通知外界本身處於什麼狀態，好比view中的哪一個按鈕被點擊了，model中的哪一個字段有更新了。它們不關心誰監聽這些事件。
好處：
• model層和view層徹底分離，能夠由不一樣的人並行開發
• 能夠不依賴走通整個流程來測試，model層和controller徹底沒有DOM操做，能夠實現自動化的單元測試
• 要增長或刪除功能，只須要開始或中止監聽事件便可，層與層之間解耦以後很容易實現對某一部分的替換、增減

因而我將controller的兩套流程分離一下，各司其職。
這樣，無論是從model層到view層的數據流，仍是從view層到model層的數據流，雖然這兩個數據流的起點和終點是對調過來的，但它們流經的節點不同，這樣就清晰了不少。
熟悉react和redux的朋友，可能看這幅圖會比較眼熟。是的，這個時候已經造成了一個單向數據流的閉環。其實，當時我也不知道這會造成所謂的單向數據流，只是在探索怎麼化簡複雜度罷了。
架構演變到這一步，其實已經開始了第二輪重構，當時仍是2015年夏天，我開始熱火朝天的寫一些demo嘗試這個架構模式。
另外一方面，我已經開始嘗試將view層組件化，也就是將一個個視圖類實現成可組合可嵌套的，在通用的視圖類上實現了一套添加子組件/移除子組件等等的API，將整個界面實現成一個個視圖實例組成的樹狀結構。
但其中一直有一些痛點，其中以view層的痛點最加重業務的複雜度。

因而在view層我改爲使用react來實現。業務層只須要寫全量渲染的代碼，不再用寫局部更新的代碼了，框架本身會幫業務層對DOM作局部更新。手動點個贊。
網上也有不少使用backbone的model配合react的文章，其實就相似於咱們的架構演變到這一步時的方案。
因而我繼續實踐，很快又挖出了一個痛點。。
更新組件樹中的深層節點時很麻煩。
一開始的作法是，從組件樹的根節點一層層的往下傳數據，這顯然很麻煩。
再次帶着問題尋找解決方案。此時redux框架通過屢次迭代以後，開始成熟、穩定下來，我發現redux提供的connect函數正好能讓我直接把數據傳遞給組件樹中的深層節點。
因而我引入了redux，最終項目的架構就變成了這樣

除了爲業務下降複雜度的框架，大型SPA的將來還有不少挑戰。好比：

•   強類型，靜態類型檢查
•   異常處理的最佳實踐
•   自動化測試的健全：由於基於react這種視圖層框架幾乎不須要操做DOM，基於redux這種函數式編程思想的框架管理整個應用的狀態，反作用和狀態都獲得很好的控制

控制複雜度的心得。

1.  分治：無論多麼龐大的問題，咋一看很複雜，但把它切割成一個個小問題以後，局面就變得清晰了不少。模塊化、組件化都是這個思路，我以爲前端的路由也體現了分治的思想，把路由看做一個有限狀態機，它就將應用的生命週期劃分紅了幾個大的狀態。
2.  善於利用巨人的肩膀：其實，複雜度並不會減小，它只會從一個地方轉移到另外一個地方，複用組件如此，框架爲業務層封裝複雜性也是如此，因此，善於利於巨人的肩膀，由於它已經幫你轉移了複雜度。
3.  先確認瓶頸再作性能優化：雖然是老生常談，但仍是要強調一下，由於真的頗有用但又很容易忘記。
4.  二八原則：考慮項目的生命週期、影響力來衡量投入的資源，好鋼用在刀刃上，我我的感受小米挺強調成本控制的，畢竟咱們是創業公司，跟大公司能夠適當冗餘不太同樣。