不知道你有沒有遇到過，每次過年回家 或 相親都會遇到這樣的段子
親戚 （或未來丈母孃） : 你現在幹啥呢？我:我是做Android的，換種方式說 ，是做app、做手機應用的，就你手機上這一個個應用就是我 們做的
親戚 （未來丈母孃） : “那你能不能做個淘寶、微信啊？
面對這種疑問，我們也只能笑一笑，畢竟淘寶是200多人同時開發的結晶。經歷10多年的版本迭 代。形成了如今高性能淘寶應用，憑一人之力無法做出完整淘寶項目，當然了，我們也可以仿淘寶做做 UI界面。但做出來的殼子對技術提升來說沒有什麼意義。
這種疑問也引發我們深刻沉思，作爲專業的我們， 是怎麼實現手機淘寶的，我們應該有所瞭解。 用了什麼架構 ，接下來我們就一起來揭祕吧！
那我們就一起看看淘寶團隊是如何實現200多人一起協作開發的完整大型項目吧！
1.1 手淘項目早期遇到的問題你現在也可能遇到？
手機淘寶Android客戶端有幾百人開發，十幾個團隊。如果整個Android客戶端是一個工程，那十 幾個團隊每個人上午上班第一件事情估計就是合代碼，運氣不好，一天都在合代碼，而且只要有一個人 提交的代碼編譯不過，所有人都會被堵塞在那裏，所以單個工程是不可能的事情。
只要是包含了很多業務的客戶端，都會面臨這個問題，各個業務代碼量越來越多，新需求又源源 不斷的來，業務團隊之間要是有直接依賴，那被依賴最多的團隊成員，在改代碼的時候都是戰戰兢兢 的，生怕自己的改動導致其他業務奔潰。
最終交付的時候，總會被一個業務線的人卡住，導致沒法及時交付這個版本。而且隨着代碼量越來 越多，方法數超65535的問題也跟着到來
在手機淘寶2010年的版本 由單體項目轉成了組件化項目
1.2 爲什麼要手淘項目要實現組件化呢?
隨着從手淘APP發佈第一個版本以來，新功能的不斷增加，業務也會變的越來越複雜，從當初5個 人的Android團隊發展到現在200人的團隊規模。協作起來越來越複雜和麻煩,，每次發佈版本時真是頭 疼的問題！！！
看你的項目適不適應組件化！ 看你有沒有遇到以下幾種情況
1、實際業務變化非常快，但是單一工程的業務模塊耦合度太高，牽一髮而動全身；
2、對工程所做的任何修改都必須要編譯整個工程；
3、功能測試和系統測試每次都要進行；
4、團隊協同開發存在較多的衝突.不得不花費更多的時間去溝通和協調，並且在開發過程中，任 何一位成員沒辦法專注於自己的功能點，影響開發效率；
5、不能靈活的對業務模塊進行配置和組裝；
1.3 再來看看手淘項目組件化開發的一些優勢：
- 代碼解耦變得明顯
- 功能重用變得容易
- 團隊開發變得簡單
- 編譯速度變的更快
最關鍵的是每次發版時，不用等待某一個人提交代碼才能提交，可以快速的按照既定時間線提交
1.4 手淘組件化遇到問題，舉一個例子(如重複依賴)
重複依賴問題其實在開發中經常會遇到，早期的手淘項目也遇到了，我們來看你手淘項目組怎麼解決的呢
比如你 implementation 了一個A，然後在這個庫裏面又 implementation 了一個B，然後你的工 程中又 implementation 了一個同樣的B，就依賴了兩次。
可以將所有的依賴寫在 module中，手機淘寶在編譯過程中會走手淘的編譯插件， 所有的依賴統一 交給Groovy適配器來進行，Groovy適配器會篩選出最新版本 交給編譯插件。
組件化中還有很多類似需要解決的問題，我們該怎麼學習手機淘寶式的組件化呢?
推薦給大家一個講解組件化的視頻：www.bilibili.com/video/BV1BT…
裏面講解的技術點：
1.如何將項目組件化？
2.組件化中的核心路由框架;
3.阿里ARouter框架的分析;
4.編譯時技術實現Arouter;
大家感興趣的可以看一看；
最，最，最後我給大家分享一份從各大網絡平臺上收錄和整理的 Android學習PDF+架構視頻+面試文檔+源碼筆記 ，還有Android開發面試專題資料，高級進階架構資料供大家學習進階，希望可以幫助到大家進入大廠、拿到高薪
