نوشته های hamed seify

گریدل چه جوری جادو می کنه (شکافتن فایل های گریدل)

hamed seify — Wed, 16 Jun 2021 12:40:16 +0430

کار کردن با گریدل واسه برنامه نویسایی که تازه کار هستن کمی ترسناکه. چون خیلی باگ میده، همش باید آنلاین باشی و فیلترشکن خوب داشته باشی، چون کمی پیچیده به نظر میاد و محتواش رو نمی تونن بخونن بنابراین سعی می کنن ازش فاصله بگیرن و باهاش درگیر نشن. توی نوشته های قبلی به طور کلی گریدل رو معرفی کردیم و در مورد اینکه چه جوری فرآیند بیلد رو اتوماتیک می کنه گفتیم. اگه مطالعه نکردین می تونید به لینک زیر مراجعه کنید: https://vrgl.ir/pyKOW بعدم که زبون برنامه نویسی گرووی رو معرفی کردیم که توی گریدل استفاده میشه واسه پیاده کردن تسک های گریدل. اگه با گرووی آشنا نیستین لطفا مقاله قبلی بنده که به معرفی گرووی پرداختم رو مطالعه بفرمایید: https://vrgl.ir/1s9Z3 از اینجا به بعد می خواییم کمی موشکافانه تر به گریدل نگاه کنیم و ببینیم دقیقا چه تنظیمات و کنترل هایی برای خروجی گرفتن از پروژهای اندروید تو گریدل وجود داره.اجزای گریدل تو پروژه های اندرویدی:برای اینکه بفهمیم دقیقا گریدل چه جوری کار می کنه لازمه همه چیزایی که تو خروجی اپ ما تاثیر میذاره رو بشناسیم. یعنی اینکه علاوه بر کد کاتلین و جاوایی که نوشتیم یه سری تنظیمات توی فایل های گریدل پروژه هستن که به ما کمک می کنن تا خروجی رو کنترل کنیم. این تنظیمات عبارتند از:Built Type:بیلد تایپ شامل پارامتر های برای بیلد کردنه که گریدل استفاده می کنه. کلاژر بیلد تایپ توی فایل گریدل ماژول (مثلا app) استفاده میشه.از جمله پارامتر هاش میشه کنترل Proguard رو معرفی کرد. می تونید کلید sign کردن اپ رو هم اینجا تعریف کنید.⬇️ توی نمونه کد پایین ما یه بیلد تایپ تستی رو می بینیم:android { ... buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } ... }Product Flavor:در واقع Product Flavor ها ورژن های مختلف اپ رو تعریف می کنن اما این ورژن های مختلف به معنی نسل های اپ نیست بلکه به معنی خروجی های مختلف از اپ هست. مثالی که همیشه ازش استفاده میشه اینه که اگه اپ شما قرار باشه دو نسخه پولی و رایگان داشته باشه که کنار هم روی هر دیوایسی نصب بشن از Product Flavor استفاده میشه.به دلیل اختیاری بودن Product Flavor، به صورت پیش فرض توی گریدل نیست و اگه بهش نیاز داشته باشید باید اضافه کنید که جای اضافه کردنش توی فایل گریدل ماژول ها داخل کلاژر android هست.⬇️ تو نمونه کد پایین ما چندتا Product Flavor تستی که تعریف شدن رو می بینیم:android { ... productFlavors { demo { applicationIdSuffix ".demo" versionNameSuffix "-demo" } full { applicationIdSuffix ".full" versionNameSuffix "-full" } } }تو نمونه کد بالا نمونه تعریف Product Flavor رو می بینید که دو تا نسخه دمو و فول رو تعریف می کنه. اون پارامترها به عنوان مثال پسوند اپ آی دی و ورژن هستند برای اینکه دو تا خروجی کنار هم نصب بشن.Build Variant:بیلد ورینت در واقع محصول مشترک Build Type و Product Flavor هست که گریدل برای بیلد استفاده می کنه و برای هر دو مد دیباگ و ریلیز استفاده میشه.نکته اینه که شما مستقیما با Build Variant کار نمی کنید و در واقع این گریدل هست که برای کنترل اون از Build Type و Product Flavor استفاده می کنه. خلاصه اینکه حاصل کار با Build Type و Product Flavor میشه Build Variant.⬇️ تب Build Variant رو تو عکس پایین ببینید:توی عکس بالا، تصویر تب Build Variants رو می بینید، که ماژول app رو به صورت جدول نشون میده و توی اون ماژول 4 تا Build Variant داریم.چه جوری این اتفاق می افته؟ اول اینکه ما به صورت پیش فرض تو پروژه دو تا Build Type دیباگ و ریلیز رو داریم. از طرفی دو تا Product Flavor فول و دمو رو هم داریم، که در نتیجه این ارتباط میشه چهار تا بیلد ورینت demoDebug و demoRelease و fullDebug و fullRelease.ورودی های Manifest:اینجا با کلیت کار Manifest کاری نداریم (مثلا معرفی المان های اصلی اپ از جمله اکتیویتی ها و سرویس ها و برادکست ریسیور ها) اما با این کار داریم که Manifest شامل پارامترهایی هست که تو فرآیند بیلد اپ تاثیر میذاره. از جمله این پارامتر ها minimum SDK version و target SDK version هستن که توی Build Type هم قابل دسترس هستند.البته لازم به ذکره که اولویت مقادیر Build Type نسبت به پارامتر های Manifest بیشتر هست و کامپایلر به مقادیر Build Type ارجحیت میده. در پروژه ای که شامل چندتا منیفست باشه، تنظیمات موجود در این منیفست ها با هم merge میشن که ادامه دادنش در این مقاله نمی گنجه. ... Dependencyها:پر استفاده ترین بخش توی پروژه ها واسه ما دوولوپرا همین بخش Dependencyها هستش. بقیه قسمت های گریدل یکبار یا دوبار تنظیم میشن تو کل پروژه و دیگه تقریبا باهاشون کاری نداریم (به ندرت شاید بیشتر بشه)، هرچند بعضی پروژه ها هم اصلا مارو درگیر تنظیمات مثلا Build Type و Product Flavor نمی کنن.اما این دیپندنسی ها چیزی هستن که ما در فرآیند توسعه اپ مدام باهاشون کار داریم. اعم از فایل های jar یا لایبرری هایی که از طریق فایل سیستم به پروژه اضافه کردیم یا لایبرری هایی که از طریق آدرس ریموت به پروژه اضافه کردیم. گریدل همه رو کنترل می کنه و تو پروژه اضافه می کنه.اگه قرار بود دستی این کار رو انجام بدیم باید دونه دونه بایت کدهاشون رو دانلود می کردیم و تو پروژه جا میدادیم که فرآید خیلی اذیت کنی میشد.⬇️ نمونه کد پایین، دیپندنسی های پیش فرض تو یه پروژه جدید رو نشون میده، که تو فایل build.gradle هر ماژولی می تونه باشه:plugins { ... } android { ... } dependencies { implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version" implementation 'androidx.core:core-ktx:1.5.0' implementation 'androidx.appcompat:appcompat:1.3.0' implementation 'com.google.android.material:material:1.3.0' implementation 'androidx.constraintlayout:constraintlayout:2.0.4' implementation "androidx.drawerlayout:drawerlayout:1.1.1" testImplementation 'junit:junit:4.+' androidTestImplementation 'androidx.test.ext:junit:1.1.2' androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0' }Signing:خیلی از ماها معمولا برای خروجی گرفتن از پروژه، از منو Build توی اندروید استودیو استفاده می کنیم. هم خروجی دیباگ می گیریم (بدون ساین کردن پروژه با کلید تعریف شده خودمون) و هم خروجی ریلیز (با استفاده از کلید تعریف شده خودمون).اما با استفاده از signingConfigs هم میشه از پروژه خروجی گرفت. این تنظیمات تو کلاژر android تو فایل build.gradle ماژول اپ استفاده میشه.به این کد توجه کنید:android { ... signingConfigs { release { storeFile file("release-key.keystore") storePassword 'passwotd' keyAlias 'alias' keyPassword 'password' } } buildTypes { release { ... signingConfig signingConfigs.release } debug { debuggable true } } }تو نمونه کد بالا ما برای ساین کردن اپ کلید تعریف کردیم و کافیه که تسک assembleRelease رو تو ترمینال مثل کد پایین صدا کنیم تا از پروژه خروجی ریلیز بگیریم:./gradlew assembleReleaseخاصیت این کار اینه که کلید پروژه رو داخل خود پروژه تعریف کردیم و همیشه در دسترس هست. اما نکته منفی این کار اینه که کلید های ساین اپ در دسترس هر کسی که به کدها دسترسی داشته باشه هست و این ممکنه برای جاهایی که تیم انتشار از تیم توسعه جدا هستند مورد پذیرش نباشه.ریز کردن Code و Resource:با استفاده از تنظیمات proguard می شه به گریدل حالی کرد که موقع بیلد کردن از Rule های مختلفی برای Build Variantهای مختلف استفاده کنه. مثلا به تنظیمات زیر نگاه کنید:android { ... buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } productFlavors { flavor1 { ... } flavor2 { proguardFile 'flavor2-rules.pro' } } }اینجا ما واسه flavor2 یه فایل رول جدید تعریف کردیم که به همین شکل می تونه یه فایل متفاوت برای flavor1 تعریف بشه.پشتیبانی از APKهای مختلف:ما می تونیم توی فایل build.gradle ماژول اپ، تنظیماتی رو تعریف کنیم که اپ ما واسه چه دنسیتی (تعداد پیکسل ها توی یک اینچ مربع از صفحه نمایش) قراره استفاده بشه. مثلا xhdpi یا xxxhdpi یا غیره. بنابراین فقط از ریسورس های مناسب اون سایز تو بیلد استفاده میشه. به طور مثال به تیکه کد زیر توجه کنید:android { ... splits { density { enable true exclude "ldpi", "xxhdpi", "xxxhdpi" compatibleScreens 'small', 'normal', 'large', 'xlarge' } } }توی تیکه کد بالا که توی فایل build.gradle ماژول تعریف کردیم، با استفاده از کلاژر splits یه دنسیتی تعریف کردیم و گفتیم خروجی برای کدوم کیفیت های صفحه نمایش فعال باشه. همین طور به طور مشابه می تونیم برای نوع پردازنده هم خروجی رو فعال و غیر فعال کنیم.فایل های گریدل:تا اینجای کار تنظیمات اصلی که توی گریدل استفاده میشن برای کنترل بیلد و خروجی پروژه رو گفتیم. حالا اینجا می خواییم فایل های گریدل که تو یه پروژه اندرویدی استفاده میشن رو توضیح بدیم که چیا هستن و چه کاربردی دارن.settings.gradle:این فایل که توی روت اصلی پروژه هست، به گریدل میگه که کدوم ماژول ها توی فرآیند بیلد باید لحاظ بشن. به طور نرمال تو اکثر پروژه ها فقط ماژول اپ موجود هست، اما توی پروژه های چند ماژوله باید تو این فایل درج بشه که همه ماژول ها یا اونایی که نیاز داریم رو در نظر بگیره. مثلا محتویات داخل این فایل این شکلیه:include ':simpleModule' include ':app' rootProject.name = "root_name"من تو این پروژه به غیر از ماژول اصلی app یه ماژول دیگه به اسم simpleModule دارم که به پروژه اضافه شده و تو فرآیند بیلد میاد.build.gradle سطح ماژول:این فایل توی فولدر هر ماژولی هست و به تنظیمات مخصوص اون ماژول می پردازه، از جمله تنظیمات Build Type و Product Flavor و Proguard. تنظیماتی که تو این فایل ست میشه اگر در build.gradle پروژه هم باشه، روی اونها override میشه و برای بیلد کردن ارجحیت داره. یه نمونه تنظیمات موجود توی این فایل رو تو نمونه کد پایین آوردم. بعضی تنظیمات آوردنشون اختیاری هستش، که به productFlavors میشه اشاره کرد:apply plugin: 'com.android.application' android { compileSdkVersion 28 buildToolsVersion "30.0.2" defaultConfig { applicationId 'com.example.myapp' minSdkVersion 15 targetSdkVersion 28 versionCode 1 versionName "1.0" } buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } flavorDimensions "tier" productFlavors { free { dimension "tier" applicationId 'com.example.myapp.free' } paid { dimension "tier" applicationId 'com.example.myapp.paid' } } } dependencies { implementation project(":lib") implementation 'com.android.support:appcompat-v7:28.0.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }build.gradle سطح پروژه:این فایل هم توی روت اصلی پروژه واقع شده و به بخشی از تنظیمات گریدل اشاره داره که تو همه ماژول های پروژه یکسان هستند، از جمله ریپازیتوری های لایبرری ها و ورژن گریدل.شما می تونید توی این فایل متغییر هایی رو تعریف کنید که توی سایر بخش های پروژه به طور مشترک و global در دسترس باشن.⬇️ تیکه کد پایین یک نمونه از محتویات این فایل به همراه تعدادی متغیر گلوبال هست:buildscript { repositories { google() jcenter() } dependencies { classpath 'com.android.tools.build:gradle:4.2.0' } } allprojects { repositories { google() jcenter() } } ext { supportLibVersion = "28.0.0" }تو نمونه کد بالا یه متغیر گلوبال به اسم supportLibVersion تعریف کردم که مقدار ورژن لایبرری ساپورت رو تو خودش نگه میداره و هرجا لازم داشته باشم می تونم با صدا زدن کد نمونه زیر ازش استفاده کنم:... dependencies { implementation "com.android.support:appcompatv7: ${rootProject.ext.supportLibVersion}" }مثلا تو همه ماژولا از این لایبرری استفاده می کنم و می خوام همه جا ورژن یکسان باشه و از یکجا تغییر کنه.gradle.properties:تو این فایل تنظیمات خود گریدل از جمله سایز Heap و اینکه از اندروید استودیو استفاده بشه یا نه و jetifier فعال باشه یا نه ست میشن.local.properties:تو این فایل متغیر های محیطی که گریدل ازشون برای بیلد کردن استفاده می کنه تنظیم میشن. متغیر های محیطی از جمله آدرس SDK , NDK و CMake هستند.فرآیند Build اپ چه جوری شروع میشه:زمانی که شما دکمه Run رو تو اندروید استودیو می زنید در واقع به اندروید استودیو می گید که تسک assembleDebug رو از ماژول اصلی کانفیگ (که در اکثر مواقع همون ماژول app هست) اجرا کنه و این تسک، اول شروع می کنه به اجرای تسک هایی که پیش نیازش هستن و بعد اجرای خودش و در نهایت تسک هایی که بعد از خودش باید اجرا بشن رو اجرا می کنه.هرچند دکمه ران در کنار اجرای تسک assembleDebug یه سری آماده سازی های دیگه رو هم اجرا می کنه اما در واقع اصل قضیه شروع اجرای همین تسک هست. حالا اگه بخوایید از پروژه خروجی APK بگیرید باید تسک assembleRelease رو صدا کنید تا اجرا بشه و خروجی بده.عکس زیر کل فرآیند بیلد و ران کردن اپ رو با تمام جزئیاتش نشون میده:راهنمای عکس به قدر کافی واضحه و اینکه جهت فلش ها نشون دهنده جهت فرآیند و شروع و پایان اون هست. فرآیند بیلد اپ با چک کردن و کامپایل کردن ریسورس ها و assetها شروع میشه. بخش اول ارور هایی که موقع ران کردن اپ یا خروجی گرفتن براتون پیش میاد برای همین بخشه که مثلا یه ریسورسی ناموجوده اما صدا زده شده یا اینکه اصطلاحا ناقص و ناخواناست.بعد از ریسورس ها نوبت کلاس های جاوا و کاتلینه که به بایت کدها تبدیل بشن. اینجا هم ارور های نام آشنایی پیش میان که دیگه خودتون استادین. ارور های سینتکسی که نذاشتن سمیکالن نام آشنا ترینشون هست.بعد از کدهای جاوا و کاتلین نوبت به پروگارد کردن و پکیجینگ هست. تو این بخش ارور های مربوط به dex و proguard و obfuscate پیش میاد که مثلا ماژول ها نمی تونن باهم مچ بشن یا اینکه یه فایلی بزرگتر از سایز قابل دگز کردن هست. در نهایت هم که پکیج بدست اومده از مرحله قبل باید sign بشه که در نهایت میشه ازش استفاده و منتشر کرد.graمطالب بالا خلاصه ای از پیج خود اندروید دولوپر بود که توی لینک زیر براتون قابل دسترس هست. البته چون اندروید دولوپر مارو تحریم کرده، لینک رو همین جوری آوردم: https://developer.android.com/studio/build ممنون از اینکه وقت گذاشتین و مقاله های سری گریدل بنده رو مطالعه کردین و ممنون از اینکه با لایک هاتون منو تشویق به ادامه راه می کنید. لطفا اگه مطلبی یا سوالی مد نظرتون هست تو کامنتا برام بذارین تا در موردش صحبت کنیم.

گریدل چه جوری جادو می کنه (معرفی گرووی)

hamed seify — Mon, 31 May 2021 15:35:13 +0430

توی مقاله قبلی در مورد اینکه گریدل چه ابزار مفید و کار راه بندازی هست صحبت کردیم و اینکه اگه نخواییم از این ابزار اتوماسیون فرآیند Build استفاده کنیم باید چه مصیبتی بکشیم تا بتونیم یه Build ساده بگیریم از پروژه. اگه مقاله قبلی رو نخوندین یا با گریدل به اندازه کافی آشنایی ندارین لطفا اول مقاله قبلی رو بخونید: https://vrgl.ir/pyKOW در ادامه می خواییم در مورد اینکه گریدل چه جوری فرآیند Build اتوماتیک رو انجام بده صحبت کنیم و زبون برنامه نویسی به اسم Groovy رو معرفی کنیم که به گریدل تو این کار کمک می کنه.زبان برنامه نویس Groovyزبان برنامه نویس Groovy منطبق با Java هست که ویژگی هایی مشابه پایتون هم داره. منطبق با جاوا یعنی اینکه از روی جاوا الگوبرداری شده و بعد از کامپایل به بایت کد های جاوا تبدیل میشه. البته گرووی هم کامپایلری هست و هم اینترپرتری اما تو اندروید استودیو کامپایل میشه. Groovy به عنوان یک زبان شی گرا شناخته میشه اما خواص فانکشنال هم داره.توی اندروید استودیو از زبان گرووی برای نوشتن تسک های گریدل و فرآیندی که باید طی کنه تا از نرم افزار Build بگیره استفاده میشه.آموزش مختصر گرووی:خب ساده ترین کدی که واسه یادگیری هر زبون برنامه نویسی میشه نوشت کد نمایش Hello World! هست. پس یه تیکه کد اینجا بذاریم که Hello World! رو نمایش بده:public class Demo { public static void main(String args[]) { System.out.println("Hello World"); } }کد براتو آشنا نیست؟ بنظرتون اشتباهی کد رو تایپ کردم؟نه همه چی درسته. این تیکه کد که از قضا کاملا شبیه کد جاوا هست تو زبون گرووی عبارت Hello World! رو نمایش میده. توی پست قبلی هم گفته بودم که زبون گرووی از جاوا اقتباس گرفته و شباهت بسیار زیادی بهش داره. اما نکته ای که هست اینه که زبون گرووی می تونه خیلی ساده تر هم نوشته بشه، بدون کلاس بدون حتی متد main.مثلا کد بالا همون کاری رو می کنه که کد پایین می کنه:println "Hello World!"بدون سمیکولون و بدون پرانتز حتی. به شیوه مشابه DSL کاتلین.تعریف متغیر:توی جاوا به این صورت هست که دیتا تایپ رو مشخص می کنیم و بعد اسم متغیر رو و بعد در صورت لزوم مقدار دهی اولیه. مثلا:int age = 50; String name = "Hamed"و از طرفی جاوا به دیتا تایپ حساسه و نمی تونید مقدار استرینگ رو به متغیر با تایپ اینتیجر بدین در حالی که تو گرووی مشکلی پیش نمیاد. تعریف متغییر تو گرووی با استفاده از کلمه کلیدی def انجام میشه به شکل زیر:def age = 12توی نمونه کد بالا ما دیتا تایپ رو به صورت ضمنی مشخص نکردیم و مشکلی پیش نمیاد اگه یه مقدار با تایپ دیگه تو متغیر age بریزیم. مثلا:def age =12 age = "something"کد بالا بدون هیچ اروری اجرا میشه. اما حواستون باشه زمانی که به صورت ضمنی دیتا تایپ رو تعریف کرده باشید نمی تونید مقادیری از تایپ دیگه به متغیر بدید. مثلا کد پایین ارور تایپ کستینگ میده:int age = 44 age = "something"اینم متن ارورش:104 Caught: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'something' with class 'java.lang.String' to class 'int' org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'something' with class 'java.lang.String' to class 'int' at jdoodle.run(jdoodle.groovy:3) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Command exited with non-zero status 1می تونید استرینگ های چند خطی هم تعریف کنید با استفاده از سه تا دابل کوتیشن، مثل کد زیر:def explain = """ It is a multiline text"""تو گرووی مثل جاوا می تونید از اوپراتور های جمع و تفریق و بزرگتر کوچیکتر و تساوی و غیره استفاده کنید. دستور های حلقه و شرطی هم به همون صورت قابل استفاده هستن. امکان مضاعفی که دارید توی گرووی نسبت به جاوا تعریف حلقه ها به شیوه متفاوتی هست:0.upto(4) {println "$it"} خروجی: 0 1 2 3 4تو نمونه کد بالا ما یه حلقه تعریف کردیم با استفاده از متد upto که از 0 شروع می کنه و تا 4 رو چاپ می کنه. کار این متد اینه که از ایندکس مبدا شروع کنه و تا سقف یه بلاک کدی رو اجرا کنه، درست مثل حلقه for. یه روش دیگه استفاده از متد times هست که فقط تعداد دفعات رو می گیره و بلاک کد رو تکرار می کنه:5.times{println "$it"}تو کد بالا متد times به طور مشخص از ۰ شروع می کنه و به تعداد ۵ بار کد داخل بلاک رو اجرا می کنه.متد های upto و times هر دو با استپ های یکی یکی جلو میرن. یعنی مثلا از ۰ تا ۱۰ رو یک واحد یک واحد افزایش میدن تا حلقه اجرا بشه. حالا اگه بخواییم قدم ها رو از یک واحد یک واحد تغییر بدیم باید از متد step استفاده کنیم. متد step سینتکس و عملکردی مشابه upto داره با این تفاوت که اندازه قدم هم به عنوان پارامتر سوم توش مشخص میشه:0.step(7,2){println "$it"} خروجی: 0 2 4 6توی کد بالا متد step شروع می کنه از ۰ تا ۷ رو با اندازه قدم ۲ پیمودن و براساس اون بلاک کد رو اجرا کردن.Closuresخوب این قسمت از گرووی واسه ما دوولوپرای اندروید خیلی کاربردی میشه چون توی فایل های گریدل پروژتون نگاه کنید پر هست از کلاژر هایی که هر کدوم برای اجرای یه تسک تعریف شده. یادتون که هست توی مقاله قبلی گفتیم گریدل برای بیلد کردن نرم افزار میاد تسک تعریف می کنه و اون تسک ها رو براساس فرآیند بیلد کردنش اجرا می کنه.Closure تیکه کدی هست که داخل بلاک نوشته میشه و به یه متغیر منتسب میشه تا با صدا زدن اون متغیر اجرا بشه. عملکردش مشابه متد ها هست اما کاری که می کنه در واقع همون کاری هست که لامبدا ها تو کاتلین می کنن. تیکه کد زیر رو ببینید:def myClosure = { println "Hello World!" } myClosure()یه بلاک کدی رو تعریف کردم و به یه متغیر منتسب کردم. حالا هر بار اون متغیر رو صدا بزنم اون بلاک کد هم اجرا میشه.کلاژر ها می تونن پارامتر ورودی و مقدار بازگشتی هم داشته باشن. مثلا:def adder = { a,b-> return (a+b) } println(adder(4,7)) خروجی: 11تا اینجا یه معرفی خلاصه و کاربردی از گرووی کردیم که می خواییم تو مقاله بعدی با کمکش گریدل رو کمی بشکافیم و ببینیم چه جوری با این کد ها فرآیند بیلد کردن رو اتوماتیک می کنه.امیدوارم این مطالب براتون کاربردی و مفید بوده باشه تا اینجا. لایک یادتون نره و اگه سوالی بود تو کامنتا برام بنویسین.

اندر احوالات Gradle و Android Studio

hamed seify — Sun, 23 May 2021 15:48:39 +0430

گریدل چیه و به چه دردی می خوره؟گریدل یه ابزار اتوماتیک کردن فرآیند Build هست که تقریبا هر نرم افزاری رو میشه باهاش بیلد گرفت. مثلا فرآیند Build کردن اپلیکیشن های اندروید به این صورت هست که در شکل پایین می بینید. سورس کدها و ریسورس ها به همراه لایبرری ها و دیپندنسی ها کامپایل میشن و به یه مشت فایل DEX تبدیل میشن. بعد این فایل های DEX توسط پکیجر و با استفاده از یک کلید بسته بندی میشه که ما اون خروجی نهایی رو با پسوند .APK می شناسیم و توی دیوایس های اندرویدی مون قابل نصب و استفاده هستن.به غیر از Gradle ابزارهای دیگه ای هم هستن که کار اتوماسیون فرآیند Build رو انجام میدن اما اندروید استودیو به صورت پیش فرض با گریدل کار می کنه. از جمله این ابزار ها میشه Maven و Ant و Jenkins و Travis CI رو مثال زد که بعضی ها رایگان و بعضی ها پولی هستن.توی عکس پایین یه دیاگرام کلی از فرآیند Build و خروجی گرفتن اپ های اندرویدی می بینید:حالا گریدل این وسط چه نقشی داره و کجای قضیست اصلا؟گریدل کارش اینه که یکسری فرمان (تسک) رو دریافت می کنه و یه سری کارا رو پشت سر هم انجام میده. مثلا اگر به فایل های build.gradle توی پوشه های android و ماژول app نگاه کنید، می بینید که یکسری کد به زبون Groovyهستن. در مورد زبان گرووی و نحوه استفاده از اون توی گریدل توی پست بعدی صحبت می کنم. کار این کدها اینه که وقتی دکمه سبز رنگ Run رو میزنید یا اینکه می خوایید از پروژه خروجی بگیرید، تسک های مربوط بهشون رو انجام بدن. همین تسک هایی که بالاتر به صورت خلاصه گفتیم.مثلا اگه بخوایید فرآیند Build رو دستی (بدون استفاده از ابزار هایی مثل Gradle) انجام بدید باید این مراحل رو طی کنید:فایل های .java رو بندازید تو کامپایلر javac تا براتون کامپایل کنه و خروجی .class بده.از dx استفاده کنید تا فایل ها .class رو به فایل های .dex تبدیل کنه.یه ورژن اولیه apk از assetها و resourceها و AndroidManifest درست کنید که یه فایل با پسوند .apk.unaligned میشهاز aapt استفاده کنید تا فایل های dex رو به فایل اولیه apk اضافه کنه.از jarsigner استفاده کنید تا فایل بدست اومده رو براتون sign کنه.و در نهایت از zipalign استفاده کنید تا فایل sign شده رو به خروجی نهایی APK تبدیل کنه تا توی دیوایس های اندرویدی قابل استفاده باشه.البته من کمی کلی این قدم ها رو گفتم و هر کدوم یه ریزه کاری هایی هم داره. هدفم این بود که بگم اگر از ابزار هایی مثل Gradle استفاده نکنیم چه فرآیند سختی رو باید پشت سر بذاریم تا بتونیم خروجی بگیریم از پروژه. توی عکس پایین لاگ Build و Run کردن یک اپلیکیشن توی اندروید استودیو هست که داریم از Gradle استفاده می کنیم و تمام تسک هایی که باید انجام بشن تا خروجی اپ در بیاد رو نشون میده:ورژن های مختلف گریدل که توی اپ می بینیم چیه؟در واقع اونا ورژن های مختلف Gradle نیستن بلکه هر کدوم یک چیز جداست. شما در رابطه با گریدل دو تا دیپندنسی مختلف می بینید.اولی که ورژن خود گریل هست و از طریق Project Structure در دسترس هست به شکل زیر:دومی اما پلاگین گریدل هست که درواقع اندروید استودیو ازش استفاده می کنه تا بتونه با گریدل کار کنه. ورژن پلاگین گریدل هم از طریق Project Structure قابل دسترس هست:یه نکته ای که باید در مورد پلاگین گریدل توجه کنید و خیلی وقتا موجب باگ میشه اینه که تناسب بین ورژن گریدل و پلاگینش رو رعایت کنید. توی عکس پایین نشون میده که هر ورژن از پلاگین گریدل حداقل به چه ورژنی از گریدل احتیاج داره و اگه این تناسب رعایت نشه فرآیند بیلد شدن اصلا شروع نمیشه:مثلا ورژن های 3.6.0 تا 3.6.4 (اگه ورژنی هم بینشون بوده) نیازمند گریدل 5.6.4 به بالا هست و با ورژن های پایین تر کار نمی کنه.این جدول از لینک زیر قابل دسترس هست:برای ویرایش کردن ورژن گریدل و پلاگینش می تونید به ترتیب به فایل های gradle-wrapper.properties و build.gradle (توی روت اصلی پروژه) مراجعه کنید که توی عکس هایی پایین مشخصه:امیدوارم این مقاله خلاصه و جمع و جور باعث آشنایی بیشتر با گریدل شده باشه براتون و اینکه توی مقاله های بعدی در مورد دستکاری توی گریدل با استفاده از زبان Groovy و توضیح میدم. ممنونم از توجه و وقتی که گذاشتین.#گریدل #اندروید_استودیو #گرووی #Groovy #Build_Automation #automation #android#Gradle #Android_Studio #Java #Kotlin #آموزش #اندروید