只要是包含了很多業務的客戶端，都會面臨這個問題，各個業務程式碼量越來越多，新需求又源源不斷的來，業務團隊之間要是有直接依賴，那被依賴最多的團隊成員，在改程式碼的時候都是戰戰兢兢的，生怕自己的改動導致其他業務奔潰。最終交付的時候，總會被一個業務線的人卡住，導致沒法及時交付這個版本。而且隨著程式碼量越來越多，方法數超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出來，大部分情況是然並卵，因為大部分公司的應用都沒有這麼複雜的業務。