百度App移動端工程能力演進

近幾年,前端工程化越來越多地被提及。到底什麼是前端工程化?大前端工程化中的“大”我們又該如何去理解?我們該怎樣去搭建一個適合自身的前端工程化工具?在搭建前端工程化工具中會遇到哪些問題?又該如何解決?

在即將於 12 月 20~21 日舉行的 GMTC 全球大前端技術大會 (深圳站) 上,百度資深研發工程師郭金老師將分享 《百度 App Tekes 研發一體化平臺》。InfoQ 在會前採訪了郭金老師,帶大家瞭解百度“大前端工程化”的打開方式,看看百度如何落地 Tekes 研發一體化平臺,以及百度 App 的架構與工程能力。百度又是如何通過研發流程一體化平臺,實現並行開發、快速迭代和高效複用的?

InfoQ:自從有前端工程化這個概念,很快就出現了“大前端工程化”,您是怎麼看待“大”前端工程化這個概念呢?

郭金:工程化目標是提升開發效率,保障應用質量。“大”前端工程化是指移動端、前端在項目規模、工程複雜度、快速迭代等相同背景下,對一些共性問題的思考。比如,如何保障多人協同並行開發效率、如何控制質量影響範圍、如何進行依賴管理 (包管理)、如何規範研發流程以及在快速迭代下如何控制劣化等。
總的來說,前端、移動端在容器化、組件化 (模塊化)、依賴管理 (包管理)、自動化、流程規範等方面都有很多相似性。
針對這些問題我們會產生一些思考: 既然面臨同樣的問題,那能不能用同樣的解決方案,甚至同樣的技術棧。這時候有一些全棧工程師跳出來,他們遊走在各種技術角色之間,充分吸收各端技術優勢,讓各端技術優勢互補。

InfoQ:大型 App 需要對工程適度拆分來保障並行開發。在工程拆分方面,有什麼指導原則?

郭金:1. 定義架構層級,並規範底層組件不能反向依賴上層組件,越往下層對組件接口穩定性、依賴的合理性以及質量要求就要更高;
2. 要有一套機制或框架來保障各組件或模塊能做到邏輯、資源、數據各有歸屬,這個框架就是我們常說的廣義組件化框架;
3. 沉澱一些各業務複用的通用服務組件,比如賬號、ABTest 等組件;
4. 基礎庫的體系化建設,基礎庫的建設主要是避免交叉依賴,有合理的粒度,做到低成本輸出;
5. 全面的業務組件化,利用組件化框架提供的容器,分發、依賴注入、數據拆分等框架做到邏輯、資源、數據各有歸屬,邏輯、接口邊界清晰,組件必須有明確的功能定位。
做好上面這些,也就達到殼化的目標。
最後,需要有防劣化的機制,這也是最難做到的。百度 App 是通過 EasyBox 工具鏈和 Tekes 平臺發佈通知系統來做到這一點的。通過 EasyBox 做到組件間的編譯隔離,層級反向依賴防控;通過 Tekes 來做依賴、接口劣化防控。

InfoQ:大型 App 與中小型 App 的差異點及複雜度在哪裏?

郭金:差異主要體現在大型 App 的團隊規模、業務規模 (包含非基礎庫類的接入業務規模) 比較大,迭代速度快、技術形態多以及有多樣性的目標。大型 App 的關注點會比小型 App 多,最基本的要求是保障並行開發,提升研發效率,以及不同組件間相對能做到故障隔離來保障整體 App 的質量;
更進一步是多技術形態下基礎能力複用、矩陣產品孵化;
還有技術組件對外輸出 (包含小程序開源),這些輸出很多不是單一組件對外輸出,而是成組對外輸出,對外輸出的組件不僅要適應百度 App 的架構與環境,也要適應不同的宿主架構和環境;
另外就是性能、體積因素的約束,問題快速定位能力的要求。
複雜度就體現在這樣的背景和多樣性的目標上。毫不誇張地說,在大型 App 裏做架構和工程能力就是要讓大象跳舞。

InfoQ:組件化與組件化框架,以及依賴管理工具間的關係是什麼?

郭金:組件化是一個體系化的工作,需要通過上面講到的一系列的工作來一步步落實。
廣義的組件化框架指一切具有依賴注入、分發、容器化、數據拆分、資源拆分、組間通信性質的非功能性組件。這些組件的主要目的是保障其他組件邏輯、資源、數據各有組件歸屬,組件化框架是並行開發的基礎保障。
關於依賴管理工具,很多人會混淆依賴管理工具和組件化框架,依賴管理工具在一定程度上能保障組件的邏輯邊界,也就是控制開放接口,也能協助組件明確依賴。依賴管理工具更多是構建系統的一部分。

InfoQ:工程拆分後,目前的收益和成果有哪些?

郭金:可量化部分的數據,首先是我們矩陣產品組件複用率能達到 55%,矩陣產品同步主線的時間也由原來的 5 人周降低到 1 人周。
不可量化的數據,我覺得價值更大。首先提升了研發效率,研發效率的提升主要體現在幾個方面:第一個是複雜度內斂,不對外暴露複雜度;第二個是並行開發效率,組件化具有分發、容器化等性質,很多集中式管理的邏輯、事件會通過組件化框架分發到各目標組件,減少了組間耦合和交互;第三個體現在複用上,工程拆分後,沉澱了大量的服務組件和基礎庫組件,也就是有很多可用的輪子。
其次是在質量上,邏輯各有歸屬,加上組件化的分發機制,確保各組件間相對隔離,單個組件的故障範圍能內斂到組間內部;
最後,拆分的組件是一個編譯單元,是啓動速度、體積等指標的量化單位,方便快速定位性能、體積等問題。

InfoQ:EasyBox 綜合解決方案主要包含哪些部分?EasyBox 的出現是基於什麼樣的背景?

郭金:EasyBox 綜合解決方案包含三部分:多倉庫管理工具 MGIT、二進制管理、構建系統。多倉庫部分主要是團隊規模變大,通過代碼評審權限分離來保障質量,另外也是多產品線倉庫粒度源碼複用的需求推動的;二進制管理部分是從編譯速度和對外輸出穩定的發佈版本這兩個方面考慮的;最後構建系統支持分組件源碼 / 二進制切換模式,這既滿足了開發的靈活性,也統一了多方合作的開發模式。

InfoQ:多倉庫管理爲什麼不使用 Repo?

郭金:這個主要是從容錯和易用性兩個方面考慮的。我們強化了同名分支的原則,來保障多倉庫間同步。易用性上操作命令基本和 git 對齊,另外對很多輸出做了歸類整合,讓研發同學能像操作單倉庫一樣操作多倉庫,降低上手難度。

InfoQ:對 iOS 來講,構建系統 (依賴管理) 爲什麼不使用業內知名的 CocoaPods?

郭金:CocoaPods 是一個很好的依賴管理工具,雖然 Apple 自己出了 SPM,但是僅支持 SWIFT 包管理,CocoaPods 是 iOS 平臺事實上的依賴管理標準。其實,在開始做技術選型的時候,是基於 CocoaPods 修改還是自建我們也很糾結。最後幾方面考慮,我們決定自建:首先是編譯隔離,CocoaPods 組件間的訪問相對比較隨意;第二,當時我們也參考了 FaceBook 的 Buck 方案,去工程文件化,早期百度 App 工程文件有 5~6 萬行,且可讀性較差,去工程文件化大幅降低了工程文件的合併成本;第三,我們要保障架構有自底向上的輸出複用能力,要做架構層級的反向依賴控制;最後,我們要實現分組件源碼 / 二進制一鍵切換的開發模式。基於這幾個原因,即使基於 CocoaPods,也需要大改,最後決定自建,這樣我們幾個子系統間還能較好地做好分工配合。
我們早期上線的時候,因爲一些體驗問題,很多同學會有“爲什麼不用 CocoaPods”的疑問,當我們逐步優化後,問這個問題的同學越來越少,大家也越來越認可 EasyBox 纔是最適合我們的解決方案。

InfoQ:EasyBox 綜合解決方案落地後,收益和成果有哪些?

郭金:可量化的部分,首先,我們把原來的工程拆分爲多倉庫,並且 iOS 做到了去工程文件化,能做到並行上車 (合併到 master ),並行上車率 46%,上車耗時也降到了原來的 1/3,每次迭代大約節省了 20~30 個小時;其次,實現組件源碼 / 二進制的切換的開發模式,編譯速度提升了 74.8%~85.8%(不同性能的機器從 16 分 12 秒優化到 2 分 18 秒,或 6 分 30 秒到 1 分 38 秒);最後,不可量化部分,我們升級了構建系統,讓矩陣產品可以組件倉庫粒度源碼複用,實現了 App 生產線的能力,也提供了架構的靈活度,即降低了架構升級成本。

InfoQ:百度 App Tekes 研發一體化平臺是基於什麼樣的背景,此方案帶來了哪些變化?百度 App Tekes 研發一體化平臺在未來有怎樣的規劃?

郭金:首先是我們實現組件二進制化後,需要經常發佈組件的二進制版本,因爲本地發佈不安全,並且百度 App 也有對外輸出穩定二進制版本的訴求,我們考慮能將這一流程自動化,當然一些 ChangeLog 還是需要手工編輯的;其次是基於組件化劣化防控的目標,我們希望有個平臺能把各個組件依賴、接口變更、對外文檔的情況展示出來,有劣化的話及時通知對應的研發同事優化;最後是希望能把研發流程體系化,比如及時產出性能、體積、單測報表。
這個方案上線後,我們建立了組件二進制版本規範,矩陣產品有了二進制版本複用的基礎,也統一了百度 App 的研發和合作團隊研發的開發模式,編譯成功率也提升了很多。
Tekes 平臺的目標還是把整個研發流程體系化,更好的保障研發效率、矩陣產品孵化能力以及研發質量不劣化。

嘉賓介紹
郭金,百度 App 資深研發工程師,2014 年入職百度,先後負責社交化、基礎性能等技術方向,目前負責百度 App 客戶端工程與架構方向。在 App 複雜的背景和多樣化的技術目標要求下,設計並完成百度 App 架構與工程能力升級,並着力於打造研發流程一體化平臺,實現並行開發、快速迭代、高效複用。

活動推薦
在即將到來的 GMTC 深圳 2019 上,郭金老師還會具體分享,百度大型 App 架構設計與拆分方法、超級 App 高效工程能力保障方法、組件全量二進制實現路徑、組件二進制自動發佈的流程、矩陣產品工程孵化模式等。

除了郭金老師的分享,本次 GMTC 我們還設置了小程序挑戰與應對、音視頻技術、Serverless 實踐、前端測試與安全、大前端工程化、Flutter 實戰、新興編程語言、團隊建設與管理等熱門技術專場。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章