Android元件化開發實踐（一）：為什麼要進行元件化開發？

1. 前言

三國演義裡開篇就說：天下大勢，分久必合，合久必分。我發現這話套在軟體開發上，也特別貼切。我記得我剛入門時做java後臺開發，以及後來做Android應用程式開發，剛開始都是採用中心化管理的思想，將相同的資源集中進行管理，但是做著做著，發現集中管理的資源太多了，多人開發時牽一髮而動全身，進而又要對原本的專案進行拆分，演變出什麼SOA架構、什麼微服務，以及我這裡要講的Android元件化實踐。
現在已經有了很多關於元件化開發的文章了，元件化原理很簡單，但是真正實施起來還是挺困難的。在最近這兩年的時間內，我曾經主導開發過多個採用元件化架構的APP專案，其中有對老專案進行重構的，也有一開始就採用元件化架構的新專案，在這期間踩了不少坑，也積累了不少經驗，現計劃將這些都記錄下來，對或者不對歡迎大家一起探討。

2. 單一工程開發模式遇到哪些痛點

為了便於區分，在這裡我將開發模式分為2種：一種是專案元件化開發，一種是單一工程開發模式。

• 單一工程開發模式
  顧名思義，就是一個程式碼工程(Project)對應一個APP了，這個APP的所有業務功能都是集中在同一個工程裡實現的。
• 元件化開發
  簡單來說，就是將一個APP的業務功能進行拆分，每一個功能都是一個單獨的工程，每個工程都能獨立執行，且只包含自己的業務，我們姑且叫這個獨立的功能為一個元件服務，最後整個APP由多個拆分出的元件整合而成。

已經有很多文章對什麼是元件化有更詳細的介紹了，我這裡就不贅述了。在講元件化開發的好處之前，我先以我的親身經歷來講講單一工程開發模式的痛點有哪些。

1. 對工程的任意修改除錯都要編譯整個工程，效率十分低下；
   做APP開發時，我們需要經常在手機或模擬器上進行除錯，而每次除錯都需要對整個工程進行編譯，然後安裝在手機上執行。即便你只是改了一句程式碼，或是UI調整了一個畫素點，同樣需要完整的編譯工程。當工程程式碼越來越多時，編譯也會越來越慢，你可以想象一下我修改了某句程式碼，編譯一下需要等待4、5分鐘才能成功執行的場景麼，那簡直讓人崩潰，嚴重影響了開發效率（想起曾經用eclipse開發Android時，各種轉菊花，卡頓得讓人想死的心都有）。
2. 不利於多人團隊協同開發；
   早期一個APP可能就1、2個人來開發，但是隨著業務的擴張，我們可能會發展到一個團隊來開發一個APP，少則4、5個人，多則10幾個人甚至更多。像手機淘寶、微信、支付寶這些巨無霸APP，他們的APP開發人員估計起碼有數百個。
   以10人團隊為例，如果10個人都是基於同一個工程的程式碼拉分支進行開發，每人的開發任務雖然不同，但是都能修改整個工程的任意地方。為了適應自己的需求，團隊內某人改了某句程式碼，但是這個改動又有可能影響別人的開發，這樣開發人員之間勢必要花更多的時間去溝通和協調，沒法專注自己的功能點。最後進行10個人的程式碼合併時，有過這方面經歷的人，就知道這是一件多麼痛苦的事情，解決衝突解決得你要懷疑人生。
3. 無法做到功能複用
   我曾經做過一個專案，每個開通這個業務的城市，都要做一個單獨的APP，初期我們只開通了3、4個城市，需要同時釋出3、4個APP，這些APP大概6、70%功能是相同的，但是都需要加入地方定製功能。如果你每個APP都採用單一工程模式開發，剛開始你可能每個工程都有同樣的程式碼存在，只需要複製拷貝一下就行，但是如果有需求要對這些進行修改時，你必須得每個工程都逐一修改一遍，然後每個APP都測試一遍，工作量直接翻了數倍。
4. 業務模組間耦合嚴重
   採用單一工程模式開發專案，到最後勢必會造成業務模組高度耦合，可以說是你中有我、我中有你，修改任何業務都有可能導致牽一髮而動全身，這顯然是不利於後期專案功能維護以及迭代開發的。

3. 為什麼要進行元件化開發

前面都是我在單一工程開發模式下碰到的問題，已經嚴重影響了我們團隊的開發效率以及質量，所以我才極力推崇元件化開發方式。它解決了我上面的所有痛點：

1. 極大提高工程編譯速度
   進行元件化拆分後，每個業務或者功能都是一個單獨的工程，這個單獨的工程可以獨立編譯執行，拆分後的工程通常都比較小，程式碼量也比較少，我再也不用像以前編譯一下得等待好幾分鐘了。
2. 業務模組解耦，有利於多人團隊協作開發
   業務元件之間不能相互引用，每個元件都把對應的業務功能收斂在一個工程裡，彼此互不打擾。 在多人團隊裡，每個人只負責自己的業務模組，他對業務功能的增刪改查，都只限定在自己的這個業務模組裡，不會影響其他人的業務，他程式碼質量的好壞也只會影響到自己的業務模組；對測試來說，也十分方便，大部分情況下，我們只需要著重測試修改過的業務元件即可，而不用老是進行全部迴歸測試。
3. 元件化是功能重用的基石
   業務元件類似一個個積木一樣，我們可以用積木搭建出不同的房子，同理我們也可以建立多個不同的APP。我們只需要維護好每個元件，需要用到該元件的功能時，一建引用整合就可以了。

當然，元件化並不是說只有好處沒有壞處，例如：

• 元件化開發前期可能要花費更多的時間來進行模組拆分；
• 一個人的小專案完全沒必要元件化開發，那樣只會給自己帶來更多的工作量；
• 元件化可能會帶來更多重複的程式碼；
• 元件化需要良好的架構設計，包括怎麼拆分業務，元件之間怎麼通訊等等，需要有個高水平的架構師統籌全域性，經驗不足的同學盲目進行元件化反而會適得其反，帶來更多的麻煩；

4. 小結

本文描述了單一工程開發與元件化開發的優缺點，這些都是在實際工作過程中的一些感悟。需要注意的是，我們並不要為了元件化而元件化，我們要根據實際情況來決定。如果元件化帶來的好處遠大於單一工程開發，那你就大膽使用元件化開發方案吧。

系列文章
Android元件化開發實踐（一）：為什麼要進行元件化開發？
Android元件化開發實踐（二）：元件化架構設計
Android元件化開發實踐（三）：元件開發規範
Android元件化開發實踐（四）：元件間通訊問題
Android元件化開發實踐（五）：元件生命週期管理
Android元件化開發實踐（六）：老專案實施元件化
Android元件化開發實踐（七）：開發常見問題及解決方案
Android元件化開發實踐（八）：元件生命週期如何實現自動註冊管理
Android元件化開發實踐（九）：自定義Gradle外掛