原作時間：2019～2021年

此次共享，騰訊內網 / 外網同步發布。

內部代碼地址：https://git.code.oa.com/fatboyli/QBDF

外部代碼地址：GitHub - ventureli/QBDF

兩年前的一個混淆包（無源碼）：GitHub - ventureli/VLOCInterpreter

作者：騰訊fatboyli（李文強）

1.立項

大約在2017年的時候，QQ瀏覽器IPAD項目組還在北京，那時候AppStore上架還比較慢，我們項目組決定做自己的動態化框架，動態化框架的目標是：真正實現一次發版本，多次發布。

整個iPAD項目組對整個市場的動態化框架做了一次比較深入的研究（為期一周）當時團隊的分工如下：如今小伙伴都以天各一方，懷念和大家一起戰斗的日子。

項目組分工

最開始我們并沒有信心完全從0開始做一個全新的動態化框架，我們的想法是從WEEX上進行更改和擴展，形成QB團隊自己的動態化框架。這一決定其實浪費我大約1.5個月的時間。WEEX的核心問題非常嚴重。整個動態化框架的設計和實現工作最后交給我來實現。

2.第一版本架構

接到任務后，大約利用了2周左右的時間對WEEX的源碼進行了了解，我們第一步對weex的整個一些UI層面的限制進行了修正。主要有如下幾個方面：（當時版本的weex比較早，現在這些問題可能已經不存在了。）

1.不支持完全比例排版（比如子控件的高度是父控件的寬度的50%）

2.對旋轉屏幕的支持

3.添加iOS的特有屬性支持（比如對tableView的group的形勢的支持）

4.修正BUG

上面的內容我就不展開說明了，這并不是本系列文章的重點，但是里面有非常多有意思的小trick。有興趣的同學可以單獨聯系我。

以上主要是針對UI層面的。但是WEEX在邏輯層面有天生的短板，它和RN是完全一樣，采用預先注冊的形勢進行和Native交互，這只能算作是跨平臺，并不能算作完全能力的動態化，我猜想這也是蘋果之所以沒有對RN和WEEX動手的原因。比如我在WEEX要用的某個NATIVE寫好的BUTTON，那么這個BUTTON在WEEX引擎初始化的時候用以下代碼注冊好。

[WeexSDKEngine registerModule:xxxx WithClass:XXX]

這就根本算不上動態化了，這也造成了WEEX還不能夠進行打PATCH。

第一版本架構

3.第二版本架構

但是 等等，當時是有能夠完全能力動態運行和打PATCH的框架的偶～ YES， JSPATCH！所以我當初想的是用WEEX處理UI層面的操作，用JSPATCH來做邏輯層面的引擎從而達到無限制的動態化能力。架構大約是這個樣子。

第二版本的架構

這里面的核心問題是怎么WEEX的腳本里嵌入JS腳本，這個設計也是比較有意思的，我設計的幾個宏字符串

_OBJC_JSP_REGISTERTARG_（注冊參數）

_OBJC_JSP_JSCALL_START_（JSPATCH代碼開始）

_OBJC_JSP_JSCALL_END_（JSPATCH代碼結束）

_OBJC_JSP_JSCALL_RETURN_（輸出變量）

通過這幾個宏字符串可以完成JSPATCH代碼內嵌到WEEX里。這幾個宏定義我也不展開詳細介紹了，大致的思路是JSPATCH運行的時候先通過全局替換的方案，把這些字符串替換為一個內置的方法，比如 XXX_CALL（1），這樣，然后把每段JSPATCH代碼編號，這樣當運行到XXX_CALL 這個方法時候，就能知道要去取什么JSPATCH腳本了。同時_OBJC_JSP_REGISTERTARG_方法預先注入參數，_OBJC_JSP_JSCALL_RETURN_ 輸出參數即可。此時的代碼看起來是這個樣子的。

WEEX橋接JSPATCH

3.第三版本架構

完成了以上的工作，我們第一個QBDF框架就實現了。但是在此基礎上我重新做了一個擴展，基于以下的想法。

WEEX是JS，HTML也可以運行JS

WEEX的JS可以橋接JSPATCH，那么HTML應該也可以橋接JSPATCH

HTML的JSPATCH是需要做加密的，否則會暴露NATIVE邏輯

所以我重新設計了一個新的模塊作為QBDF的補充，就是 HTML+JS+CSS +資源 打包成為ZIP作為WEBAPP，通過后臺模塊下發和維護，同時JS橋接JSPATCH代碼實現WEBAPP能力無限制。

如上后第三版本的框架的架構圖如下。

第三版本框架

4.第四版本架構

以上框架完成后，基本上已經完成我們最初的想法，確實是一個有動態化能力的框架，

Weex開源代碼深度定制，UI動態化

可動態配置

可以調用幾乎任意代碼，無須注冊

雖有學習成本，VUE和JS比較好學

未來只要解決bug即時更新開源代碼就可以了

但是其實在這個過程中，發現了幾個問題。我做了如下的考慮。

SPATCH和WEEX都是基于JAVASCRIPTCORE的，都是基于WEBTHREAD的。而我們瀏覽器里面有大量的WEBVIEW一旦代碼寫的不注意就回出現死鎖，甚至有時候無法避免以至于不能打PATCH，這也是我們和其他APP比較特殊的地方。

QBDF不應該是這樣一個修修補補的二流框架！

還沒達到我自己的要求

所以最后我們重新設計了整個QBDF框架，從0開始寫一個OC語言的解釋器和虛擬機動態運行OC代碼，一個完全基于編譯原理層面的動態運行OC語言的解決方案。第四版本的家購入如下。

第四版本QBDF腳本

好了，本文到這里就結束了，我們的QBDF經歷過很多版本的迭代。

總結

以上是生活随笔為你收集整理的QQ浏览器HD的动态化方案QBDF的前世今生（1）【简书被冻结-搬运】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。