Android元件化開發實踐（六）：老專案實施元件化
比較早期的時候，我們開發APP都是採用單一工程模式，隨著業務的發展，APP越來越龐大，開發人員越來越多，所以必然面臨著將老專案進行元件化的過程。
在將老專案進行元件化的過程中，會面臨很多的問題，以我自己的經驗為例，主要有以下點：
- 程式碼年久失修，文件缺失，不敢隨意修改，否則會牽一髮而動全身，引起現有正常業務的執行；
- 進行元件化重構需要花費比較長的時間，業務不可能停下來等著你去重構；
- 元件化重構後，需要全量回歸測試，測試比較花費時間；
相信每個人都會碰到這些問題，元件化重構勢在必行，但是老闆不可能專門給你幾個月，啥業務都不做就讓你進行程式碼重構。那怎麼辦呢，我這裡講講自己的一些經驗，供大家參考。
1. 優先整合路由框架
首先，在老專案中引入路由框架，不管是自己簡單設計的也好，還是採用第三方框架，新開發的功能頁面跳轉一律採用路由，老的頁面跳轉逐步替換。這樣做的目的是儘量減少程式碼耦合，為後面進行模組拆分打下基礎。
2. 業務模組拆分
一個老專案必然經過很多人的手，你不一定要對所有程式碼都很熟悉，但是你必須要基本瞭解所有的業務功能，在此基礎上對所有業務進行初步的模組劃分。這個業務模組劃分，粒度可以粗一點，原則上一個業務模組只是實現某一個子功能。
以我自己為例，我會採用xmind或類似工具，將所拆分的業務畫出來，就像一個公司的組織架構一樣：公司由若干個大的事業部組成，每個事業部包含若干個二級部門，二級部門又有可能包含三級部門。將你的專案劃分成幾個大的業務，每個大的業務再細化成若干個小的業務，業務層次劃分不必太細，一般保持2層即可，否則設計的元件太多，實施起來會更加繁瑣。
總之，最後你一定要有一張你的整體業務架構圖，如上圖所示，它僅僅是你對APP所有業務的模組劃分。
3. 嘗試抽取出一個基礎的業務元件
羅馬不是一天造成的，人不能一口吃成一個胖子。同樣，你也不可能一下子將所有的業務，都進行元件化剝離出來。萬事開頭難，特別是老專案在進行元件化重構時，往往我們會有無從下手的感覺。回顧一下上一節中你整理出來的業務架構圖，從中找出一個你覺得最核心最基礎的業務，也就是你覺得這個業務必須最先進行元件化重構。通常情況下，我會選擇“註冊/登入”這個業務模組，在我們的應用裡，很多業務都是需要使用者登入的。
首先，新建一個工程，不管三七二十一，把老工程裡的註冊、登入相關的程式碼拷貝過來，包括Activity類、佈局xml檔案、圖片檔案等，其他的暫時不要考慮。這個時候，你會發現新的工程裡，到處都是紅色的警告錯誤，要麼依賴的某個類不存在，要麼依賴的某個資原始檔不存在，根本無法編譯執行。不能執行就對了，顯然這種粗暴的方式行不通，如果你嘗試去解決，你會發現類似這樣的依賴路徑：A -> B -> C ->D，你得把所有依賴的類或資源拷貝到新工程裡，這可能會形成一顆巨大的依賴樹，實施起來難度太大了，基本不現實。
顯然，想直接把老工程的程式碼原樣複製過來，期望一次性成功，大部分情況下都不會成功。那麼我們要怎麼做呢，現在又會有一種無從下手的感覺了。
4. 畫出程式碼的依賴關係圖
我們把老工程的程式碼複製過來之後，發現依賴的資源太多了，壓根沒法編譯執行。既然我想把“註冊、登入”這個業務模組做成一個獨立的元件，那麼這個業務模組裡所依賴的其他資源，是不是也得是個獨立的元件。同樣，採用xmind畫出“註冊、登入”這個業務所依賴的其他資源，如下圖所示：
通過檢視新工程裡報錯的地方，大概可以總結出“註冊、登入”業務需要依賴上圖所示的這些資源。
5. 抽取出基礎功能元件
當我們把“註冊、登入”所有依賴的資源列舉出來之後，我們先把這些依賴的東西，從老工程中抽取出來，做成單獨的元件。
- 日誌記錄
列印或者記錄程式執行時日誌。 - 網路請求
請求服務端介面用到的網路框架，例如OkHttp、Retrofit等，或者是自己封裝的框架。 - 資料庫等資料儲存
使用者登入後，需要儲存登入資訊到本地，採用資料庫或者SharedPreference等儲存。 - 圖片、樣式、字串等資源
UI相關的各種資源，有些資源是全域性通用的，有些是該業務裡獨有的，我們只把通用的UI資源放到元件裡，因為這些需要共用的。 - 常用的一些工具類
例如字串處理、日期格式化、dp與px轉換等。 - BaseActivity等Base類
BaseActivity是所有Activity都必須繼承的父類，在這裡定義一些Activity通用的行為，例如友盟統計埋點等。
我們先按照這些功能，建立對應的基礎功能元件模組，然後將註冊、登入業務裡需要用到的從老工程移到對應的元件模組裡。剛開始的時候，我們的目標是先建立元件，元件的功能也許很薄弱，程式碼也許很凌亂，規範也沒有，但是我們先不管它，先做到能用就行。先有基本的框架，等架子搭起來之後，我們再去豐滿血肉。
6. 重新封裝基礎業務元件
上一節中的基礎功能元件封裝好之後，在“註冊、登入”這個元件工程裡，依賴需要的基礎元件，然後逐步解決衝突錯誤等，直到該工程能夠獨立執行。最後，我們需要花時間調整程式碼規範，優化程式碼結構等。
7. 新老程式碼共存
到現在為止，我們已經將一個業務元件獨立出來。接下來，我們需要將該元件整合到老工程裡去，只需要將註冊、登入的跳轉入口改一下，就可以使用了。經過測試之後，逐步刪除老工程裡的舊程式碼，這樣下來之後，註冊、登入使用的是新的元件，而其他功能依舊沒變。
接下來的時間裡，我們採取開發新功能與重構並行的方式，每週安排一部分人去重構，一部分人依舊在老工程裡開發，經過一段時間之後，逐步將老工程的業務全部元件化，到最後老工程裡應該幾乎沒程式碼了。但是在這個期間，我們的專案工程裡可能會包含很多冗餘的程式碼、冗餘的資原始檔等，這也會導致APP的包大小增大，但這些是不可避免的。
小結
老專案元件化是一個漸進的過程，我們必須先選定一個突破口，完成一個元件之後，後面其他的業務實施元件化就會相對容易多了。我們必須控制好整個元件化實施的週期，嚴格按照計劃執行，同時要把握好新功能開發與重構之間的度。