Android SDK開發藝術探索（七）依賴原則與打包方法

1、前言

本篇是Android SDK開發藝術探索系列的第七篇文章，也是本系列的終篇。簡單介紹了SDK開發中關於SDK開發配置、組件依賴原則、組件衝突的解決方法，探索SDK開發中的依賴原則與打包方法。html

系列文章：android

Android SDK開發藝術探索（一）開篇與設計json

Android SDK開發藝術探索（二）Exception or ErrorCodeapi

Android SDK開發藝術探索（三）初始化安全

Android SDK開發藝術探索（四）個性化配置markdown

Android SDK開發藝術探索（五）安全與校驗架構

Android SDK開發藝術探索（六）壓縮與優化app

Android SDK開發藝術探索（七）依賴原則與打包方法ide

2、基本配置

2.一、Module配置

建立一個library module這個很簡單，Android Studio直接new一個Project後，再new一個Android Library就能夠了。oop

app module用於模擬調試；library module 用於編寫SDK代碼，生成jar/aar。

library module下的build.gradle模板配置：

模板配置非所有由Android Studio自動生成，加入了一些通用的基礎的SDK開發相關配置做爲參考。要點以下：

gradle下自定義獲取當前時間的方法；
自定義混淆規則consumerProguardFiles；
顯式限定sdk支持的arm架構指令集，配置abiFilters；
gradle配置引用相對路徑下的簽名文件；
buildTypes針對編譯本module時的相關配置說明；
自動提取編譯生成的aar文件，重命名後自動複製到app module下的libs目錄，方便調試驗證與發佈SDK。

//區別於application，這意味着該module將被視爲library
apply plugin: 'com.android.library'

//自定義的一個方法，用來獲取當前時間
static def releaseTime() {
    return new Date().format("yyyy-MM-dd", TimeZone.getTimeZone("UTC"))
}

android {
    compileSdkVersion 29
    buildToolsVersion "29.0.3"

    defaultConfig {
        minSdkVersion 21
        targetSdkVersion 29
        versionCode 1
        versionName "1.0"
        consumerProguardFiles "proguard-rules.pro"//配置自定義的混淆規則，該字段下的混淆規則將做用於集成該SDK的APP
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
        ndk {
            abiFilters 'armeabi-v7a','arm64-v8a'//顯式限定sdk支持的arm架構指令集
        }
    }

    signingConfigs {
        release {
            storeFile file("../key/mylib.jks")//相對路徑下的簽名文件
            storePassword "Android_2333"
            keyAlias "key-sdk"
            keyPassword "Android_2333"
        }
    }

    buildTypes {
        release {
            minifyEnabled true
            shrinkResources false//sdk module編譯時，不支持設置shrinkResources爲true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'//編譯本module時參與混淆配置的文件
        }
        debug {
            minifyEnabled false
            shrinkResources false //sdk module編譯時，不支持設置shrinkResources爲true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'//編譯本module時參與混淆配置的文件
        }
    }

    //自動提取編譯生成的aar文件，重命名，最後自動複製到appmodule下的libs目錄，方便調試驗證。
    libraryVariants.all { variant ->
        if (variant.buildType.name == 'release') {
            variant.assembleProvider.get().doLast {
                variant.outputs.each { output ->
                    def outputFile = output.outputFile
                    if (outputFile != null && outputFile.name.endsWith('release.aar')) {
// def fileName = "${project.name}-release-${android.defaultConfig.versionName}-${releaseTime()}"
                        def outputPath = "../mylib/build/aar"
                        def libPath = "../app/libs"
                        copy {
                            from outputFile
                            into outputPath
// rename { fileName + ".aar" }
                        }
                        //直接複製到App的libs目錄下，方便調試
                        copy {
                            from outputFile
                            into libPath
                        }
                    }
                }
            }
        }
    }
}

dependencies {
    //這句話表明集引入libs目錄下的全部jar包
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation 'com.android.support:support-v4:28.0.0'
    implementation 'com.android.support:appcompat-v7:28.0.0'
}
複製代碼

2.二、如何打一個aar包

有圖有真相：

雙擊gradle腳本assembleRelease，執行正式aar編譯生成過程;
編譯完成，能夠看到outputs目錄下自動生成了一個aar文件，同時咱們的腳本也生效了，將其複製到了指定的目錄下（這裏能夠作一下自動版本命名之類的工做）

沒錯，就是這麼簡單，到這裏就生成了咱們要發佈的SDK！

3、依賴原則

3.一、儘可能避免第三方庫的依賴

在本系列開篇文章中提到了SDK開發的兩個原則：

一是：最小可用性原則，即用最少的代碼，如無必要勿增實體；二是：最少依賴性原則，即用最低限度的外部依賴，如無必要勿增依賴。

SDK開發中，須要儘可能避免依賴第三方庫，使用通用的Android SDK自帶的官方庫能知足需求便可，以避免引發沒必要要的衝突或者三方庫不要放到lib包下，默認打包進去封裝過程當中的aar二次打包問題；

好比，不要爲了一個簡單的JSON數據轉換就引入Fastjson 、Gson之類的第三方json解析轉換庫。

若是確實由於項目須要，要引入一些開源庫，能夠經過源碼集成的形式引入，再更改一下包名，避免集成衝突。

3.二、AndroidManifest無關屬性剔除

如無必要，請保證 SDK Module中的AndroidManifest 配置簡潔，剔除無關屬性，如<supports-screens、<application>標籤中的無心義字段。

3.三、SDK依賴項配置區別與原則

在 dependencies 代碼塊內，能夠配置不一樣的依賴指令，對應不一樣的編譯行爲。如compileOnly、implementation、api的介紹以及配置原則。

截圖來自：developer.android.com/studio/buil…

4、如何解決組件依賴衝突

當咱們集成的各類SDK包含相同依賴的時候，有可能產生版本衝突，此時能夠經過以下方法進行配置解決。

4.一、強制使用指定版本

grconfigurations.all {
    resolutionStrategy {
        //強制使用某些版本的依賴
        force 'com.android.support:support-v4:26.1.0','com.android.support:appcompat-v7:26.1.0'
    }
}
複製代碼

配置後查看依賴版本信息以下：

4.二、排除SDK中的指定模塊

排除某SDK下指定module的依賴

dependencies {
    implementation('some-library') {
        //排除依賴'some-library'中的指定依賴
        exclude group: 'com.android.support', module: 'support-v4'
        exclude group: 'com.android.support', module: 'appcompat-v7'
    }
}
複製代碼

排除全部SDK下指定module的依賴

android {
...
configurations.all {
    //全局排除SDk中的指定依賴
    exclude group: 'com.android.support', module: 'support-v4'
    exclude group: 'com.android.support', module: 'appcompat-v7'
}
...
}
複製代碼

5、結語

本篇簡單介紹了SDK開發與集成過程當中的依賴原則與打包方法，包括如何打包aar、基本依賴原則、組件依賴衝突的解決方法。Android SDK開發藝術探索系列到此爲止，後續可能會出一些番外篇。但願整個系列下來對你們在SDK開發或者集成中能有所啓發，感謝你們！

最後，若是本篇文檔對您的開發有所幫助或啓發，點贊/關注/分享三連就是對做者持續創做最好的激勵，感謝支持！

參考文章

版權聲明：

本文首發於個人專欄 AndDev安卓開發已受權鴻洋公衆號獨家發佈。