"Triển khai" trong phụ thuộc của Kotlin Gradle là gì?

Question

Tôi đang sử dụng Android Studio 3.0 Preview để bắt đầu dự án Kotlin mới. Khi tôi cố gắng thêm phụ thuộc vào build.gradle Tôi đã thấy phạm vi implementation thay vì thông thường compile.

androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', { 
    exclude group: 'com.android.support', module: 'support-annotations' 
}) 
implementation 'com.android.support:appcompat-v7:25.3.1' 
testImplementation 'junit:junit:4.12' 

Cũng có phạm vi androidTestImplementation và testImplementation.

Cuối cùng, tôi thêm compile để thêm phụ thuộc bên thứ ba và nó hoạt động.

compile 'io.reactivex.rxjava2:rxandroid:2.0.1' 

Vì vậy, câu hỏi của tôi là ..

• implementation, androidTestImplementation, và testImplementation phạm vi là gì?
• Có khác biệt nào so với compile, testCompile và androidTestCompile?
• Tôi nên sử dụng cái nào cho dự án Kotlin của mình?

Chỉnh sửa: Không đúng, câu hỏi này không phải là Kotlin cụ thể. Đó là số Android Gradle Plugin configuration mới.

Answer 1

Điều này không dành riêng cho Kotlin, nhưng phải làm với plugin Gradle mới cho Android.

compile, provided và apk hiện không còn được dùng nữa.
Sử dụng implementation hoặc api thay vì compile, compileOnly thay vì provided và runtimeOnly thay vì apk.

Lý do cho việc này là tăng tốc các bản dựng nhiều mô-đun. Với mô-đun A phụ thuộc vào mô-đun B do đó phụ thuộc vào mô-đun C, thay đổi trong mô-đun C cũng sẽ kích hoạt biên dịch lại mô-đun A. Nếu A không trực tiếp sử dụng C, không cần A để biên dịch lại khi C thay đổi.

Cấu hình implementation đảm bảo chính xác này: nếu bạn chỉ định implementation project(':C') trong B, bạn không thể truy cập C từ A và bạn tránh xây dựng các module không cần thiết. Trong một dự án đa mô-đun lớn, điều này có thể tiết kiệm rất nhiều thời gian.

Xem Migrate to the new Gradle plugin để biết thêm thông tin.

Answer 2

Phiên bản trước đó của gradle v3.0.0-alpha1 được sử dụng để sử dụng compile nhưng hiện không được dùng nữa.

Tại sao?

Các phụ thuộc xuất hiện trong cấu hình compile sẽ được tiếp xúc quá mức với người tiêu dùng của thư viện và như vậy sẽ xuất hiện trên đường dẫn biên dịch của người tiêu dùng. Phụ thuộc được tìm thấy trong cấu hình thực hiện sẽ, mặt khác, không được tiếp xúc với người tiêu dùng, và do đó không bị rò rỉ vào đường dẫn biên dịch của người tiêu dùng.

Hãy lấy một ví dụ để hiểu điều này. Giả sử, tôi đã tạo một Library_Image_Upload hỗ trợ Image uploading cho máy chủ. Tôi đã sử dụng Library_Network lib trong Library_Image_Upload hỗ trợ tất cả các hoạt động mạng. Thư viện của tôi chỉ sử dụng hình ảnh tải lên và cung cấp một cách thuận tiện để tải lên hình ảnh. Bây giờ như tôi sử dụng Library_Network lib trong dự án Library_Image_Upload của tôi, tất cả mọi người sử dụng lib này sẽ có chức năng của Image Uploading cùng với tất cả các hoạt động mạng rằng ai cũng có thể sử dụng (quan trọng). Sau đó tôi nghĩ rằng có một lựa chọn tốt hơn để Library_Network là Library_Magic_Image và sử dụng nó. Vì vậy, tất cả các chức năng API được hiển thị bởi Library_Network đã biến mất và bất kỳ ai đang sử dụng các chức năng đó đều đã bị hỏng xây dựng.

implementation đi kèm với một số lợi ích:

• Dependencies không rò rỉ ra classpath biên dịch của người tiêu dùng nữa, vì vậy bạn sẽ không bao giờ vô tình phụ thuộc vào một sự phụ thuộc bắc cầu
• nhanh hơn biên soạn nhờ giảm kích thước classpath
• Ít biên dịch lại khi thay đổi phụ thuộc thực hiện: người tiêu dùng sẽ không cần phải biên dịch lại
• Xuất bản sạch hơn: khi được sử dụng cùng với plugin maven-publish mới, thư viện Java p các tệp POM của roduce phân biệt chính xác giữa những gì được yêu cầu để biên dịch đối với thư viện và những gì được yêu cầu để sử dụng thư viện lúc chạy (nói cách khác, không trộn những gì cần thiết để biên dịch thư viện và những gì cần thiết để biên dịch thư viện).

Để tìm hiểu thêm đọc The Java Library Plugin

Vì vậy, tôi nghĩ rằng bạn có câu trả lời của cả ba câu hỏi.

Tôi hy vọng điều đó sẽ hữu ích.