商用Android 工程化實踐，擺脫小做坊式開發

做者：張濤

你們好，今天跟你們分享的主題是：從小做坊到大工廠，一條電商的 Android 工程化開發實踐

我是張濤，就任於一條生活館，咱們公司是一家電商新零售公司，目前移動端的一些開發管理工做都是由我在負責。 對今天的分享有哪些值得探討的也都歡迎與我交流。

Android 做爲一個誕生近十一年的移動操做系統，佔據了近 80% 的市場份額。
我相信在座的不少朋友，都是從2013-2015年開始從事 Android 開發的，可能晚一點的有2016年的。這也正是 Android 生態發展最快速的3年，現在咱們再回過頭來看一下這幾年。

這是咱們曾經的 APP，攜程、美團、京東、淘寶，這是我在網上找的四張圖片，時間都是在2014年2015年的，主要是再久一點的也找不到了。

從前咱們的應用，這四個應該是很典型了的，由於他們欄目多，業務也多。能夠看到，攜程四行三列，其餘的：美團、京東、淘寶，都是兩行四列。

大家都知道，接下來我要放如今的了：這是我最近才從我手機上截的四張圖，依然是攜程、美團、京東、淘寶。

在這四五年裏，互聯網公司大幅增長，而這樣的老牌互聯網公司，新業務也不斷增多，咱們看到，攜程的：WiFi 電話卡、保險簽證、以及上面主業務細分更加精細。
美團那就更是如此了，騎單車、叫外賣、美團打車、美團買菜，相信你們都是有所感覺的。

再日後京東淘寶我就不用說了，你們也都看獲得。
前面從業務角度回顧了咱們這幾年APP的發展，接下來咱們從技術架構角度看一下現代的APP

這張圖，是咱們一條生活館的移動架構圖，這張圖應該能夠覆蓋現在百分之九十 APP 的架構模型。最上層是業務層，常見的 APP 各個業務模塊，好比咱們一條生活館的最重要的幾個業務，CMS首頁、內容相關模塊、電商的商品購物、還有拍賣等等。

第二層，是服務於業務的通用業務層，最多見的瀏覽器web容器、路由功能。UI 統1、咱們的 APP 越作越大，可能一個 APP 由多個設計團隊去負責，那設計就須要有一個統一的控件風格。廣告，各類閃屏頁、內插頁彈窗、小紅點等等。還有 RN、Weex、Flutter這種多端共用業務。

最下層，是一些基礎服務。這裏我列出來了8種，你們能夠發現一個特色就是這8種都是與用戶無關的服務，好比數據上報、異常統計，我做爲一個普通的用戶徹底不在意我用的應用是否有異常統計，他不會影響個人使用。

側邊是一個貫穿咱們整個應用的綜合性技術，像 Kotlin 的 Coroutine(協程)、Google 新推出的相似 SwiftUI 的 Jetpack Compose、模塊化、國際化、插件化等等，都是改動一塊，整個應用可能都會發生變更的技術點。
咱們現在的應用已經到了如此驚人的一個龐大致量，可是……

回到咱們今天的主題：如何完成做坊到工廠的轉變？把上面那些技術全都用一遍嗎？哪怕你說插件化 Kotlin 都不適合咱們，我找出適合咱們的技術都用上，就是大工廠了嗎？

不是的，至少我認爲不是的。
自從我投身到創業公司之後，常常有人問我大公司和小公司的差異是什麼。 在我看來程序員能力的差距都不是最大的問題，固然這是前端，後端可能會由於性能問題形成比較多的損失噢。

在我看來最大的差距就是在基礎設施建設上。小公司每每會由於老闆的眼界、公司資源等各類各樣的緣由，缺失一套成體系的工程化平臺

那麼何謂工程化平臺，就是經過標準化流程的方式，去作的可以批量生產的能力。

好比說咱們前面介紹的一個應用有多個功能模塊，包含基礎模塊和業務模塊，這也是近幾年被喊的很火的移動端模塊化技術。

第二點，數據驅動模塊重組，咱們爲何要讓這些模塊獨立是如何選擇的。
第三點，咱們的研發作好了各個需求，這些需求要如何測試如何上線。
固然，一個前端工程化平臺不止這三點能力，好比線上的APM、日誌監控等等，只是這三點是我認爲做爲一個做坊到工廠轉變必不可少的三點。

接下來咱們從應用架構的角度去一個一個的詳細聊聊，首先是業務模塊獨立。

不管任何一個應用，想要作到模塊化拆分，都必不可少要面臨這三個問題：跨模塊函數調用、跨模塊界面跳轉、跨模塊消息傳遞。 固然，若是這是一個業界常見問題，必定會有開源的解決方案，好比前面兩個，咱們能夠經過阿里開源的ARouter解決，後一個我相信作Android的沒有人不知道EventBus。可是這兩個框架在咱們真正用起來的時候，都會碰上一些問題。好比ARouter，他從一開始設計就是爲了淘寶這樣大型的APP去作的，他在應用首次啓動的時候要把全部類遍歷一遍而這個時間是很是長的，即使是經過分組懶加載也依然很慢。

固然還要一個更重要的緣由，是由於咱們在ARouter開源以前，就已經有了一套完整的路由框架，因此就沒有再使用ARouter了。 另外一個EventBus也是訂閱者模式都會遇到的問題，就是消息氾濫的狀況。當應用內消息過多的時候，會形成消息難以追蹤，調試問題的複雜度也隨之增大了。

YitBridge 使用了與後端 SOA 設計思路相似的方式：將模塊之間的主動依賴倒置，變爲功能的提供與使用。 那什麼是 SOA 的設計思路呢，咱們看到一張我畫的漫畫圖：SOA 它是一種面向服務的架構模型。

例如圖上左邊有一個對外提供媒體功能的服務提供者，他告知YitBridge我提供媒體服務：「嘿，老鐵，我這有個媒體服務，你那邊有誰要用的時候能夠用個人。」
到了另外一邊，若是此刻有模塊說是，我須要媒體服務：「老鐵，你那有沒有媒體服務，我這邊須要播一個鈴聲啊！」。
「有的，給你。」

YitBridge 就會將以前服務提供者與服務使用者作一個橋接完成服務的調用。

接下來咱們來看具體到代碼上是如何使用的：首先是做爲服務使用方，也就是上一張圖右半部分的Client。咱們看到上面是傳統的作法，首先聲明一個藉口類型，而後new出接口的實現類給他賦值。而使用了YitBridge的時候，你是不須要關心接口的實現類究竟是誰的。這就是YitBridge惟一的用處，隱藏實現類，作到完全的面相接口編程。

以前說過，YitBridge將模塊之間依賴倒置，由以前的服務提供方被動的接受調用方調用變爲，服務方主動提供服務給調用方。那做爲服務提供方須要作些什麼事呢，很是簡單，你只須要給你的對象提供方法加上一個@Creator註解，告訴YitBridge這是一個建立器方法就能夠了。

前面講YitBridge實現完美實現了模塊間的解耦，而YitBridge的內部實現就是經過這個APT來完成的。Annotation Processing Tool，相信你們都有據說過這個APT，即使是你沒據說過，你也確定早就用過了，只是你不知道。 Android 上有一個註明的註解綁定框架叫 Butterknife，他的內部實現就是經過APT來作的，還有 Google 出品的 Dtabinding、Dagger2，這些也都是APT來作的。那這個註解處理器在 YitBridge 中作了些什麼呢，咱們來看這段代碼。

這是 YitBridge 在編譯之後生成的一段類：仍是繼續咱們前面講的那段示例來繼續，在運行時，他會根據你傳入的 get() 方法的參數，來判斷你所須要的是哪一個接口的實現，而後去調用對應的建立器方法。

那麼除了這個問題，還有就是多版本協做開發時候的模塊依賴問題。 Android 使用的是 Gradle 構建，若是出現基礎接口更新，上層全部依賴都跟着從新更改一下，再作一次兼容。這種事原本是無可避免的，可是若是咱們有多個版本同時開發，這個問題就大大提高了版本管理的複雜度問題。因此咱們引入了一個 baseVersion 的概念，也就是你當前模塊構建的目標版本號。只要依賴的模塊的目標版本號一致，就能夠不用考慮兼容性問題直接更新，若是baseVersion 不一致，那說明這是一次不兼容升級，須要上層模塊處理完兼容性問題後再發布。

這就是前面 moduleApi的實現，其實就是判斷了一下baseVersion是否一致，若是一致，那麼就直接引用最新版本，若是不一致，則拋異常退出編譯。從而將運行時的錯誤在編譯期就直接發現。

第二部分，數據驅動模塊重組

數據這裏，我能跟你們聊的很少。

第一個，RMF模型。
RFM 模型是電商衡量用戶價值和用戶創利能力的一個重要數據，分別指三個緯度：最近一次消費 (Recency)、消費頻率 (Frequency)、消費金額 (Monetary)。從這三個維度綜合評分最終就能夠量化出一個用戶的價值，那麼這個價值就能夠輔助咱們在線下創建線下店、用戶社羣等等數據化運營了。

第二個，商品曝光與轉化統計。
也是電商公司會常用的統計商品轉化率的方式，好比一個商品他在用戶手機上被展現了多少次，展現了之後用戶點擊了多少次，這些點擊又有多少是收藏或加入購物車了的，以及最終下單購買等等一系列流程，最終就能夠分析出每一個商品的轉化率，慢慢的咱們確定會優先選擇跟轉化率高的供應商合做。

第三部分，標準化持續集成與交付

這裏是咱們目前使用的模塊依賴構建工具，你們能夠從這張圖中感覺一下。 構建工具，主要的功能是很明顯的，就是用於構建模塊，在這之上，還有隱含的功能，就是集中了構建模塊的權限，能夠更便於統一管理； 固然還有最重要的優點就在於模塊版本的管理，你能夠很清晰的知道當前主應用所接入的模塊的版本是哪一個，當前最新構建的SNAPSHOT是哪一個，以及每一個版本的更新日誌； 這樣作了之後，在跨團隊協做上的溝通就大大下降了，若是你已經接入或者即將接入的模塊是另外一個團隊開發的模塊組件，那你能夠直接關注它，它的全部版本變更日誌，最新版本全都一目瞭然； 而且能夠經過平臺簡化模塊的測試與模塊發佈的流程，好比提測的時候，若是是一次兼容版本的發佈，你只須要告訴測試提測分支，測試能夠本身根據如今線上應用的tag，同時引入當前提測的模塊替換老版本的模塊從新編譯，很容易就能控制變量。

第二個就是，經過平臺化的構建工具，能夠很方便的動態選擇模塊依賴，好比咱們在測試某個模塊的時候，能夠排除部分已經保證沒有問題的模塊，那麼在測試的時候就能夠更聚焦，讓測試只看咱們發生改動了的模塊，最終集成測試只須要簡單看一下就好了。

接下來咱們再看看發佈效率。最先咱們的代碼，是很是嚴格的 N 週一個迭代的發佈。可是隨着業務愈來愈多，團隊也愈來愈大。不少時候不得不 delay 一兩天來照顧到全部的業務團隊。

以後，就有了咱們模塊化解耦，每一個業務按照本身的迭代排期計劃好，若是 delay 了那麼這個版本大家的新需求就得放到下個版本再發布了，這樣主 APP 的發版再也不依賴哪一個業務線，同時業務組件能夠提早打包，這也加快了打包時所用的時間。

再到最後，經過用戶畫像精準推送。咱們能夠作到代碼隨時發版，只要你認爲你的需求作完了，測試經過了，就能夠發佈 APP。可是這個版本並不必定是每一個用戶都會接收到，而是咱們提早已經分析過用戶行爲，那些願意主動使用最新應用的用戶纔會收到應用更新。你們打開手機裏面的微信、QQ 等等，點一下檢查更新看看，基本上都是提示已是最新版本了，但你用的卻不必定是最新的版本，你能夠去官網再本身下載一個 apk 裝上看看版本號。

在以後就是我前面提過的，工廠化發佈一個APP。咱們能夠根據業務須要任意組裝業務模塊，最後拼成一個APP，快速發佈到線上，查看這個應用的數據反饋，若是這個應用從數據層面看運行的很是好，那麼就能夠考慮引導流量到這個應用。若是數據很差，那麼儘早放棄下降研發成本，準備其餘的業務也更靈活。

Android學習PDF+架構視頻+面試文檔+源碼筆記

---

感謝你們能耐着性子看完囉裏囉嗦的文章

在這裏我也分享一份私貨，本身收錄整理的Android學習PDF+架構視頻+面試文檔+源碼筆記，還有高級架構技術進階腦圖、Android開發面試專題資料，高級進階架構資料幫助你們學習提高進階，也節省你們在網上搜索資料的時間來學習，也能夠分享給身邊好友一塊兒學習

若是你有須要的話，能夠點贊+評論，關注我， 加Vx：15388039515（備註思否，須要資料）