1、前言
元件化就是基於可重用的目的，將一個大的軟體系統按照分離關注點的形式，拆分成多個獨立的元件，以較少耦合、提升長遠收益。
在之前我的一篇文章中，提到過關於元件化的一些概念，可以參考《GMTC移動開發者大會紀實（二）元件化只是一句口號嗎》。接下來的幾篇文章，主要會寫下我們團隊實施元件化的一些經歷。
2、元件化原因
對於元件化，簡單的說就是專案逐步變大過程中的必由之路。
在準備做元件化之前，隨著逐步迭代現有專案結構暴露了一些問題：
- 程式碼整體結構混亂、缺少層次；
- 耦合嚴重，程式碼邊界不清晰；
- 龜速編譯，開發體驗極差；
- 無法很好的支援A/BTest；
- 每次發版在QA迴歸上耗時很久；
正是因為這些問題，我們才逐漸規劃了元件化。當然同時需要強調的是專案架構、開發模式等都不會一直存在最優解，架構、開發模式的選擇和專案所處階段、團隊規模、業務場景等息息相關，畢竟在業務剛起步打量的階段和精細化運營階段團隊的重心是不一樣的。
3、正確認識元件化
現如今網上已經有很多元件化思路、實踐等文章了，但是有必要提一下的是對元件化首先需要正確認識：
- 何時實施元件化以及元件化的具體方案等都需要結合專案所處階段、團隊規模等來決斷；
- 元件化不是炫技術，不是故弄玄虛；網上有文章講普通的元件化實現竟然有“難點在於解決跨程式通訊”，坦白的說這種就屬於自己強行給自己提升B格了（忽悠到小白那真是MMP了）；
- 傳統意義上的元件化和外掛化是兩條路：元件化發生在開發階段、外掛化發生在執行階段；
- 縱然二者可以結合，但是獨立元件對絕大多數App難有使用場景；
- 元件如果在執行階段不是在自己獨立的程式，那必然是拉B格無疑；
- 說好的元件化卻又去扯動態化也是拉B格無疑；
4、元件化思路
首先對於元件分為兩類：技術元件和業務元件；而元件化具體的思路也一定要和自己的使用場景相結合：
- 對於技術元件，合理封裝，注意不要放在一起，避免技術元件庫巨大無比；
- 對業務元件，可選擇自己依賴的技術元件夠業務元件單獨執行即可；
- 對於獨立元件，這種場景相對較少，一般見於一個模組需要執行於多個APP裡（在自己單獨的程式）；
對於我們的元件化，我們首先需要的是模組之間的解耦，形式就是各個Module自己能跑起來，因而我們的思路更偏向於前兩種。
5、元件化實施過程
實施過程描述起來相對簡單，但是實踐過程其中酸爽只有經歷才會明白這是一段血淚史。具體過程在下篇講，此處只簡述；
- 對於技術元件需要合理封裝，減少之後可能存在的替換成本；
- 同時注意，將技術元件分為常用和非常用，可以選擇自己需要的技術元件，避免一個統一的技術元件庫過大；
- 將業務程式碼根據模組進行剝離，剝離成一個個的小模組；
- 單獨的業務模組加上必要的技術元件，支撐在開發階段的獨立執行；
6、元件化實施難點
- 技術元件的整理、抽離；
- 一定要有的DisPatcher：提供隱式的跳轉和模組間方法呼叫能力；
- 元件的劃分；
- 除錯及整合方式；
本文主要講元件化的緣由、思路、難點等，有個概念就好；具體的實踐過程、難點解決及方案思考在下篇文章，歡迎關注！
歡迎關注微信公眾號：定期分享Java、Android乾貨！
