Преимущество «реализации» в build.gradle - PullRequest
0 голосов
/ 31 декабря 2018

Скажем, у меня есть проект ProjectA, содержащий ClassInProjectA, который я встроил в .aar.У меня также есть проект, ProjectB, который использует ClassInProjectA для внутреннего использования.

public class ClassInProjectB {
    public ClassInProjectB() {
        new ClassInProjectA();
    }
}

build.gradle из ProjectB выглядит следующим образом:

android {
    compileSdkVersion 28
    defaultConfig {
        minSdkVersion 15
        targetSdkVersion 28
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation(name:'projA', ext:'aar')
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

Я использую реализацию, потому что ClassInProjectA используется только внутреннепо ProjectB.

У меня есть основное приложение, и я хочу использовать ClassInProjectB.Build.gradle основного приложения выглядит следующим образом:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 28
    defaultConfig {
        applicationId "com.example.project.projectc"
        minSdkVersion 15
        targetSdkVersion 28
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation(name:'projB', ext:'aar')
    implementation(name:'projA', ext:'aar')

    implementation 'com.android.support:appcompat-v7:28.0.0'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

projB необходимо импортировать явно, или я не могу создать ClassInProjectB из-за требования ClassInProjectA.

Все хорошо,все компиляции и ClassInProjectB могут быть построены.

Если build.gradle ProjectB изменен так, что projA является требованием API:

api(name:'projA', ext:'aar')

ничего не меняется в build.gradle основногоapp.

В чем преимущество ключевого слова реализации в этом контексте?Просто ли это позволяет мне заменить ProjectB в основном приложении и избежать повторной компиляции Project A?

Я также немного смущен этим постом и этот , каждый из которых подразумевает, что основному проекту вообще не нужно неявно импортировать ProjectA, если ProjectB зависит от ProjectA через ключевое слово api.Я что-то не так понял? edit: кажется, что это имеет место, только если зависимости находятся через субмодули в одном проекте, а не экспортируются .aar .

1 Ответ

0 голосов
/ 01 января 2019

В чем преимущество ключевого слова реализации в этом контексте?Просто ли это позволяет мне заменить ProjectB в основном приложении и избежать повторной компиляции проекта A?

Единственное преимущество ключевого слова реализации и причина его появления -что он может избежать полной перестройки проекта. Этот блог пост делает большую работу по объяснению деталей.Подводя итог, если: projectA имеет реализацию зависимость от: projectB, то: projectA only необходимо перекомпилировать, если изменяется интерфейс: projectB.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...