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

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

做者 | 冉葉蘭嘉賓 | 郭金編輯 | 張之棟、王文婧近幾年，前端工程化愈來愈多地被說起。到底什麼是前端工程化？大前端工程化中的「大」咱們又該如何去理解？咱們該怎樣去搭建一個適合自身的前端工程化工具？在搭建前端工程化工具中會遇到哪些問題？又該如何解決？

在即將於 12 月 20～21 日舉行的 GMTC 全球大前端技術大會 (深圳站) 上，百度資深研發工程師郭金老師將分享 《百度 App Tekes 研發一體化平臺》。InfoQ 在會前採訪了郭金老師，帶你們瞭解百度「大前端工程化」的打開方式，看看百度如何落地 Tekes 研發一體化平臺，以及百度 App 的架構與工程能力。百度又是如何經過研發流程一體化平臺，實現並行開發、快速迭代和高效複用的？ InfoQ：自從有前端工程化這個概念，很快就出現了「大前端工程化」，您是怎麼看待「大」前端工程化這個概念呢？

郭金：工程化目標是提高開發效率，保障應用質量。「大」前端工程化是指移動端、前端在項目規模、工程複雜度、快速迭代等相同背景下，對一些共性問題的思考。好比，如何保障多人協同並行開發效率、如何控制質量影響範圍、如何進行依賴管理 (包管理)、如何規範研發流程以及在快速迭代下如何控制劣化等。

總的來講，前端、移動端在容器化、組件化 (模塊化)、依賴管理 (包管理)、自動化、流程規範等方面都有不少類似性。

針對這些問題咱們會產生一些思考: 既然面臨一樣的問題，那能不能用一樣的解決方案，甚至一樣的技術棧。這時候有一些全棧工程師跳出來，他們遊走在各類技術角色之間，充分吸取各端技術優點，讓各端技術優點互補。

  InfoQ：大型 App 須要對工程適度拆分來保障並行開發。在工程拆分方面，有什麼指導原則？

郭金：1. 定義架構層級，並規範底層組件不能反向依賴上層組件，越往下層對組件接口穩定性、依賴的合理性以及質量要求就要更高；

1. 要有一套機制或框架來保障各組件或模塊能作到邏輯、資源、數據各有歸屬，這個框架就是咱們常說的廣義組件化框架；
2. 沉澱一些各業務複用的通用服務組件，好比帳號、ABTest 等組件；
3. 基礎庫的體系化建設，基礎庫的建設主要是避免交叉依賴，有合理的粒度，作到低成本輸出；

4. 全面的業務組件化，利用組件化框架提供的容器，分發、依賴注入、數據拆分等框架作到邏輯、資源、數據各有歸屬，邏輯、接口邊界清晰，組件必須有明確的功能定位。

作好上面這些，也就達到殼化的目標。

最後，須要有防劣化的機制，這也是最難作到的。百度 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 實戰、新興編程語言、團隊建設與管理等熱門技術專場，目前大會 9 折購票，點擊「閱讀原文」瞭解大會日程。有任何問題歡迎聯繫票務魚丸：13269078023（微信同號）