手機淘寶Android客戶端架構

  手機淘寶Android客戶端有幾百人開發，十幾個團隊。如果整個Android客戶端是一個工程，那十幾個團隊每個人上午上班第一件事情估計就是合代碼，運氣不好，一天都在合代碼，而且只要有一個人提交的代碼編譯不過，所有人都會被堵塞在那里，所以單個工程是不可能的事情。

    只要是包含了很多業務的客戶端，都會面臨這個問題，各個業務代碼量越來越多，新需求又源源不斷的來，業務團隊之間要是有直接依賴，那被依賴最多的團隊成員，在改代碼的時候都是戰戰兢兢的，生怕自己的改動導致其他業務奔潰。最終交付的時候，總會被一個業務線的人卡住，導致沒法及時交付這個版本。而且隨著代碼量越來越多，方法數超65535的問題也跟著到來。

     對于中型團隊，可以參考美團 團隊的做法：http://tech.meituan.com/mt-android-auto-split-dex.html， 每個業務是一個單獨的工程，打包成aar，每次發版的時候，將aar提交到maven倉庫，然后有一個Main工程，包含所有業務的aar，Main工程打包出來的就是apk。而且還通過引入MulitDexApplication，解決了方法數超限的問題。

     自然而然的，在美團的基礎上面我們可以發展出這樣一個架構，業務aar之間不允許依賴，業務如果要對外提供接口，那就提供接口jar包，在自己業務 aar里面去實現。有一個BaseCompat的項目將集成這些接口jar包，還包括一些基礎jar包，業務aar可以依賴BaseCompat aar，業務aar之間沒有依賴，這樣做的好處就是每次發版本的時候不需要等任何一個業務，某個業務沒有在截至時間內集成，就直接使用上一個穩定的版本即可。

    aar包最終會被打包成一個dex文件（或者多個dex文件，引入MulitDexApplication），但是這個解決不了手機淘寶Android客戶端的問題，手機淘寶Android客戶端底層有Atlas插件框架。通過將業務包打成awb（其實就是apk包），然后外面包一個殼工程，殼工程中包含所有的業務awb包。在手淘客戶端啟動的時候，載入各個業務的awb包，當然這個里面包括awb包解析，dex文件優化，res文件加載一系列操作。

    Atlas插件框架大概的工作原理就是：當跳轉到一個Activity的時候，看看Activity所在的awb包有沒有被加載到內存，如果沒有，那就load optDex文件，res文件。

    還在看老羅的博客：http://blog.csdn.net/Luoshengyang/article/list/1  研究一下apk包加載，Activity啟動。應該是可以做一個開源Atlas出來，大部分情況是然并卵，因為大部分公司的應用都沒有這么復雜的業務。