android打包之重疊包技術淺談

轉載請註明出處
http://blog.csdn.net/BruceHurrican/article/details/51755194

一個app經過幾個大版本迭代後都會遇到一個問題，越來越臃腫，但是本文不是講怎樣給app瘦身的方法。本文僅當本人之工作手記罷了。主要記錄我在項目中遇到的問題及解決辦法。

先說問題吧。業務需要將現有app中部分組件單獨抽出作爲公共組件和商業組件分別提供給公司內部其他app使用和潛在合作方使用。

之前準備採用類似友盟的多渠道打包技術，主要是修改app.gradle中的productFlaors函數（相關技術方法請參考網上資料），而我和同事在項目中用到的是重疊包技術和多渠道打包技術，其在工程中的分包結構和多友盟多渠道打包技術很像。

代碼如下：

app.gradle
productFlavors {
        tt {
            applicationId 'com.bruce.demo.tt'
            minSdkVersion 15
            targetSdkVersion 23
            signingConfig signingConfigs.release
        }
        tt2 {
            applicationId 'com.bruce.demo.tt2'
            minSdkVersion 15
            targetSdkVersion 23
            signingConfig signingConfigs.debug
        }
    }

這主要是根據productFlavors來打多渠道包，用在我的項目是需求爲通過設置productFlavor來將打公共組件包、潛在合作方包、項目自用包。剛開始我是按照這個思路來進行的，但是隨着工作的進行，發現將要抽離的組件與其他module之間的耦合性太高，代碼之間的侵入性太強抽離難度太大，無奈此種方案在經過技術論證後，不適合當前公司複雜的app 架構，放棄。

此路不通只能另闢蹊徑了，通過查 gradle資料 發現可以通過增加buildTypes來增加構建類型，buildTypes 按照字面中文翻譯不正是構建類型嗎？之前居然沒有注意到T_T。

dmeo工程目錄如下：

blue 和 red 就是我要的兩個具有各自獨立業務的模塊，可以理解爲上面的公司用組件和潛在合作方組件。

關鍵代碼如下：

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            minifyEnabled false
            shrinkResources true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        blue {
            applicationIdSuffix 'blue'
            versionNameSuffix 'blue'
        }
        red {
            applicationIdSuffix 'red'
            versionNameSuffix 'red'
        }
    }

通過AS上的 BuildVariants 在types之前切換

這樣就可以打出多個包了並進行相應的代碼修改，如果設置多BuildTypes不是app工程而是一個lib的話，即此lib要根據不同的需求提供給不同的業務方，一個一個切換再打包是很麻煩的，可以通過gradle腳本來生成相應的lib包，

也可以通過輸入命令

gradle assembleBlue
gradle assembleRed

注意

• 通過AS這種方法生成的是aar包，關於aar在AS的使用此文略去不表。
• 作爲公共入口LibActivity在主目錄即main文件夾下不能存在否則報錯。
• 如果各業務模塊使用各自的依賴則應在申明中分別申明不應籠統的申明爲compile以免增大安裝包的體積
  

到此，通過增加buildtypes的方法來達到生成不同需求的app/lib的要求已經達到了，各個業務需求可以在相應的blue、red下去實現。

小結如下：

• 如果需要替換相同資源如首發icon圖片，字段名，可以考慮多渠道打包技術，各個模塊之間沒有代碼侵入或者侵入性低。
• 如果業務模塊blue、red對main目錄下的代碼依賴性強，並且有引用到其他模塊的話，非業務模塊間有相互依賴的話，考慮使用重疊包技術。

demo下載
如果文中有什麼不對的地方或者您有更好的建議歡迎不吝賜教。