Cấu hình lớp thực hiện so với cấu hình API

Tôi đang cố gắng tìm ra sự khác biệt giữa apivà implementationcấu hình trong khi xây dựng các phụ thuộc của mình.
Trong tài liệu này, nó nói rằng implementationcó thời gian xây dựng tốt hơn, nhưng, khi thấy nhận xét này trong một câu hỏi tương tự tôi đã tự hỏi liệu nó có đúng không.
Vì tôi không phải là chuyên gia trong lớp, tôi hy vọng ai đó có thể giúp đỡ. Tôi đã đọc tài liệu này rồi nhưng tôi băn khoăn về một lời giải thích dễ hiểu.

compileTừ khóa Gradle không được dùng để ủng hộ apivà implementationtừ khóa để cấu hình các phụ thuộc.

Sử dụng apilà tương đương với việc sử dụng không dùng nữa compile, vì vậy nếu bạn thay thế tất cả compilebằng apimọi thứ sẽ hoạt động như mọi khi.

Để hiểu implementationtừ khóa hãy xem xét ví dụ sau.

THÍ DỤ

Giả sử bạn có một thư viện được gọi là MyLibrarybên trong sử dụng một thư viện khác được gọi InternalLibrary. Một cái gì đó như thế này:

    // 'InternalLibrary' module
    public class InternalLibrary {
        public static String giveMeAString(){
            return "hello";
        }
    }

    // 'MyLibrary' module
    public class MyLibrary {
        public String myString(){
            return InternalLibrary.giveMeAString();
        }
    }

Giả sử sử MyLibrary build.gradledụng apicấu hình dependencies{}như thế này:

dependencies {
    api project(':InternalLibrary')
}

Bạn muốn sử dụng MyLibrarymã của mình để trong ứng dụng của build.gradlebạn, bạn thêm phụ thuộc này:

dependencies {
    implementation project(':MyLibrary')
}

Sử dụng apicấu hình (hoặc không dùng nữa compile), bạn có thể truy cập InternalLibraryvào mã ứng dụng của mình:

// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

// Can ALSO access the internal library too (and you shouldn't)
System.out.println(InternalLibrary.giveMeAString());

Theo cách này, mô-đun MyLibrarycó khả năng "rò rỉ" việc thực hiện nội bộ của một cái gì đó. Bạn không nên (có thể) sử dụng nó vì nó không được bạn nhập trực tiếp.

Các implementationcấu hình đã được giới thiệu để ngăn chặn điều này. Vì vậy, bây giờ nếu bạn sử dụng implementationthay vì apitrong MyLibrary:

dependencies {
    implementation project(':InternalLibrary')
}

bạn sẽ không thể gọi InternalLibrary.giveMeAString()mã ứng dụng của mình nữa.

Loại này của chiến lược đấm bốc cho phép Android Gradle plugin để biết rằng nếu bạn chỉnh sửa một cái gì đó trong InternalLibrary, nó chỉ phải kích hoạt các biên dịch lại của MyLibraryvà không các biên dịch lại toàn bộ ứng dụng của bạn, bởi vì bạn không có quyền truy cập vào InternalLibrary.

Khi bạn có nhiều phụ thuộc lồng nhau, cơ chế này có thể tăng tốc độ xây dựng lên rất nhiều. (Xem video được liên kết ở cuối để hiểu đầy đủ về điều này)

KẾT LUẬN

• Khi bạn chuyển sang plugin Android Gradle 3.XX mới, bạn nên thay thế tất cả compilebằng implementationtừ khóa (1 *) . Sau đó thử biên dịch và kiểm tra ứng dụng của bạn. Nếu mọi thứ đều ổn, hãy để nguyên mã, nếu bạn gặp vấn đề, có thể bạn đã có vấn đề gì đó với các phụ thuộc của mình hoặc bạn đã sử dụng một cái gì đó là riêng tư và không thể truy cập nhiều hơn. Đề xuất của kỹ sư plugin Android Gradle Jerome Dochez (1 ) * )

• Nếu bạn là người quản lý thư viện, bạn nên sử dụng apicho mọi phụ thuộc cần thiết cho API công khai của thư viện, trong khi sử dụng implementationcho các phụ thuộc kiểm tra hoặc phụ thuộc mà người dùng cuối không sử dụng.

Bài viết hữu ích Thể hiện sự khác biệt giữa thực hiện và api

TÀI LIỆU THAM KHẢO (Đây là cùng một video được chia ra để tiết kiệm thời gian)

Google I / O 2017 - Cách tăng tốc độ xây dựng Gradle (VIDEO đầy đủ)

Google I / O 2017 - Cách tăng tốc độ xây dựng Gradle (CHỈ CÓ PHẦN GRADLE PLUGIN 3.0.0 MỚI)

Google I / O 2017 - Cách tăng tốc độ xây dựng Gradle (tham khảo 1 * )

Tài liệu Android

Tôi thích nghĩ về một apiphụ thuộc là công khai (được xem bởi các mô-đun khác) trong khi implementationphụ thuộc là riêng tư (chỉ được nhìn thấy bởi mô-đun này).

Lưu ý, không giống như public/ privatebiến và phương thức, api/ implementationphụ thuộc không được thi hành bởi bộ thực thi. Đây chỉ đơn thuần là tối ưu hóa thời gian xây dựng, cho phép Gradlebiết các mô-đun cần biên dịch lại khi một trong các phụ thuộc thay đổi API của nó.

Hãy xem xét bạn có appmô-đun sử dụng lib1như một thư viện và lib1sử dụng lib2như một thư viện. Một cái gì đó như thế này : app -> lib1 -> lib2.

Bây giờ khi sử dụng api lib2trong lib1, sau đó app có thể thấy lib2 mã khi sử dụng: api lib1hoặc implementation lib1trong appmô-đun.

NHƯNG khi sử dụng implementation lib2trong lib1, sau đó app không thể nhìn thấy các lib2mã.

Câu trả lời từ @matpag và @ dev-bmax đủ rõ ràng để khiến mọi người hiểu cách sử dụng khác nhau giữa thực hiện và api. Tôi chỉ muốn đưa ra một lời giải thích thêm từ một góc độ khác, hy vọng sẽ giúp cho những người có cùng câu hỏi.

Tôi đã tạo hai dự án để thử nghiệm:

• dự án Một dự án thư viện java có tên 'frameworks-web-gradle-plugin' phụ thuộc vào 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE'
• dự án B phụ thuộc vào dự án A bằng cách triển khai 'com.example.frameworks.gradle: frameworks-web-gradle-plugin: 0.0.1-SNAPSHOT'

Hệ thống phân cấp phụ thuộc được mô tả ở trên trông giống như:

[project-b] -> [project-a] -> [spring-boot-gradle-plugin]

Sau đó, tôi đã thử nghiệm các kịch bản sau đây:

1. Tạo dự án A phụ thuộc vào 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE' bằng cách thực hiện .

   Chạy gradle dependencieslệnh trong một thiết bị đầu cuối trong thư mục gốc B ject với ảnh chụp màn hình đầu ra sau đây, chúng ta có thể thấy rằng 'spring-boot-gradle-plugin' xuất hiện trong cây phụ thuộc runtimeClasspath, nhưng không phải trong compileClasspath, tôi nghĩ đó chính xác là lý do tại sao chúng ta không thể thực hiện sử dụng thư viện đã khai báo bằng cách sử dụng, nó sẽ không được biên dịch.

   

2. Tạo dự án A phụ thuộc vào 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE' của api

   Chạy gradle dependencieslệnh trong một thiết bị đầu cuối trong poject B root dir một lần nữa. Bây giờ 'spring-boot-gradle-plugin' xuất hiện cả trong cây phụ thuộc compileClasspath và runtimeClasspath.

   

Một sự khác biệt đáng kể mà tôi nhận thấy là sự phụ thuộc trong dự án nhà sản xuất / thư viện được khai báo theo cách triển khai sẽ không xuất hiện trong compileClasspath của các dự án tiêu dùng, do đó chúng tôi không thể sử dụng lib tương ứng trong các dự án tiêu dùng.

Từ tài liệu lớp :

Chúng ta hãy xem một kịch bản xây dựng rất đơn giản cho một dự án dựa trên JVM.

plugins {
    id 'java-library'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.hibernate:hibernate-core:3.6.7.Final'
    api 'com.google.guava:guava:23.0'
    testImplementation 'junit:junit:4.+'
}

thực hiện

Các phụ thuộc cần thiết để biên dịch nguồn sản xuất của dự án không phải là một phần của API được dự án đưa ra. Ví dụ, dự án sử dụng Hibernate để thực hiện lớp kiên trì nội bộ của nó.

api

Các phụ thuộc cần thiết để biên dịch nguồn sản xuất của dự án là một phần của API được dự án đưa ra. Ví dụ, dự án sử dụng Guava và hiển thị các giao diện công cộng với các lớp Guava trong chữ ký phương thức của chúng.