1、前言
經過前面幾篇Weex原始碼分析系列文章，相信大家對Weex是什麼、Weex能帶來什麼、Weex是如何工作的等幾個問題已經有了自己的答案。
備註：
- 本文會非常簡潔，因為是站在前面幾篇原始碼分析文章的肩膀之上進行概括總結。如果還有疑惑的話強烈建議大家回過頭再去看看之前的文章；
- 基於Weex0.16.0版本；
2、Weex的核心能力
誠然，Weex為了方便開發者提供了各種方便的元件便於傻瓜式開發，但隨著我們對Weex剝絲抽繭，我們更能學習到Weex的精髓：如何以新思路解決老難題？
Weex動態化、跨平臺、結合Native的設計不僅解決了需要頻繁發版的問題，同時在一定程度上可以節省人力成本。在技術選型上RN與Weex的思路都沒有問題，也都堅信這條道路都可以走得通。對於二者最核心的能力就是JS引擎與Native的互動能力，別的類如Js框架、元件支援、工具鏈、擴充套件、生態等實際上都是附屬，都是一項技術的附帶產物，為了贏得開發者的支援而做的。
對於Weex而言其實只要保留下Js與Native的互動能力，別的各種產物我們都可以自己實現一份，思路不會有大的差別。
所以大家更應該由一項新技術的學習逐漸過渡到真正理解技術背後的本質，如果是我們自己實現我們的思路是什麼樣的，新技術有哪些我們可以借鑑的地方！
3、Weex框架分析
大家回憶下關於各個元件原始碼分析的文章中：
- 首先離不開的就是JSBridge，這是JS與Native互動的橋樑；對應於通訊層；
- JS發回來的每一個指令都會先經過各種Manager的處理，然後封裝成相應的Action；對應框架層；
- 注意很多操作都是在特定的執行緒比如WeeXDomThread，與之相對應的有執行緒的切換；對應於執行緒通訊層；
- 最後每一個JS指令執行的時候都會對應於一個元件：Module、Component、Adapter等；對應於元件層；
4、Weex框架圖
我們再對著框架圖分析一遍：WXBridge負責JS引擎與Native的互動、框架層負責將JS指令進行處理、通訊層進行各個執行緒的切換、每一個JS指令都對應了元件層的執行。
5、總結
本文是對前面幾篇原始碼分析文章的一個概括總結，只是嘗試去理解Weex SDK的框架設計及核心原理，畢竟對於Weex整個的生態而言SDK只佔了其中的一部分，還有很多類如開發流程、工具鏈、擴充套件等很多的面等待我們繼續探索。
歡迎持續關注Weex原始碼分析專案：Weex-Analysis-Project
歡迎關注微信公眾號：定期分享Java、Android乾貨！
