ゼロから始まるAndroid新プロジェクト2-Gradle編
皆さんのプロジェクトはgradleを使うのはもう長いと思いますが、どうやって使いますか?ここで私のgradleスクリプトを共有して、大部分は去年6月ごろから使っています.一部の署名の安全保存は最近自分で手を出したので、自分が悪くないと思っている案をしました.
moduleタイプの区分科普小結は、Java library moduleとAndroid library moduleがどのように区別されているのかよく分からない学生もいるかもしれませんが、実はpluginの違いで、moduleのbuild.gradle:
Android application module:
Android library module:
Java library module:
バージョン番号管理はアプリケーションモジュールが1つしかないならまだしも、もし私たちが複数のモジュールを持っていたらどうしますか?バージョン番号を変更するたびに疲れませんか?
解決策はrootでグローバル変数を宣言することであり、dependency.gradleを新規作成してapply fromで参照したり、rootのbuild.gradleで直接定義したりすることができます.
サブモジュールではrootProjectを使用します.extは参照を行います:
そんなに多くのサードパーティライブラリの参照を管理することに依存して、複数のmoduleで参照して、バージョン番号を修正するのは大変で、万が一変更を漏らした(例えばgson)結果が異常な行為を招いて、原因を調べて半日調べることができなくて、結果的にキーボードを投げたのは意外にもバージョン番号の原因です.
soは、前節と同様に、依存を統一的に定義する必要があります.
ここでも個人の好みでバージョン番号を全部抽出することができますが、私の個人的な実践原則は引用が1箇所を超えない限り、定義が一緒になることです.
moduleで使用:
ここでは、leakCanaryとblockCanaryの参照を参照して、debugとrelease compileの異なるパッケージの2つのmapを定義しました.
署名管理署名は敏感なものであり,署名ファイルと対応するパスワード情報があれば,ソースコードを逆コンパイルして署名して公開することが容易であるため,これらの機密情報をどのように保存するかが重要である.
私の個人的な実践の中で、主にこのような点をしました.
local.propertiesはkeystore情報ファイルのパスを定義します.
keystore.propertiesはkeystore情報を保存します.
buildsystemで保存されています.
アプリケーションモジュールのsigningConfigs:
Java 8はAndroidに対するmoduleをサポート
Javaのmodule:
Split APK詳細はGoogleの公式ドキュメントApk Splitsをご覧ください
私の使用:
大まかに言えば,スクリプトの構成に基づいてapkをabi,densityでパケット化できる.パケットの体積を縮小するためにarmのjniフォルダを1つだけ残す必要はありません.どのように分けたいのか、いつx 86のパケットが伝わるか分かりません.また、シミュレータの中にはx 86しかサポートされていません.
もちろん、市場がこれらの構成をサポートできれば、より良いです.ユーザーがapkをダウンロードするトラフィックはずっと小さくなります.
Module aar依存は、aar依存を使用してコンパイル速度を向上させると同時に、柔軟性を兼ね備え、いつでもソースコードを修正することができますか?
解決策はmodule式aar依存である.
library moduleディレクトリの下でbuild/outputs/aarを開きます.aarファイル(コンパイルすると生成されます)がありますか?moduleディレクトリの下に置いてbuild.gradleに入れます.
元のスクリプトを注釈すれば、終わります.とても簡単ではありませんか?ソース依存を再利用したい場合は、逆コメントすればよいでしょう.
本編を総括して主に開発段階gradleの各種の実践を話して、次の編は何がしばらく私も考えがなくて、ははは.
Gradle #New Android Project From 0
moduleタイプの区分科普小結は、Java library moduleとAndroid library moduleがどのように区別されているのかよく分からない学生もいるかもしれませんが、実はpluginの違いで、moduleのbuild.gradle:
Android application module:
apply plugin: 'com.android.application'
Android library module:
apply plugin: 'com.android.library'
Java library module:
apply plugin: 'java'
バージョン番号管理はアプリケーションモジュールが1つしかないならまだしも、もし私たちが複数のモジュールを持っていたらどうしますか?バージョン番号を変更するたびに疲れませんか?
解決策はrootでグローバル変数を宣言することであり、dependency.gradleを新規作成してapply fromで参照したり、rootのbuild.gradleで直接定義したりすることができます.
project.ext {
applicationId = "com.xxx"
buildToolsVersion = "23.0.2"
compileSdkVersion = 23
minSdkVersion = 14
targetSdkVersion = 23
versionCode = 1
versionName = "1.0.0"
abortOnLintError = false
checkLintRelease = false
useJack = false
abortOnLintError = false
javaVersion = JavaVersion.VERSION_1_8
...
}
サブモジュールではrootProjectを使用します.extは参照を行います:
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
defaultConfig {
applicationId rootProject.ext.applicationId
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName
multiDexEnabled true
}
compileOptions {
sourceCompatibility rootProject.ext.javaVersion
sourceCompatibility rootProject.ext.javaVersion
}
packagingOptions {
exclude 'LICENSE.txt'
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/ASL2.0'
exclude 'META-INF/NOTICE'
exclude 'META-INF/LICENSE'
}
lintOptions {
abortOnError rootProject.ext.abortOnLintError
checkReleaseBuilds rootProject.ext.checkLintRelease
quiet true
ignoreWarnings true
// Some libraries have issues with this.
disable 'InvalidPackage'
// Lint gives this warning but SDK 20 would be Android L Beta.
disable 'OldTargetApi'
}
...
そんなに多くのサードパーティライブラリの参照を管理することに依存して、複数のmoduleで参照して、バージョン番号を修正するのは大変で、万が一変更を漏らした(例えばgson)結果が異常な行為を招いて、原因を調べて半日調べることができなくて、結果的にキーボードを投げたのは意外にもバージョン番号の原因です.
soは、前節と同様に、依存を統一的に定義する必要があります.
daggerVersion = "2.0.2"
def retrofitVersion = "2.0.0-beta4"
def supportVersion = "23.2.1"
def rxBindingVersion = '0.4.0'
def leakCanaryVersion = "1.3.1"
def blockCanaryVersion = '1.1.4'
project.ext {
...
libSupportAppcompat = "com.android.support:appcompat-v7:${supportVersion}"
libSupportDesign = "com.android.support:design:${supportVersion}"
libSupportRecyclerview = "com.android.support:recyclerview-v7:${supportVersion}"
libSupportV4 = "com.android.support:support-v4:${supportVersion}"
libRxAndroid = "io.reactivex:rxandroid:1.1.0"
libRxJava = "io.reactivex:rxjava:1.1.1"
libEventBus = "org.greenrobot:eventbus:3.0.0"
libJavaxAnnotation = "javax.annotation:jsr250-api:1.0"
libGson = "com.google.code.gson:gson:2.4"
libRetrofit = "com.squareup.retrofit2:retrofit:${retrofitVersion}"
libRetrofitConverterGson = "com.squareup.retrofit2:converter-gson:${retrofitVersion}"
libRetrofitAdapterRxJava = "com.squareup.retrofit2:adapter-rxjava:${retrofitVersion}"
libOkHttpLoggingInterceptor = "com.squareup.okhttp3:logging-interceptor:3.0.0-RC1"
libDagger = "com.google.dagger:dagger:${daggerVersion}"
libDaggerCompiler = "com.google.dagger:dagger-compiler:${daggerVersion}"
libGlide = "com.github.bumptech.glide:glide:3.7.0"
libRxBinding = "com.jakewharton.rxbinding:rxbinding:${rxBindingVersion}"
libRxBindingSupportV4 = "com.jakewharton.rxbinding:rxbinding-support-v4:${rxBindingVersion}"
libRxBindingAppcompatV7 = "com.jakewharton.rxbinding:rxbinding-appcompat-v7:${rxBindingVersion}"
libRxBindingDesign = "com.jakewharton.rxbinding:rxbinding-design:${rxBindingVersion}"
libRxBindingRecyclerview = "com.jakewharton.rxbinding:rxbinding-recyclerview-v7:${rxBindingVersion}"
libRealm = "io.realm:realm-android:0.87.5"
debugDependencies = [
leakCanary: "com.squareup.leakcanary:leakcanary-android:${leakCanaryVersion}",
blockcanary: "com.github.moduth:blockcanary-ui:${blockCanaryVersion}",
]
releaseDependencies = [
leakCanary: "com.squareup.leakcanary:leakcanary-android-no-op:${leakCanaryVersion}",
blockcanary: "com.github.moduth:blockcanary-no-op:${blockCanaryVersion}",
]
}
ここでも個人の好みでバージョン番号を全部抽出することができますが、私の個人的な実践原則は引用が1箇所を超えない限り、定義が一緒になることです.
moduleで使用:
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
...
apt rootProject.ext.libDaggerCompiler
compile rootProject.ext.libDagger
compile rootProject.ext.libRxJava
compile rootProject.ext.libRxAndroid
compile rootProject.ext.libRxBinding
compile rootProject.ext.libGlide
provided rootProject.ext.libJavaxAnnotation
compile rootProject.ext.libSupportAppcompat
compile rootProject.ext.libSupportDesign
compile rootProject.ext.libSupportRecyclerview
compile rootProject.ext.libSupportV4
debugCompile rootProject.ext.debugDependencies.leakCanary
releaseCompile rootProject.ext.releaseDependencies.leakCanary
debugCompile rootProject.ext.debugDependencies.blockCanary
releaseCompile rootProject.ext.releaseDependencies.blockCanary
}
ここでは、leakCanaryとblockCanaryの参照を参照して、debugとrelease compileの異なるパッケージの2つのmapを定義しました.
署名管理署名は敏感なものであり,署名ファイルと対応するパスワード情報があれば,ソースコードを逆コンパイルして署名して公開することが容易であるため,これらの機密情報をどのように保存するかが重要である.
私の個人的な実践の中で、主にこのような点をしました.
local.propertiesはkeystore情報ファイルのパスを定義します.
keystore.props.file=../keystore.properties
keystore.propertiesはkeystore情報を保存します.
store=../buildsystem/release.jks
alias=xxx
storePass=xxx
pass=xxx
buildsystemで保存されています.
$ ls
ci.gradle
debug.keystore
release.jks
アプリケーションモジュールのsigningConfigs:
signingConfigs {
def Properties localProps = new Properties()
localProps.load(new FileInputStream(file('../local.properties')))
def Properties keyProps = new Properties()
// 'keystore.props.file' , debug keystore
if (localProps['keystore.props.file']) {
keyProps.load(new FileInputStream(file(localProps['keystore.props.file'])))
} else {
keyProps["store"] = '../buildsystem/debug.keystore'
keyProps["alias"] = 'android'
keyProps["storePass"] = 'androiddebugkey'
keyProps["pass"] = 'android'
}
debug {
storeFile file(keyProps["store"])
keyAlias keyProps["alias"]
storePassword keyProps["storePass"]
keyPassword keyProps["pass"]
}
release {
// release assert ,
assert localProps['keystore.props.file'];
storeFile file(keyProps["store"])
keyAlias keyProps["alias"]
storePassword keyProps["storePass"]
keyPassword keyProps["pass"]
}
}
Java 8はAndroidに対するmoduleをサポート
apply plugin: 'me.tatarka.retrolambda'
android {
compileOptions {
sourceCompatibility rootProject.ext.javaVersion
sourceCompatibility rootProject.ext.javaVersion
}
}
Javaのmodule:
sourceCompatibility = 1.8
targetCompatibility = 1.8
Split APK詳細はGoogleの公式ドキュメントApk Splitsをご覧ください
私の使用:
splits { abi { enable true reset() include 'armeabi', 'x86' //, 'x86', 'armeabi-v7a', 'mips' universalApk false } }
大まかに言えば,スクリプトの構成に基づいてapkをabi,densityでパケット化できる.パケットの体積を縮小するためにarmのjniフォルダを1つだけ残す必要はありません.どのように分けたいのか、いつx 86のパケットが伝わるか分かりません.また、シミュレータの中にはx 86しかサポートされていません.
もちろん、市場がこれらの構成をサポートできれば、より良いです.ユーザーがapkをダウンロードするトラフィックはずっと小さくなります.
Module aar依存は、aar依存を使用してコンパイル速度を向上させると同時に、柔軟性を兼ね備え、いつでもソースコードを修正することができますか?
解決策はmodule式aar依存である.
library moduleディレクトリの下でbuild/outputs/aarを開きます.aarファイル(コンパイルすると生成されます)がありますか?moduleディレクトリの下に置いてbuild.gradleに入れます.
configurations.maybeCreate("default")
artifacts.add("default", file('lib_authorize-debug.aar'))
元のスクリプトを注釈すれば、終わります.とても簡単ではありませんか?ソース依存を再利用したい場合は、逆コメントすればよいでしょう.
本編を総括して主に開発段階gradleの各種の実践を話して、次の編は何がしばらく私も考えがなくて、ははは.
Gradle #New Android Project From 0