時間是來到2020年，組件化技術已經相對成熟，對其的實現思路，核心思想也基本確定，組件化已然成了一個技術公司和技術人員都應該具備的能力。
雖然組件化技術已經趨於成熟，不過對於一個項目進行組件化改革也不會是一個一蹴而就的事情。相反我認爲組件化對一個項目來說他是一個過程，是一個隨着需求和項目發展不斷改進架構和組件化程度的過程。組件化過程中一樣會面臨耦合和代碼複用的問題，這些問題的友好解決，也是組件化的價值和難點。
一個項目如果是發展的，那麼他必然面臨着如下的問題：
1.適應市場，需求越來越多，進而導致代碼越來越多，模塊間的耦合在所難免，耦合嚴重度也會隨之升高。
2.項目模塊增多，之前由2-3個人維護的代碼開始人手不足，所以變成了多人維護多個模塊。此時會出現，代碼風格多樣化，引入依賴庫多樣化，如果項目需求緊張可能存在同一功能由兩個不同的依賴實現。
3.人數多了之後，人員的變動也是時常發生的事，那麼可能就會產生同一模塊又產生代碼風格的多樣化，實現思路多樣化。這個問題繼續發展下去就是，後面再接手的人，看了下代碼，感覺哪哪都不敢改，然後想辦法不動之前的代碼，這樣的一個項目帶來的後果就是，出問題很容易，改問題很難。
4.模塊的增多，耦合的增加還會產生定位時互相推諉，你說我的模塊有問題，他說你的模塊有問題，那麼此時推斷到底是那個模塊的問題時間消耗又會增加。
5.另外可能有的項目有意識的將模塊變成了moudle，然後讓各自的人員去維護各自的moudle，這樣可以一定程度的解決互相耦合的問題，不過隨着開發的推進，模塊之間的關聯持續增加，必然會導致如基礎數據，公共訪問接口下沉，父類爲了實現子類的功能，子類將功能放到父類中，這就產生了底層的臃腫，和邏輯混雜，說的直白點就是將之前存在於個模塊的一部分耦合集合下沉了。
總之以上是五個主要的方向，實際開發這些項目的時候產生的具體問題會比這多很多，最後就是研發辛苦但是看不到成果，而且研發開銷還會逐漸增長。
所以組件化的產生可以說是一個必然，也是有充分需求下產生的技術。
組件化的核心目的是隔離，這種隔離是組件間隔離，以及組件內的隔離。他是用一些代碼和規則去保護另外一些代碼和功能，對於一個功能他實現的是“1+1”那麼組件化後他還是“1+1”，只不過他被保護了起來，不再可以直接調用。舉個具體的例子，有點像進程間通信，你能拿到的只是aidl的接口，和訪問方式，但是具體如何實現你是不知道的，也是不可見，同樣你只能使用開放出來的東西。
如果感覺組件化的概念沒有理解深入，那麼你可以把它看成在一個項目中，做應用間的通信。只是各自對應的層級下降。他的實現後的效果和aidl是十分相似的，兩個項目之間不再有任何關係彼此透明，A項目如果想訪問B項目，必須按照B項目開放出來的接口和數據結構去訪問。這就是組件化在組件間要做的事情，組件間不在有依賴關係，彼此透明，如果要互相訪問只能按照開放出來的規則去訪問。這種隔離有效的解決了組件間的耦合問題，讓問題留在組件內部。
當然組件化也不是沒有缺點的。
1.你需要用一部分代碼和規則去保護另外一部分代碼，主要體現在接口代碼的實現和編譯規則的編寫。對於編譯規則也是有一定學習成本的，當然可以輸出一個模版，有需要的時候更改模版即可。
2.引進組件化後必然會增加moudle的數量，如果只是在單一項目中通過SVN的形式去打包，會在一定的程度上增加編譯時間。這個問題也可以通過插件化的方式去解決。
3.組件間的通信是透明的，如果是通過scheme或者一些其他的方式實現的，這是有一定風險的，如果拼寫或傳參類型的錯誤都可能導致崩潰或失效。
總之最大的開銷還是在於組件化過程中，組件建立和組件對外暴露的接口與數據模型，以及建立編譯規則的實現。