نوشته های هادی دهقانی

درک تفاوت launch و async در Kotlin Coroutines

هادی دهقانی — Sat, 20 Sep 2025 15:47:04 +0330

تفاوت launch و asyncمقدمهاگر توسعه‌دهنده اندروید هستید، احتمال زیاد با این صحنه‌ها روبه‌رو شده‌اید: صفحه‌ای که بارگذاریش کُند است، درخواست شبکه‌ای که UI را قفل می‌کند، چند فراخوانی API که انگار قرار نیست تمام بشوند، یا یک کار پس‌زمینه که انیمیشن‌های نرم و روان شما را لگ‌دار می‌کند. آشناست؟ 😅 خیالتان راحت، تنها نیستید. همین‌جاست که Kotlin Coroutines — و به‌خصوص درک تفاوت بین launch و async — وارد میدان می‌شوند و می‌توانند بازی را برای عملکرد اپ شما عوض کنند.ماجرا از کجا شروع شد؟ماه پیش، روی یک اپلیکیشن شبکه اجتماعی کار می‌کردم. توی صفحه پروفایل باید هم اطلاعات کاربر و هم پست‌های اخیرش نمایش داده می‌شد. کد ساده و اولیه این بود:class ProfileViewModel : ViewModel() { fun loadProfile(userId: String) { viewModelScope.launch { val user = userRepository.getUser(userId) // ۱ ثانیه طول می‌کشد val posts = postRepository.getPosts(userId) // ۱ ثانیه طول می‌کشد // مجموعاً: ۲ ثانیه _profileState.value = ProfileState(user, posts) } } }نتیجه؟ کاربر باید ۲ ثانیه کامل فقط منتظر می‌ماند تا پروفایلش بالا بیاید. نه فاجعه است، نه خیلی خوب. بدتر این که این دو درخواست API اصلاً به هم ربطی نداشتند و می‌شد آن‌ها را هم‌زمان اجرا کرد.اینجاست که دانستن فرق launch و async می‌تواند معجزه کند.تفاوت اصلی launch و asyncقبل از این که برویم سراغ تکنیک‌ها، بیایید اول خیلی ساده بفهمیم هر کدام چه کار می‌کنند.launch — کارگر «بفرست و ولش کن»launch را تصور کنید مثل این که یک نفر را برای انجام کاری بفرستید ولی انتظار نداشته باشید گزارشی برگرداند. کار خودش را می‌کند و تمام. شما هم رسید کاری که داده‌اید (یک Job) را می‌گیرید و سراغ کار خودتان می‌روید.val job = launch { performBackgroundTask() updateDatabase() // هیچ مقدار بازگشتی وجود ندارد }ویژگی‌ها:یک Job برمی‌گرداندهیچ مقداری برنمی‌گرداندبرای کارهایی که فقط اثر جانبی دارند و خروجی مهم نیست، عالی استasync — کارگر «قول نتیجه»async را تصور کنید مثل استخدام یک مشاور که حتماً می‌خواهید بعد از بررسی‌اش گزارش کامل بدهد. وقتی async را صدا می‌زنید، یک وعده نتیجه آینده (Deferred) می‌گیرید، بعد هر وقت خواستید می‌توانید با await() نتیجه را بگیرید.val deferred = async { calculateComplexValue() } val result = deferred.await()ویژگی‌ها:یک Deferred برمی‌گرداندبا await() می‌توانید مقدار خروجی را بگیریدهم‌زمانی را راحت می‌کند (کارهای موازی)کجا launch و async را استفاده کنیم؟سناریو ۱: سریع‌تر کردن راه‌اندازی اپفرض کنید هنگام باز شدن اپ باید سه کار انجام شود: بارگذاری تنظیمات کاربر، چک کردن آپدیت، و همگام‌سازی داده‌ها.❌ روش کند (ترتیبی): هر کدام بعد از دیگری اجرا می‌شوند.class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleScope.launch { loadUserPreferences() // 500 میلی‌ثانیه checkForUpdates() // 800 میلی‌ثانیه syncUserData() // 1200 میلی‌ثانیه کل: 2.5 ثانیه } } } ✅ روش سریع (هم‌زمان): همه با هم اجرا می‌شوند و فقط طولانی‌ترینشان زمان کلی را تعیین می‌کند.class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleScope.launch { val prefsDeferred = async { loadUserPreferences() } val updatesDeferred = async { checkForUpdates() } val syncDeferred = async { syncUserData() } // همه به طور همزمان اجرا می‌شوند، زمان کل: ~1.2 ثانیه val prefs = prefsDeferred.await() val updates = updatesDeferred.await() val syncResult = syncDeferred.await() initializeApp(prefs, updates, syncResult) } } }سناریو ۲: ساخت فید خبری سریع‌تراگر همزمان مقالات، اطلاعات کاربر و تبلیغات را دریافت کنیم، به‌جای ۳ ثانیه، کمتر از ۱ ثانیه طول می‌کشد.class NewsFeedViewModel : ViewModel() { fun loadFeed() { viewModelScope.launch { try { // همه عملیات را به طور همزمان شروع کن val articlesDeferred = async { newsRepository.getLatestArticles() } val userDeferred = async { userRepository.getCurrentUser() } val adsDeferred = async { adRepository.getTargetedAds() } // منتظر همه نتایج باش val articles = articlesDeferred.await() val user = userDeferred.await() val ads = adsDeferred.await() // نتایج را ترکیب کن val feedData = FeedData(articles, user, ads) _feedState.value = FeedState.Success(feedData) } catch (e: Exception) { _feedState.value = FeedState.Error(e.message) } } } }اشتباهات رایجاستفاده از launch وقتی به نتیجه نیاز داریم → باید async باشد.// ❌ اشتباه - تلاش برای گرفتن نتایج از launch fun fetchUserData(): User? { var user: User? = null launch { user = userRepository.getUser() // این طور که انتظار دارید کار نمی‌کند } return user // همیشه null خواهد بود } // ✅ درست - استفاده از async برای نتایج suspend fun fetchUserData(): User { return async { userRepository.getUser() }.await() }صدا زدن زودهنگام await() که باعث می‌شود هم‌زمانی از بین برود.// ❌ عدم استفاده از همزمانی suspend fun loadData() { val user = async { getUserData() }.await() val posts = async { getPostsData() }.await() // اینها به صورت ترتیبی اجرا می‌شوند، هدف را از بین می‌برد } // ✅ اجرای همزمان مناسب suspend fun loadData() { val userDeferred = async { getUserData() } val postsDeferred = async { getPostsData() } val user = userDeferred.await() val posts = postsDeferred.await() }فراموش کردن مدیریت استثناء‌ها در کارهای هم‌زمان.// ❌ مدیریت ناکامل خطا viewModelScope.launch { val result1 = async { riskyOperation1() } val result2 = async { riskyOperation2() } // اگر result1.await() خطا پرتاب کند، result2.await() هرگز فراخوانی نمی‌شود val data1 = result1.await() val data2 = result2.await() } // ✅ مدیریت مناسب استثناء viewModelScope.launch { try { val result1 = async { riskyOperation1() } val result2 = async { riskyOperation2() } val data1 = result1.await() val data2 = result2.await() // مدیریت موفقیت } catch (e: Exception) { // مدیریت هر گونه شکست } }چه وقت از کدام استفاده کنیم؟از launch استفاده کنید وقتی:فقط کارهای «آتش و فراموش کن» انجام می‌دهید (مثل لاگ کردن، کش کردن)خروجی برایتان مهم نیستاز async استفاده کنید وقتی:به داده خروجی نیاز داریدچند عملیات مستقل دارید که می‌خواهید موازی اجرا شوندنکات پیشرفتهاز coroutineScope برای گروه‌بندی چند کار هم‌زمان استفاده کنیدsuspend fun loadCompleteProfile() = coroutineScope { val basicInfo = async { userRepository.getBasicInfo() } val preferences = async { userRepository.getPreferences() } val statistics = async { userRepository.getStatistics() } ProfileData( basic = basicInfo.await(), prefs = preferences.await(), stats = statistics.await() ) }برای عملیات طولانی withTimeout بگذاریدsuspend fun loadDataWithTimeout() = withTimeout(5000) { val data1 = async { fetchData1() } val data2 = async { fetchData2() } CombinedData(data1.await(), data2.await()) }برای مجموعه‌ای از کارها از awaitAll() استفاده کنیدsuspend fun loadMultipleUsers(userIds: List): List { return userIds.map { userId -> async { userRepository.getUser(userId) } }.awaitAll() }نتیجه‌گیریتفاوت launch و async فقط یک قاعده فنی نیست — مستقیماً روی تجربه کاربری تاثیر می‌گذارد. کاربر شاید نداند شما از coroutine استفاده کرده‌اید، اما قطعاً حس می‌کند وقتی صفحه به جای ۳ ثانیه، در ۱ ثانیه لود می‌شود.یادتان باشد:launch برای کارهایی که نتیجه لازم نداریدasync برای مواقعی که نتیجه می‌خواهید یا می‌توانید کارها را همزمان انجام دهیدخطاها را حتماً مدیریت کنیدawait() را آخر کار صدا بزنید

انتخاب هوشمندانه Dispatcher در Kotlin Coroutines

هادی دهقانی — Fri, 12 Sep 2025 12:17:52 +0330

Smart Dispatcher Selection in Kotlin Coroutinesمقدمه: چرا انتخاب درست Dispatcher حیاتی است؟یکی از مهمترین عواملی که میتواند عملکرد اپلیکیشن اندروید یا سرویس بکاند شما را بهبود دهد، انتخاب صحیح Dispatcher در Kotlin Coroutines است.بسیاری از برنامهنویسان اندروید، به محض نیاز به اجرای کدی در بکگراند، از Dispatchers.IO استفاده میکنند. این کار همیشه بهترین انتخاب نیست و حتی ممکن است باعث کندی عملکرد، مصرف بالای منابع و فریز شدن UI شود.در این مقاله یاد میگیریم:Dispatcher چیست؟انواع آن در Kotlinچه زمانی از Main، Default یا IO استفاده کنیماشتباهات رایج و بهترین شیوههاDispatcher در Kotlin چیست؟Dispatcher در Kotlin Coroutines تعیین میکند که کد شما در کدام Thread یا Thread Pool اجرا شود. به زبان ساده:Dispatcher = مکان اجرای coroutine شماانواع اصلی DispatchersDispatchers.Mainکاربرد: بروزرسانی UI، تعامل با ViewThread: تنها یک Main/UI Threadقابل استفاده در:Android، Swing، JavaFX✅ استفاده صحیح:viewModelScope.launch(Dispatchers.Main) { textView.text = "سلام" progressBar.isVisible = true }❌ استفاده نادرست:viewModelScope.launch(Dispatchers.Main) { val result = complexCalculation() // عملیات سنگین روی UI textView.text = result }Dispatchers.Defaultکاربرد: عملیات CPU-bound (محاسبات، پردازش داده)Thread Pool: به اندازه هستههای CPUبهینه برای: Sorting، Parsing JSON، پردازش تصویرمثال:suspend fun parseJson(jsonString: String): MyDataModel = withContext(Dispatchers.Default) { Json.decodeFromString(jsonString) }Dispatchers.IOکاربرد: عملیات Blocking I/OThread Pool: تا 64 Threadبهینه برای: خواندن/نوشتن فایل، JDBC، درخواست شبکه بدون async✅ استفاده صحیح:suspend fun readFile(file: File): String = withContext(Dispatchers.IO) { file.readText() }❌ استفاده نادرست:suspend fun wrongRetrofitCall() = withContext(Dispatchers.IO) { retrofitApi.getData() } // غیرضروریDispatchers.Unconfinedکاربرد: تنها برای Testing یا موارد خاصویژگی: ثابت نبودن Thread بعد از suspensionهشدار: در Production استفاده نشودمثال:@Test fun testExample() = runTest { launch(Dispatchers.Unconfined) { assertEquals(4, 2 + 2) } }چرا نباید همیشه از IO استفاده کنیم؟Thread زیاد = کارایی پایین برای تسکهای CPU-boundContext Switching اضافی و کاهش سرعت اجراکتابخانههایی که خودشان Dispatcher دارندRetrofit + OkHttpRoomKtor Clientنتیجه: اگر کتابخانه Thread Management دارد، نیازی به withContext(Dispatchers.IO) نیست.جدول انتخاب Dispatcher مناسبجدول انتخاب Dispatcher مناسبمثال واقعی در ViewModelfun loadProfile(userId: String) = viewModelScope.launch { try { _uiState.value = UiState.Loading // Retrofit -> بدون Dispatcher val userData = api.getUserProfile(userId) // Room -> بدون Dispatcher dao.insert(userData.toEntity()) // پردازش تصویر -> Default val avatar = withContext(Dispatchers.Default) { imageProcessor.applyCircularMask(userData.avatar) } // خواندن فایل -> IO val settingsJson = withContext(Dispatchers.IO) { File("${context.filesDir}/prefs.json").readText() } // پارس کردن جیسون -> Default val settings = withContext(Dispatchers.Default) { Json.decodeFromString(settingsJson) } // آپدیت UI -> Main (پیشفرض در viewModelScope.launch) _uiState.value = UiState.Success(userData, avatar, settings) } catch (e: Exception) { _uiState.value = UiState.Error(e.message) } }بهترین شیوهها (Best Practices)۱. استفاده از Extension Functionssuspend fun onDefault(block: suspend () -> T) = withContext(Dispatchers.Default) { block() } suspend fun onIO(block: suspend () -> T) = withContext(Dispatchers.IO) { block() }۲. محدود کردن IOبرای جلوگیری از ایجاد Thread بیش از حد، میتوانید تعداد آنها را محدود کنید:val limitedIO = Dispatchers.IO.limitedParallelism(10)۳. اجتناب از تغییرات تو در توی Dispatcher// خوب val data = withContext(Dispatchers.IO) { loadData() } val processed = withContext(Dispatchers.Default) { process(data) } save(processed) // بدون withContext اضافی❌ اشتباهات رایجاستفاده از Dispatchers.IO برای همه عملیاتهااستفاده از withContext برای کتابخانههایی که Dispatcher داخلی دارند (مثل Retrofit و Room)تودرتو کردن بیدلیل withContext📌 نتیجهگیریMain: فقط و فقط برای UIDefault: برای عملیات سنگین و محاسباتی CPUIO: برای عملیات ورودی/خروجی (I/O) که Thread را مسدود میکنندبدون Dispatcher اضافی برای کتابخانههایی که خودشان Thread Pool دارندبا انتخاب صحیح Dispatcher، اپلیکیشن شما پاسخگوتر، سریعتر و بهینهتر کار خواهد کرد.