Gradle Implementation กับการกำหนดค่า API

ฉันพยายามคิดออกว่าอะไรคือความแตกต่างระหว่างapiและimplementationการกำหนดค่าในขณะที่สร้างการอ้างอิงของฉัน
ในเอกสารอธิบายว่ามันimplementationมีเวลาในการสร้างที่ดีขึ้น แต่เมื่อเห็นความคิดเห็นนี้ ในคำถามที่คล้ายกันฉันก็สงสัยว่ามันจริงหรือเปล่า
เนื่องจากฉันไม่มีความเชี่ยวชาญในการไล่ระดับฉันหวังว่าจะมีคนช่วย ฉันอ่านเอกสารแล้ว แต่ฉันสงสัยเกี่ยวกับคำอธิบายที่เข้าใจง่าย

compileคำหลักGradle ถูกคัดค้านapiและimplementationคำหลักเพื่อกำหนดค่าการอ้างอิง

การใช้apiจะเทียบเท่ากับการใช้ที่เลิกใช้แล้วcompileดังนั้นหากคุณแทนที่ทั้งหมดcompileด้วยapiทุกอย่างจะทำงานเหมือนเคย

เพื่อให้เข้าใจถึงimplementationคำสำคัญให้พิจารณาตัวอย่างต่อไปนี้

ตัวอย่าง

สมมติว่าคุณมีไลบรารีที่เรียกMyLibraryว่าภายในใช้ไลบรารีอื่นที่เรียกว่าInternalLibraryภายใน บางสิ่งเช่นนี้

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

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

สมมติว่าการกำหนดค่าการMyLibrary build.gradleใช้งานapiในdependencies{}ลักษณะนี้:

dependencies {
    api project(':InternalLibrary')
}

คุณต้องการใช้MyLibraryในรหัสของคุณดังนั้นในแอปของbuild.gradleคุณคุณเพิ่มการพึ่งพานี้:

dependencies {
    implementation project(':MyLibrary')
}

การใช้การapiกำหนดค่า (หรือเลิกใช้compile) คุณสามารถเข้าถึงInternalLibraryในรหัสแอปพลิเคชันของคุณ:

// 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());

ด้วยวิธีนี้โมดูลMyLibraryอาจ "รั่ว" การใช้งานภายในบางสิ่งบางอย่าง คุณไม่ควร (สามารถ) ใช้สิ่งนี้เพราะคุณไม่ได้นำเข้าโดยตรง

การimplementationกำหนดค่าได้รับการแนะนำเพื่อป้องกันสิ่งนี้ ดังนั้นตอนนี้ถ้าคุณใช้implementationแทนapiในMyLibrary:

dependencies {
    implementation project(':InternalLibrary')
}

คุณจะไม่สามารถโทรInternalLibrary.giveMeAString()ในรหัสแอพของคุณอีกต่อไป

การจัดเรียงของกลยุทธ์นี้จะช่วยให้มวย Android Gradle ปลั๊กอินที่จะรู้ว่าถ้าคุณแก้ไขในบางสิ่งบางอย่างInternalLibraryก็ต้องเรียก recompilation ของMyLibraryและไม่ recompilation ของ app InternalLibraryทั้งหมดของคุณเพราะคุณไม่ได้มีการเข้าถึง

เมื่อคุณมีการพึ่งพาที่ซ้อนกันจำนวนมากกลไกนี้สามารถเร่งการสร้างได้มาก (ดูวิดีโอที่เชื่อมโยงในตอนท้ายเพื่อความเข้าใจอย่างสมบูรณ์)

สรุป

• เมื่อคุณสลับไปใหม่ Android Gradle ปลั๊กอิน 3.XX คุณควรแทนที่ทั้งหมดของคุณcompileกับimplementationคำหลัก(1 *) จากนั้นลองรวบรวมและทดสอบแอปของคุณ หากทุกอย่างไม่เป็นไรปล่อยให้รหัสเป็นอยู่ถ้าคุณมีปัญหาคุณอาจมีบางสิ่งผิดปกติกับการอ้างอิงของคุณหรือคุณใช้สิ่งที่ตอนนี้เป็นส่วนตัวและไม่สามารถเข้าถึงได้มากขึ้น คำแนะนำโดยวิศวกรปลั๊กอินของ Android Gradle Jerome Dochez (1 ) * )

• หากคุณเป็นผู้ดูแลห้องสมุดคุณควรใช้apiสำหรับการอ้างอิงทุกครั้งที่จำเป็นสำหรับ API สาธารณะของห้องสมุดของคุณในขณะที่ใช้implementationสำหรับการทดสอบอ้างอิงหรือการอ้างอิงที่ผู้ใช้ขั้นสุดท้ายจะต้องไม่ใช้

บทความที่มีประโยชน์แสดงให้เห็นถึงความแตกต่างระหว่างการใช้งานและAPI

ข้อมูลอ้างอิง (วิดีโอนี้แบ่งออกเป็นวิดีโอชุดเดียวกันเพื่อประหยัดเวลา)

Google I / O 2017 - วิธีสร้าง Gradle ให้เร็วขึ้น (วิดีโอเต็ม)

Google I / O 2017 - Gradle สร้างความเร็วได้อย่างไร (ปลั๊กอิน GRADLE ใหม่ 3.0.0 ส่วนเท่านั้น)

Google I / O 2017 - วิธีสร้าง Gradle ให้เร็วขึ้น (อ้างอิง1 * )

เอกสารประกอบ Android

ฉันชอบคิดถึงการapiพึ่งพาเป็นสาธารณะ (มองเห็นโดยโมดูลอื่น) ในขณะที่การimplementationพึ่งพาเป็นส่วนตัว (มองเห็นได้เฉพาะโดยโมดูลนี้)

โปรดทราบว่าแตกต่างจากpublic/ privateตัวแปรและวิธีการapi/ การimplementationอ้างอิงไม่ได้บังคับใช้โดยรันไทม์ นี่เป็นเพียงการปรับให้เหมาะสมแบบ build-time ซึ่งอนุญาตให้Gradleรู้ได้ว่าโมดูลใดที่จำเป็นต้องคอมไพล์ใหม่เมื่อการพึ่งพาตัวใดตัวหนึ่งเปลี่ยน API ของมัน

พิจารณาว่าคุณมีappโมดูลที่ใช้lib1เป็นห้องสมุดและlib1ใช้lib2เป็นห้องสมุด บางสิ่งเช่นนี้: app -> lib1 -> lib2.

ตอนนี้เมื่อใช้งานapi lib2ในlib1นั้นapp จะเห็น lib2รหัสเมื่อใช้: api lib1หรือimplementation lib1ในappโมดูล

แต่เมื่อใช้implementation lib2ในlib1แล้วapp ไม่สามารถดูlib2รหัส

คำตอบจาก@matpagและ@ dev-bmaxมีความชัดเจนเพียงพอที่จะทำให้ผู้คนเข้าใจประเพณีที่แตกต่างระหว่างการใช้งานและ API ฉันแค่ต้องการอธิบายเพิ่มเติมจากมุมมองอื่นหวังว่าจะช่วยคนที่มีคำถามเดียวกัน

ฉันสร้างสองโครงการสำหรับการทดสอบ:

• โปรเจ็กต์ Aในฐานะโปรเจ็กต์ไลบรารี java ชื่อ 'frameworks-web-gradle-plugin' ขึ้นอยู่กับ 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE'
• โครงการ Bขึ้นอยู่กับโครงการ A โดยการใช้งาน 'com.example.frameworks.gradle: frameworks-web-gradle-plugin: 0.0.1-SNAPSHOT'

ลำดับชั้นการพึ่งพาที่อธิบายข้างต้นดูเหมือนว่า:

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

จากนั้นฉันทดสอบสถานการณ์ต่อไปนี้:

1. โครงการทำขึ้นอยู่กับ 'org.springframework.boot: ฤดูใบไม้ผลิบูต gradle ปลั๊กอิน: 1.5.20.RELEASE โดยการดำเนินการ

   เรียกใช้gradle dependenciesคำสั่งในเทอร์มินัลใน poject B root dir ir ที่มีสกรีนช็อตเอาท์พุทดังต่อไปนี้เราจะเห็นว่า 'spring-boot-gradle-plugin' ปรากฏขึ้นใน treeClasspath พึ่งพา runtimeClasspath แต่ไม่ใช่ใน compileClasspath การใช้ไลบรารีที่ประกาศโดยใช้การนำไปใช้จะไม่สามารถรวบรวมได้

   

2. ทำให้โครงการ A ขึ้นอยู่กับ 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE' โดยapi

   รันgradle dependenciesคำสั่งในเทอร์มินัลใน poject B root dir อีกครั้ง ตอนนี้ 'spring-boot-gradle-plugin' จะปรากฏขึ้นทั้งในทรี compileClasspath และ runtimeClasspath

   

ความแตกต่างที่สำคัญที่ฉันสังเกตเห็นคือการพึ่งพาในโครงการผู้ผลิต / ไลบรารีที่ประกาศในวิธีการใช้งานจะไม่ปรากฏใน compileClasspath ของโครงการผู้บริโภคดังนั้นเราจึงไม่สามารถใช้ lib ที่สอดคล้องกันในโครงการผู้บริโภค

จากเอกสาร gradle :

ลองมาดูสคริปต์สร้างที่ง่ายมากสำหรับโครงการที่ใช้ 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.+'
}

การดำเนินงาน

การพึ่งพาที่จำเป็นในการรวบรวมแหล่งผลิตของโครงการซึ่งไม่ได้เป็นส่วนหนึ่งของ API ที่เปิดเผยโดยโครงการ ตัวอย่างเช่นโครงการใช้ Hibernate สำหรับการนำเลเยอร์การคงอยู่ภายในมาใช้

API

การพึ่งพาที่จำเป็นในการรวบรวมแหล่งผลิตของโครงการซึ่งเป็นส่วนหนึ่งของ API ที่เปิดเผยโดยโครงการ ตัวอย่างเช่นโครงการใช้ Guava และแสดงอินเตอร์เฟสสาธารณะกับคลาส Guava ในลายเซ็นเมธอด