গ্রেডলে বাস্তবায়ন এবং সংকলনের মধ্যে পার্থক্য কী?


1024

অ্যান্ড্রয়েড স্টুডিও 3.0.০ এ আপডেট করার পরে এবং একটি নতুন প্রকল্প তৈরি করার পরে, আমি লক্ষ্য করেছি যে build.gradleসেখানে নতুন পরিবর্তনের যোগ করার একটি নতুন উপায় compileআছে implementationএবং পরিবর্তে testCompileসেখানে রয়েছে testImplementation

উদাহরণ:

 implementation 'com.android.support:appcompat-v7:25.0.0'
 testImplementation 'junit:junit:4.12'

পরিবর্তে

 compile 'com.android.support:appcompat-v7:25.0.0'
 testCompile 'junit:junit:4.12'

তাদের মধ্যে পার্থক্য কী এবং আমার কী ব্যবহার করা উচিত?

উত্তর:


1276

TL; ড

কেবল প্রতিস্থাপন করুন:

  • compileসহ implementation(যদি আপনার যদি ট্রানজিটিভিটির প্রয়োজন না হয়) বা api(আপনার যদি ট্রানজিটিভিটির প্রয়োজন হয়)
  • testCompile সঙ্গে testImplementation
  • debugCompile সঙ্গে debugImplementation
  • androidTestCompile সঙ্গে androidTestImplementation
  • compileOnlyএখনও বৈধ। এটি 3.0 এ যোগ করা হয়েছিল প্রতিস্থাপনের জন্য এবং সংকলন নয়। ( providedযখন গ্র্যাডলের সেই ব্যবহারের ক্ষেত্রে কোনও কনফিগারেশন নাম না থাকলে এবং মাভেনের প্রদত্ত স্কোপটির নাম দিয়েছিল তখন তা চালু করা হয়েছিল)

গ্রেডল 3.0.০ এর সাথে আগত এমন একটি ব্রেকিং পরিবর্তন যা গুগল আইও 17 এ ঘোষণা করেছিল

compileকনফিগারেশন করা হয় বর্তমানে অবচিত এবং দ্বারা প্রতিস্থাপিত করা উচিত implementationবাapi

থেকে Gradle ডকুমেন্টেশন :

dependencies {
    api 'commons-httpclient:commons-httpclient:3.1'
    implementation 'org.apache.commons:commons-lang3:3.5'
}

apiকনফিগারেশনে উপস্থিতি নির্ভরতাগুলি লাইব্রেরির গ্রাহকদের কাছে ক্রমবর্ধমানভাবে প্রকাশ করা হবে এবং গ্রাহকদের সংকলন শ্রেণিপথগুলিতে প্রদর্শিত হবে।

অন্যদিকে implementationকনফিগারেশনে প্রাপ্ত নির্ভরতাগুলি ভোক্তাদের কাছে প্রকাশিত হবে না এবং তাই গ্রাহকদের সংকলন শ্রেণিপথে ফাঁস হবে না। এটি বিভিন্ন সুবিধা নিয়ে আসে:

  • নির্ভরতা আর গ্রাহকদের সংকলন শ্রেণিপথের মধ্যে ফাঁস হয় না, তাই আপনি দুর্ঘটনাক্রমে কোনও ট্রানজিটিভ নির্ভরতার উপর নির্ভর করতে পারবেন না
  • ক্লাসপ্যাথ আকার হ্রাস করার জন্য দ্রুত সংকলন ধন্যবাদ
  • প্রয়োগের নির্ভরতা পরিবর্তিত হলে কম পুনঃসংশোধন: গ্রাহকদের পুনরায় সংযুক্ত করার প্রয়োজন হবে না
  • ক্লিনার প্রকাশনা: যখন নতুন মেভেন-পাবলিশ প্লাগইনের সাথে একত্রে ব্যবহৃত হয়, জাভা লাইব্রেরিগুলি পিওএম ফাইল তৈরি করে যা লাইব্রেরির তুলনায় সংকলনের জন্য প্রয়োজনীয় এবং রানটাইমের সময় লাইব্রেরিটি ব্যবহার করার জন্য যা প্রয়োজন তার মধ্যে ঠিক পার্থক্য করে (অন্য কথায়, না লাইব্রেরি নিজেই সংকলন করার জন্য কী প্রয়োজন এবং গ্রন্থাগারের বিরুদ্ধে সংকলনের জন্য কী প্রয়োজন তা মিশ্রণ করুন)।

কম্পাইল কনফিগারেশন এখনও বিদ্যমান, কিন্তু এটা গ্যারান্টী যে অফার করবে না ব্যবহার করা উচিত নয় apiএবং implementationকনফিগারেশনের প্রদান।


দ্রষ্টব্য: আপনি যদি কেবলমাত্র আপনার অ্যাপ্লিকেশন মডিউলে একটি লাইব্রেরি ব্যবহার করছেন - সাধারণ ক্ষেত্রে- আপনি কোনও তাত্পর্য লক্ষ্য করবেন না।
একে অপরের উপর নির্ভর করে মডিউলগুলি সহ আপনার কোনও জটিল প্রকল্প রয়েছে বা আপনি একটি লাইব্রেরি তৈরি করছেন তবেই আপনি পার্থক্যটি দেখতে পাবেন।


137
"ভোক্তা" কারা?
সুরগাচ

34
গ্রাহক গ্রন্থাগারটি ব্যবহার করে মডিউল। অ্যান্ড্রয়েডের ক্ষেত্রে এটি অ্যান্ড্রয়েড অ্যাপ্লিকেশন। আমি মনে করি এটি স্পষ্ট এবং আমি নিশ্চিত নই যে আপনি যা চাইছেন তা এটি কিনা।
হামাজেড

21
এটি আমার মতোই শোনাচ্ছিল। তবে আমি যদি কোনও গ্রন্থাগার তৈরি করি তবে অবশ্যই আমি চাই এটির অ্যাপ্লিকেশনটি অ্যাপটিতে প্রকাশিত হোক। অন্যথায়, অ্যাপ্লিকেশন বিকাশকারী কীভাবে আমার গ্রন্থাগারটি ব্যবহার করবেন? এজন্য implementationনির্ভরতা আড়াল করার অর্থ আমি পাই না । আমার প্রশ্নটি কি অর্থবোধ করে?
সুরগাচ

234
হ্যাঁ, এখনই এটি বোধগম্য হয় যদি আপনার অ্যাপ্লিকেশনটি লাইব্রেরি x এর উপর নির্ভর করে যা নিজেই y, z এর উপর নির্ভর করে। আপনি যদি implementationকেবল এক্স এপি ব্যবহার করেন তবে তা প্রকাশিত হবে তবে আপনি যদি apiy ব্যবহার করেন তবে zটিও প্রকাশিত হবে।
হামাজ করা হয়েছে

36
বুঝেছি! এটি এখন আরও বোধগম্য হয়। আপনি এই উত্তরটি আপনার উত্তরে যুক্ত করতে পারেন। এটি উদ্ধৃত ডকুমেন্টেশনের চেয়ে আরও স্পষ্ট।
সুরগাচ

378

এই উত্তরটি মধ্যে পার্থক্য প্রকট হবে implementation, apiএবং compileএকটি প্রকল্প নিয়ে।


ধরা যাক আমার তিনটি গ্রেডল মডিউল সহ একটি প্রকল্প রয়েছে:

  • অ্যাপ্লিকেশন (একটি অ্যান্ড্রয়েড অ্যাপ্লিকেশন)
  • মাইন্ড্রয়েডলাইবারি (একটি অ্যান্ড্রয়েড লাইব্রেরি)
  • মাইজাবালিবারি (একটি জাভা গ্রন্থাগার)

appmyandroidlibraryনির্ভরতা হিসাবে আছে । নির্ভরতা হিসাবে myandroidlibraryআছে myjavalibrary

Dependency1

myjavalibraryএকটি MySecretক্লাস আছে

public class MySecret {

    public static String getSecret() {
        return "Money";
    }
}

myandroidlibraryহয়েছে MyAndroidComponentবর্গ যে থেকে মান নিপূণভাবে MySecretবর্গ।

public class MyAndroidComponent {

    private static String component = MySecret.getSecret();

    public static String getComponent() {
        return "My component: " + component;
    }    
}

শেষ অবধি, থেকে প্রাপ্ত মানটিতে appকেবল আগ্রহীmyandroidlibrary

TextView tvHelloWorld = findViewById(R.id.tv_hello_world);
tvHelloWorld.setText(MyAndroidComponent.getComponent());

এখন, নির্ভরতা সম্পর্কে কথা বলা যাক ...

appগ্রাহক প্রয়োজন :myandroidlibrary, যাতে appbuild.gradle ব্যবহার implementation

( দ্রষ্টব্য : আপনি এপিআই / সংকলনও ব্যবহার করতে পারেন But তবে এই চিন্তাটি মুহুর্তের জন্য ধরে রাখুন))

dependencies {
    implementation project(':myandroidlibrary')      
}

Dependency2

আপনার কি মনে হয় myandroidlibrarybuild.gradle দেখতে কেমন হবে? আমাদের কোন সুযোগ ব্যবহার করা উচিত?

আমাদের তিনটি বিকল্প রয়েছে:

dependencies {
    // Option #1
    implementation project(':myjavalibrary') 
    // Option #2
    compile project(':myjavalibrary')      
    // Option #3
    api project(':myjavalibrary')           
}

Dependency3

তাদের মধ্যে পার্থক্য কী এবং আমার কী ব্যবহার করা উচিত?

সংকলন বা এপিআই (বিকল্প # 2 বা # 3) Dependency4

আপনি যদি ব্যবহার করেন compileবা api। আমাদের অ্যান্ড্রয়েড অ্যাপ্লিকেশন এখন myandroidcomponentনির্ভরতা অ্যাক্সেস করতে সক্ষম , যা একটি MySecretশ্রেণি।

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can access MySecret
textView.setText(MySecret.getSecret());

বাস্তবায়ন (বিকল্প # 1)

Dependency5

আপনি যদি implementationকনফিগারেশন ব্যবহার করে থাকেন MySecretতবে তা প্রকাশিত হয় না।

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can NOT access MySecret
textView.setText(MySecret.getSecret()); // Won't even compile

সুতরাং, আপনার কোন কনফিগারেশন চয়ন করা উচিত? এটি আপনার প্রয়োজনের উপর নির্ভর করে।

আপনি যদি নির্ভরতা প্রকাশ করতে চানapi বা ব্যবহার করুন compile

আপনি যদি নির্ভরতা প্রকাশ করতে না চান (আপনার অভ্যন্তরীণ মডিউলটি লুকিয়ে রাখছেন) তবে ব্যবহার করুন implementation

বিঃদ্রঃ:

এটি গ্রেডল কনফিগারেশনের একটি সংক্ষিপ্তসার, সারণী 49.1 দেখুন। জাভা লাইব্রেরি প্লাগইন - আরও বিশদ ব্যাখ্যার জন্য নির্ভরতা ঘোষণা করতে ব্যবহৃত কনফিগারেশন

এই উত্তরের নমুনা প্রকল্পটি https://github.com/aldoKelvianto/ImplementationVsCompile এ উপলব্ধ


1
আমি বাস্তবায়ন ব্যবহার করে একটি জার ফাইলের উপর নির্ভরতা যুক্ত করেছি, যদি এটির অ্যাক্সেসটি প্রকাশ না করা হয় তবে আমি কেন এখনও পেতে পারি এবং আমার কোডটি ঠিকঠাক কাজ করছে?
smkrn110

@ smkrn110 বাস্তবায়ন আপনার জার লাইব্রেরিটি উন্মোচিত করবে, তবে আপনার জারের নির্ভরতা লাইব্রেরিগুলিতে নয়।
aldok

2
@ বিজয়শর্মা গৃহীত উত্তরে বলা হয়েছে যে compileএকই জিনিসগুলির apiগ্যারান্টি নেই।
সাব 6 রিসোর্স

9
আমি মনে করি এটি গ্রহণযোগ্য উত্তর হওয়া উচিত। ভাল করে বুঝিয়েছি!
শশাঙ্ক ক্যাপসিম

9
@ স্টিভেন ডাব্লু.ক্ল্যাসেন এটিই আমি শুনেছি সর্বাধিক অনর্থিত ডাউনভোট। আপনি যদি মনে করেন যে তথ্যের
টিম

65

Compileকনফিগারেশন অসমর্থিত হয়েছে এবং দ্বারা প্রতিস্থাপিত করা উচিত implementationবা api

আপনি https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation এ ডক্সটি পড়তে পারেন ।

সংক্ষিপ্ত অংশ হচ্ছে-

স্ট্যান্ডার্ড জাভা প্লাগইন এবং জাভা লাইব্রেরি প্লাগইনগুলির মধ্যে মূল পার্থক্যটি হ'ল পরেরটি গ্রাহকদের কাছে উন্মুক্ত একটি এপিআই ধারণাটি প্রবর্তন করে। একটি লাইব্রেরি জাভা উপাদান যা অন্যান্য উপাদানগুলি গ্রাস করে। এটি বহু-প্রকল্পের বিল্ডগুলিতে খুব সাধারণ ব্যবহারের ক্ষেত্রে, তবে আপনার বাহ্যিক নির্ভরতা হওয়ার সাথে সাথে এটিও।

প্লাগইন দুটি কনফিগারেশন প্রকাশ করে যা নির্ভরতা ঘোষণা করতে ব্যবহার করা যেতে পারে: এপিআই এবং বাস্তবায়ন। এপিআই কনফিগারেশনটি নির্ভরতাগুলি প্রকাশ করতে ব্যবহার করা উচিত যা লাইব্রেরি এপিআই দ্বারা রফতানি করা হয়, অন্যদিকে বাস্তবায়ন কনফিগারেশনটি উপাদানটির অভ্যন্তরীণ নির্ভরতাগুলি ঘোষণা করতে ব্যবহার করা উচিত।

আরও ব্যাখ্যার জন্য এই চিত্রটি দেখুন। সংক্ষিপ্ত বর্ণনা


46

সংক্ষিপ্ত সমাধান:

compileনির্ভরযোগ্যতা সহ সমস্ত নির্ভরতা প্রতিস্থাপন করা আরও ভাল পদ্ধতির implementation। এবং কেবল যেখানে আপনি একটি মডিউল ইন্টারফেস ফাঁস, আপনি ব্যবহার করা উচিত api। এটি অনেক কম সংশোধনের কারণ হওয়া উচিত।

 dependencies {
         implementation fileTree(dir: 'libs', include: ['*.jar'])

         implementation 'com.android.support:appcompat-v7:25.4.0'
         implementation 'com.android.support.constraint:constraint-layout:1.0.2'
         // …

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

আরো ব্যাখ্যা:

অ্যান্ড্রয়েড গ্রেডল প্লাগইন 3.0.০ এর আগে : আমাদের একটি বড় সমস্যা হয়েছিল যা একটি কোড পরিবর্তনের ফলে সমস্ত মডিউল পুনরায় সংযুক্ত হয়ে যায়। এর মূল কারণ হ'ল গ্রেডল জানে না আপনি মডিউলটির ইন্টারফেসটি অন্য একটির মাধ্যমে ফাঁস করেছেন কিনা।

অ্যান্ড্রয়েড গ্রেডল প্লাগইন 3.0 এর পরে : সর্বশেষতম অ্যান্ড্রয়েড গ্রেডল প্লাগইন এখন আপনার স্পষ্টভাবে সংজ্ঞা দিতে হবে যদি আপনি কোনও মডিউলটির ইন্টারফেস ফাঁস করেন। এর ভিত্তিতে এটি কী পুনরায় রচনা করতে হবে তার উপর সঠিক পছন্দ করতে পারে।

যেমন compileনির্ভরতা হ'ল এবং দুটি নতুন দ্বারা প্রতিস্থাপন করা হয়েছে:

  • api: আপনি নিজের ইন্টারফেসের মাধ্যমে এই মডিউলটির ইন্টারফেসটি ফাঁস করেন, অর্থাত্ পুরানো compileনির্ভরতার মতো

  • implementation: আপনি কেবলমাত্র এই মডিউলটি অভ্যন্তরীণভাবে ব্যবহার করেন এবং এটি আপনার ইন্টারফেসের মাধ্যমে ফাঁস করেন না

সুতরাং এখন আপনি স্পষ্টভাবে গ্রেডলকে বলতে পারবেন কোনও ব্যবহৃত মডিউলটির ইন্টারফেস পরিবর্তন হয় বা না হলে মডিউলটি পুনরায় সংকলন করতে।

জেরোইন মোলস ব্লগের সৌজন্যে


2
পরিষ্কার এবং সংক্ষিপ্ত ব্যাখ্যা। ধন্যবাদ!
লিওন - হ্যান লি

20
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| Name               | Role                 | Consumable? | Resolveable? | Description                             |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| api                | Declaring            |      no     |      no      | This is where you should declare        |
|                    | API                  |             |              | dependencies which are transitively     |
|                    | dependencies         |             |              | exported to consumers, for compile.     |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| implementation     | Declaring            |      no     |      no      | This is where you should                |
|                    | implementation       |             |              | declare dependencies which are          |
|                    | dependencies         |             |              | purely internal and not                 |
|                    |                      |             |              | meant to be exposed to consumers.       |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| compileOnly        | Declaring compile    |     yes     |      yes     | This is where you should                |
|                    | only                 |             |              | declare dependencies                    |
|                    | dependencies         |             |              | which are only required                 |
|                    |                      |             |              | at compile time, but should             |
|                    |                      |             |              | not leak into the runtime.              |
|                    |                      |             |              | This typically includes dependencies    |
|                    |                      |             |              | which are shaded when found at runtime. |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| runtimeOnly        | Declaring            |      no     |      no      | This is where you should                |
|                    | runtime              |             |              | declare dependencies which              |
|                    | dependencies         |             |              | are only required at runtime,           |
|                    |                      |             |              | and not at compile time.                |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| testImplementation | Test dependencies    |      no     |      no      | This is where you                       |
|                    |                      |             |              | should declare dependencies             |
|                    |                      |             |              | which are used to compile tests.        |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| testCompileOnly    | Declaring test       |     yes     |      yes     | This is where you should                |
|                    | compile only         |             |              | declare dependencies                    |
|                    | dependencies         |             |              | which are only required                 |
|                    |                      |             |              | at test compile time,                   |
|                    |                      |             |              | but should not leak into the runtime.   |
|                    |                      |             |              | This typically includes dependencies    |
|                    |                      |             |              | which are shaded when found at runtime. |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| testRuntimeOnly    | Declaring test       |      no     |      no      | This is where you should                |
|                    | runtime dependencies |             |              | declare dependencies which              |
|                    |                      |             |              | are only required at test               |
|                    |                      |             |              | runtime, and not at test compile time.  |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+

প্রশ্নের সরাসরি উত্তর দেয় না
skryvets

1
এছাড়াও একটি উন্নয়নও রয়েছে কেবলমাত্র
হোহেনহেমসেনবার্গ

আমার রানটাইম এবং সংকলন উভয় সময়ের প্রয়োজন হলে আমার কী ব্যবহার করা উচিত? বর্তমানে, আমি implementationএকটি অনুসরণ করেছি runtime
মেরুন

8

সাধারণ ব্যক্তির মেয়াদে সংক্ষিপ্ত পার্থক্য হ'ল:

  • আপনি যদি এমন একটি ইন্টারফেস বা মডিউল নিয়ে কাজ করছেন যা বিবৃত নির্ভরতার সদস্যদের উদ্ভাসিত করে অন্যান্য মডিউলগুলিকে সহায়তা দেয় আপনি 'এপিআই' ব্যবহার করা উচিত।
  • আপনি যদি এমন কোনও অ্যাপ্লিকেশন বা মডিউল তৈরি করছেন যা বর্ণিত নির্ভরতা অভ্যন্তরীণভাবে প্রয়োগ করতে বা ব্যবহার করতে চলেছে, তবে 'বাস্তবায়ন' ব্যবহার করুন।
  • 'সংকলন' 'এপিআই' এর মতোই কাজ করেছে, তবে আপনি যদি কেবল কোনও লাইব্রেরি প্রয়োগ বা ব্যবহার করেন তবে 'বাস্তবায়ন' আরও ভাল কাজ করবে এবং আপনার সংস্থানগুলি সংরক্ষণ করবে।

বিবিধ উদাহরণের জন্য @ আলডোকের উত্তরটি পড়ুন।


তবে কথাটি হ'ল কোনও ব্যক্তি যদি ইচ্ছাকৃতভাবে এই প্রশ্নের উত্তর খুঁজতে এখানে আসে তবে সে সর্বোপরি একজন সাধারণ মানুষ নয়।
isষভ

6

সংস্করণ 5.6.3 যেহেতু গ্রেডল ডকুমেন্টেশন একটি পুরানো compileনির্ভরতা (বা একটি নতুন) একটি implementationবা apiনির্ভরতার সাথে প্রতিস্থাপন করা উচিত কিনা তা সনাক্ত করার জন্য থাম্বের সহজ নিয়ম সরবরাহ করে :

  • সম্ভব হলে implementationকনফিগারেশনটি পছন্দ করুনapi

এটি নির্ভরতা গ্রাহকের সংকলন শ্রেণিপথ থেকে দূরে রাখে। এছাড়াও, গ্রাহকরা তাত্ক্ষণিকভাবে কোনও এপ্লিকেশন ধরণের জনসাধারণের API এ ফাঁস হলে সংকলন করতে ব্যর্থ হবে।

সুতরাং আপনি কখন apiকনফিগারেশন ব্যবহার করা উচিত ? একটি API নির্ভরতা হ'ল লাইব্রেরির বাইনারি ইন্টারফেসে প্রকাশিত হওয়া কমপক্ষে একটি প্রকার থাকে যা প্রায়শই তার এবিআই (অ্যাপ্লিকেশন বাইনারি ইন্টারফেস) হিসাবে পরিচিত। এর মধ্যে অন্তর্ভুক্ত রয়েছে তবে সীমাবদ্ধ নয়:

  • সুপার ক্লাস বা ইন্টারফেসে ব্যবহৃত প্রকারগুলি
  • জেনেরিক প্যারামিটারের প্রকারগুলি সহ সর্বজনীন পদ্ধতি পরামিতিগুলিতে ব্যবহৃত ধরণের (যেখানে জনসাধারণ এমন কিছু যা সংকলকদের কাছে দৃশ্যমান I
  • প্রকারগুলি সর্বজনীন ক্ষেত্রে ব্যবহৃত হয়
  • পাবলিক টীকা টাইপ

বিপরীতে, নিম্নলিখিত তালিকায় ব্যবহৃত কোনও প্রকার এবিআইয়ের কাছে অপ্রাসঙ্গিক, এবং তাই implementationনির্ভরতা হিসাবে ঘোষণা করা উচিত :

  • প্রকারের দেহগুলিতে একচেটিয়াভাবে ব্যবহৃত types
  • প্রাইভেট সদস্যদের একচেটিয়াভাবে ব্যবহৃত
  • প্রকারভেদগুলি অভ্যন্তরীণ ক্লাসগুলিতে একচেটিয়াভাবে পাওয়া যায় (গ্র্যাডেলের ভবিষ্যতের সংস্করণগুলি আপনাকে ঘোষণা করতে দেয় যে কোন প্যাকেজগুলি পাবলিক এপিআইয়ের অন্তর্ভুক্ত)

6

Gradle 3.0 পরবর্তী পরিবর্তনগুলি চালু করা হয়েছে:

  • compile -> api

    api মূলশব্দ হ্রাস করা হিসাবে একই compile

  • compile -> implementation

    সবচেয়ে ভাল উপায় কারণ কিছু সুবিধা আছে। নির্ধারিত সময়ে implementationকেবলমাত্র এক স্তরের জন্য নির্ভরতা প্রকাশ করুন (নির্ভরতা রানটাইম এ উপলব্ধ)। ফলস্বরূপ আপনার একটি দ্রুত বিল্ড (গ্রাহকদের পুনরায় সংকলনের প্রয়োজন নেই যা 1 স্তরের উপরে যা উচ্চতর)

  • provided -> compileOnly

    এই নির্ভরতা কেবল সংকলন সময়ে পাওয়া যায় (নির্ভরতা রানটাইম এ উপলব্ধ না)। এই নির্ভরতা ট্রানজিটিভ এবং হতে পারে না .aar। এটি সংকলন সময় টীকা প্রোটেসরের সাথে ব্যবহার করা যেতে পারে এবং আপনাকে একটি চূড়ান্ত আউটপুট ফাইল হ্রাস করতে দেয়

  • compile -> annotationProcessor

    খুব অনুরূপ compileOnlyতবে গ্যারান্টি দেয় যে ট্রানজিটিভ নির্ভরতা ভোক্তার জন্য দৃশ্যমান নয়

  • apk -> runtimeOnly

    নির্ভরতা সংকলন সময়ে পাওয়া যায় না তবে রানটাইম এ উপলব্ধ।


তাই অন্য কথায়, api = public, implementation = internalএবং compileOnly = private- আমি এই কাজগুলির জন্য যেমন alias লেখা তৈরি করতে তারা সুপার বিভ্রান্তিকর হয় প্রয়োজন।
t3chb0t
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.