بخش هشتم — عملکرد

درس پنجاه‌وچهارم

Memory

Memory در اندروید دقیقاً به چی اشاره می‌کنه؟

وقتی در اندروید از Memory حرف می‌زنیم، معمولاً منظورمون حافظه RAMیه که برنامه هنگام اجرا مصرف می‌کنه؛ یعنی حافظه‌ای که Objectها، تصویرها، صفحه‌های Compose، داده‌های موقت، Cacheها و نتیجه درخواست‌های شبکه داخلش قرار می‌گیرن. این حافظه با Storage فرق داره. Storage همون فضای دائمی گوشیه که فایل‌ها، دیتابیس Room و DataStore داخلش باقی می‌مونن، اما اطلاعات RAM معمولاً فقط تا وقتی فرایند برنامه زنده است وجود دارن.

اندروید برای هر برنامه یک فرایند جدا و مقدار محدودی Heap در نظر می‌گیره. اندازه دقیق این حافظه روی همه دستگاه‌ها یکسان نیست و به RAM، نسخه اندروید و تنظیمات سازنده بستگی داره. اگه قیمت‌بان بیشتر از ظرفیت مجازش حافظه درخواست کنه، ممکنه با OutOfMemoryError متوقف بشه. از طرف دیگر، وقتی حافظه سیستم کم میشه، اندروید می‌تونه فرایند برنامه‌های پس‌زمینه رو از بین ببره تا برای برنامه‌های مهم‌تر حافظه آزاد کنه.

این یعنی نباید تصور کنیم چون Kotlin و Android دارای Garbage Collector هستن، دیگه هیچ مسئولیتی درباره حافظه نداریم. Garbage Collector آبجکت‌هایی رو پاک می‌کنه که برنامه دیگه راهی برای دسترسی بهشون نداره. اما اگه ما ناخواسته Reference یک Activity، Bitmap یا List بزرگ رو نگه داشته باشیم، Garbage Collector تصور می‌کنه هنوز به اون نیاز داریم و نمی‌تونه حافظه‌اش رو آزاد کنه.

Garbage Collector چطور تصمیم می‌گیره چی رو پاک کنه؟

وقتی یک Object می‌سازیم، فضای لازم برای اون داخل Heap برنامه گرفته میشه:

val product = Product( id = 42, title = “Laptop”, price = 58_000_000 )

تا وقتی متغیر یا Object دیگری به product دسترسی داشته باشه، این Object زنده محسوب میشه. وقتی دیگه هیچ مسیر قابل‌دسترسی‌ای به اون وجود نداشته باشه، Garbage Collector می‌تونه حافظه‌اش رو پس بگیره.

مثلاً در این تابع، بعد از پایان اجرا معمولاً Reference محلی از بین میره:

fun printTemporaryProduct() {
    val product =
        Product(
            id = 42,
            title = "Laptop",
            price = 58_000_000
        )

    println(product.title)
}

fun printTemporaryProduct() {
    val product =
        Product(
            id = 42,
            title = "Laptop",
            price = 58_000_000
        )

    println(product.title)
}

اما اگه همون Object رو داخل یک Collection سراسری نگه داریم، همچنان قابل‌دسترسی باقی می‌مونه:

object ProductMemoryCache {

    private val products =
        mutableListOf<Product>()

    fun add(product: Product) {
        products.add(product)
    }
}

object ProductMemoryCache {

    private val products =
        mutableListOf<Product>()

    fun add(product: Product) {
        products.add(product)
    }
}

تا وقتی products پاک نشه، تمام Objectهای داخلش هم در حافظه باقی می‌مونن. Garbage Collector نمی‌تونه تشخیص بده که ما از نظر منطقی دیگه به اون‌ها نیاز نداریم؛ فقط می‌بینه هنوز یک Reference معتبر بهشون وجود داره.

Android Runtime از Heap نسل‌بندی‌شده استفاده می‌کنه. Objectهای تازه معمولاً در نسل جوان قرار می‌گیرن و Objectهایی که مدت بیشتری زنده می‌مونن به نسل‌های قدیمی‌تر منتقل میشن. ساخت تعداد زیادی Object کوتاه‌عمر باعث اجرای بیشتر Garbage Collection میشه و اگه این اتفاق وسط Animation یا اسکرول رخ بده، می‌تونه باعث افت فریم و کندی رابط کاربری بشه.

Memory Leak یعنی حافظه گم شده؟

اسم Memory Leak ممکنه این تصور رو ایجاد کنه که حافظه واقعاً از سیستم ناپدید شده، اما در برنامه‌های Kotlin و Java معمولاً مشکل اینه که یک Reference بیشتر از زمان لازم زنده مونده. مثلاً Activity بسته شده، اما یک Singleton هنوز Reference اون Activity رو نگه داشته. در نتیجه Activity همراه تمام Viewها، تصویرها و Stateهای خودش قابل پاک شدن نیست.

نمونه اشتباه:

object AnalyticsManager {

    private var context: Context? = null

    fun initialize(context: Context) {
        this.context = context
    }
}

object AnalyticsManager {

    private var context: Context? = null

    fun initialize(context: Context) {
        this.context = context
    }
}

اگه این متد رو از Activity صدا بزنیم:

AnalyticsManager.initialize(this)

AnalyticsManager.initialize(this)

Singleton تا پایان عمر فرایند زنده می‌مونه و Activity رو هم همراه خودش نگه می‌داره. حتی اگه کاربر Activity رو ببنده یا گوشی بچرخه، Activity قبلی ممکنه در حافظه باقی بمونه.

راه بهتر اینه که فقط ApplicationContext رو نگه داریم:

object AnalyticsManager {

    private lateinit var applicationContext: Context

    fun initialize(context: Context) {
        applicationContext =
            context.applicationContext
    }
}

object AnalyticsManager {

    private lateinit var applicationContext: Context

    fun initialize(context: Context) {
        applicationContext =
            context.applicationContext
    }
}

ApplicationContext تقریباً به اندازه فرایند برنامه عمر می‌کنه، بنابراین نگهداری اون داخل Singleton معمولاً باعث Leak شدن Activity نمیشه. اصل کلی اینه: Object کوتاه‌عمر نباید توسط Object بلندعمر نگه داشته بشه.

Activity و Fragment عمر محدودی دارن، اما Singleton، Repository سراسری، Coroutine بدون Scope مناسب و Callback ثبت‌شده ممکنه مدت خیلی بیشتری زنده بمونن.

یک Memory Leak واقعی در قیمت‌بان

فرض کن برای دریافت تغییر قیمت‌ها یک Listener داریم:

interface PriceUpdateListener {

    fun onPriceUpdated(
        productId: Long,
        newPrice: Long
    )
}

interface PriceUpdateListener {

    fun onPriceUpdated(
        productId: Long,
        newPrice: Long
    )
}

Repository هم Listenerها رو نگه می‌داره:

class PriceRepository {

    private val listeners =
        mutableSetOf<PriceUpdateListener>()

    fun addListener(
        listener: PriceUpdateListener
    ) {
        listeners.add(listener)
    }

    fun removeListener(
        listener: PriceUpdateListener
    ) {
        listeners.remove(listener)
    }

    fun notifyPriceChanged(
        productId: Long,
        newPrice: Long
    ) {
        listeners.forEach { listener ->
            listener.onPriceUpdated(
                productId,
                newPrice
            )
        }
    }
}

class PriceRepository {

    private val listeners =
        mutableSetOf<PriceUpdateListener>()

    fun addListener(
        listener: PriceUpdateListener
    ) {
        listeners.add(listener)
    }

    fun removeListener(
        listener: PriceUpdateListener
    ) {
        listeners.remove(listener)
    }

    fun notifyPriceChanged(
        productId: Long,
        newPrice: Long
    ) {
        listeners.forEach { listener ->
            listener.onPriceUpdated(
                productId,
                newPrice
            )
        }
    }
}

حالا Activity خودش رو به عنوان Listener ثبت می‌کنه:

class ProductActivity :
    AppCompatActivity(),
    PriceUpdateListener {

    override fun onCreate(
        savedInstanceState: Bundle?
    ) {
        super.onCreate(savedInstanceState)

        priceRepository.addListener(this)
    }

    override fun onPriceUpdated(
        productId: Long,
        newPrice: Long
    ) {
        // بروزرسانی صفحه
    }
}

class ProductActivity :
    AppCompatActivity(),
    PriceUpdateListener {

    override fun onCreate(
        savedInstanceState: Bundle?
    ) {
        super.onCreate(savedInstanceState)

        priceRepository.addListener(this)
    }

    override fun onPriceUpdated(
        productId: Long,
        newPrice: Long
    ) {
        // بروزرسانی صفحه
    }
}

مشکل اینه که اگه Activity از بین بره ولی Listener حذف نشه، Repository همچنان Reference اون رو نگه می‌داره. پس باید در زمان مناسب ثبت رو لغو کنیم:

override fun onDestroy() {
    priceRepository.removeListener(this)

    super.onDestroy()
}

override fun onDestroy() {
    priceRepository.removeListener(this)

    super.onDestroy()
}

این روش کار می‌کنه، اما به حافظه و دقت برنامه‌نویس وابسته است. فراموش کردن فقط یک removeListener() می‌تونه Leak ایجاد کنه. به همین دلیل در معماری‌های جدید معمولاً Flow و Lifecycle رو جایگزین Listenerهای دستی می‌کنیم.

Flow رو براساس Lifecycle جمع‌آوری می‌کنیم

فرض کن Repository تغییر قیمت‌ها رو با StateFlow منتشر می‌کنه:

class PriceRepository {

    private val _priceUpdates =
        MutableStateFlow<Map<Long, Long>>(
            emptyMap()
        )

    val priceUpdates:
        StateFlow<Map<Long, Long>> =
        _priceUpdates.asStateFlow()

    fun updatePrice(
        productId: Long,
        newPrice: Long
    ) {
        _priceUpdates.update { current ->
            current + (
                productId to newPrice
            )
        }
    }
}

class PriceRepository {

    private val _priceUpdates =
        MutableStateFlow<Map<Long, Long>>(
            emptyMap()
        )

    val priceUpdates:
        StateFlow<Map<Long, Long>> =
        _priceUpdates.asStateFlow()

    fun updatePrice(
        productId: Long,
        newPrice: Long
    ) {
        _priceUpdates.update { current ->
            current + (
                productId to newPrice
            )
        }
    }
}

داخل Activity نباید یک Coroutine بدون توجه به Lifecycle بسازیم:

lifecycleScope.launch {
    priceRepository.priceUpdates.collect {
        // ممکنه حتی وقتی صفحه قابل‌مشاهده نیست ادامه پیدا کنه
    }
}

lifecycleScope.launch {
    priceRepository.priceUpdates.collect {
        // ممکنه حتی وقتی صفحه قابل‌مشاهده نیست ادامه پیدا کنه
    }
}

روش بهتر استفاده از repeatOnLifecycle است:

override fun onCreate(
    savedInstanceState: Bundle?
) {
    super.onCreate(savedInstanceState)

    lifecycleScope.launch {
        repeatOnLifecycle(
            Lifecycle.State.STARTED
        ) {
            priceRepository
                .priceUpdates
                .collect { prices ->
                    renderPrices(prices)
                }
        }
    }
}

override fun onCreate(
    savedInstanceState: Bundle?
) {
    super.onCreate(savedInstanceState)

    lifecycleScope.launch {
        repeatOnLifecycle(
            Lifecycle.State.STARTED
        ) {
            priceRepository
                .priceUpdates
                .collect { prices ->
                    renderPrices(prices)
                }
        }
    }
}

وقتی Activity به وضعیت STARTED میرسه، Collection شروع میشه. وقتی صفحه متوقف میشه، Coroutine داخلی لغو میشه و وقتی صفحه دوباره شروع شد، Collection تازه‌ای ساخته میشه. به این ترتیب نه لازم است Listener رو دستی حذف کنیم و نه پردازش بی‌دلیل در پس‌زمینه ادامه پیدا می‌کنه.

در Compose هم بهتره از API سازگار با Lifecycle استفاده کنیم:

@Composable
fun ProductRoute(
    viewModel: ProductViewModel
) {
    val uiState by
        viewModel.uiState
            .collectAsStateWithLifecycle()

    ProductScreen(
        uiState = uiState
    )
}

@Composable
fun ProductRoute(
    viewModel: ProductViewModel
) {
    val uiState by
        viewModel.uiState
            .collectAsStateWithLifecycle()

    ProductScreen(
        uiState = uiState
    )
}

این روش بهتر از collectAsState خامه، چون Collection رو با Lifecycle رابط کاربری هماهنگ می‌کنه.

Coroutine هم می‌تونه باعث نگهداری حافظه بشه

Coroutine ذاتاً Memory Leak نیست، اما اگه داخل Scope اشتباه اجرا بشه، ممکنه Objectها رو بیش از حد لازم زنده نگه داره. نمونه خطرناک:

class ProductActivity :
    AppCompatActivity() {

    override fun onCreate(
        savedInstanceState: Bundle?
    ) {
        super.onCreate(savedInstanceState)

        GlobalScope.launch {
            val products =
                repository.loadProducts()

            runOnUiThread {
                showProducts(products)
            }
        }
    }
}

class ProductActivity :
    AppCompatActivity() {

    override fun onCreate(
        savedInstanceState: Bundle?
    ) {
        super.onCreate(savedInstanceState)

        GlobalScope.launch {
            val products =
                repository.loadProducts()

            runOnUiThread {
                showProducts(products)
            }
        }
    }
}

GlobalScope به Lifecycle Activity وابسته نیست. اگه کاربر صفحه رو ببنده، Coroutine همچنان ادامه پیدا می‌کنه و چون داخل Lambda به Activity دسترسی داریم، Activity ممکنه تا پایان عملیات زنده بمونه. علاوه بر اون، ممکنه بعد از بسته شدن صفحه تلاش کنیم UI رو تغییر بدیم.

نسخه درست:

lifecycleScope.launch {
    val products =
        repository.loadProducts()

    showProducts(products)
}

lifecycleScope.launch {
    val products =
        repository.loadProducts()

    showProducts(products)
}

Coroutine مربوط به lifecycleScope وقتی Lifecycle نابود بشه لغو میشه. در ViewModel هم از viewModelScope استفاده می‌کنیم:

class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val _uiState =
        MutableStateFlow(
            ProductUiState()
        )

    val uiState =
        _uiState.asStateFlow()

    fun loadProducts() {
        viewModelScope.launch {
            _uiState.update {
                it.copy(
                    isLoading = true
                )
            }

            val result =
                repository.loadProducts()

            _uiState.update {
                it.copy(
                    isLoading = false,
                    products =
                        result.getOrDefault(
                            emptyList()
                        )
                )
            }
        }
    }
}

class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val _uiState =
        MutableStateFlow(
            ProductUiState()
        )

    val uiState =
        _uiState.asStateFlow()

    fun loadProducts() {
        viewModelScope.launch {
            _uiState.update {
                it.copy(
                    isLoading = true
                )
            }

            val result =
                repository.loadProducts()

            _uiState.update {
                it.copy(
                    isLoading = false,
                    products =
                        result.getOrDefault(
                            emptyList()
                        )
                )
            }
        }
    }
}

وقتی ViewModel برای همیشه پاک بشه، Coroutineهای viewModelScope هم لغو میشن.

ViewModel نباید Activity رو نگه داره

ViewModel ممکنه هنگام چرخش صفحه زنده بمونه، در حالی که Activity قبلی نابود شده و Activity جدید ساخته میشه. بنابراین نباید Context مربوط به Activity، View، NavController یا Binding رو داخل ViewModel نگه داریم.

نمونه اشتباه:

class ProductViewModel(
    private val activity: Activity
) : ViewModel() {

    fun showMessage() {
        Toast.makeText(
            activity,
            "قیمت بروزرسانی شد",
            Toast.LENGTH_SHORT
        ).show()
    }
}

class ProductViewModel(
    private val activity: Activity
) : ViewModel() {

    fun showMessage() {
        Toast.makeText(
            activity,
            "قیمت بروزرسانی شد",
            Toast.LENGTH_SHORT
        ).show()
    }
}

اگه Activity بچرخه، ViewModel همچنان Activity قبلی رو نگه می‌داره و باعث Leak میشه. ViewModel بهتره فقط State و Event تولید کنه:

data class ProductUiState(
    val products: List<Product> =
        emptyList(),
    val message: String? = null
)

data class ProductUiState(
    val products: List<Product> =
        emptyList(),
    val message: String? = null
)

class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val _uiState =
        MutableStateFlow(
            ProductUiState()
        )

    val uiState =
        _uiState.asStateFlow()

    fun priceUpdated() {
        _uiState.update {
            it.copy(
                message =
                    "قیمت بروزرسانی شد"
            )
        }
    }

    fun messageShown() {
        _uiState.update {
            it.copy(
                message = null
            )
        }
    }
}

class ProductViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val _uiState =
        MutableStateFlow(
            ProductUiState()
        )

    val uiState =
        _uiState.asStateFlow()

    fun priceUpdated() {
        _uiState.update {
            it.copy(
                message =
                    "قیمت بروزرسانی شد"
            )
        }
    }

    fun messageShown() {
        _uiState.update {
            it.copy(
                message = null
            )
        }
    }
}

خود UI پیام رو نمایش میده و بعد به ViewModel خبر میده که Event مصرف شده. در مواردی که واقعاً Context لازم داریم، بهتره وابستگی رو تا حد امکان به کلاس‌های بیرون ViewModel منتقل کنیم. اگه Context برنامه لازم شد، میشه ApplicationContext رو با Dependency Injection وارد کرد؛ نه Activity رو.

چرا تصویرها معمولاً بیشترین Memory رو مصرف می‌کنن؟

Bitmapها یکی از رایج‌ترین دلایل مصرف بالای RAM هستن. اندازه فایل تصویر روی دیسک با مقدار حافظه‌ای که بعد از Decode مصرف می‌کنه یکسان نیست. مثلاً یک فایل JPEG ممکنه فقط ۵۰۰ کیلوبایت باشه، اما وقتی به Bitmap با ابعاد ۴۰۰۰ در ۳۰۰۰ تبدیل میشه، چند ده مگابایت RAM مصرف کنه.

تقریب ساده مصرف Bitmap معمولاً این شکلیه:
عرض × ارتفاع × تعداد بایت هر Pixel

برای Bitmap نوع ARGB_8888 هر Pixel تقریباً چهار بایت مصرف می‌کنه. پس تصویر ۴۰۰۰ در ۳۰۰۰ تقریباً چنین حافظه‌ای می‌خواد:

4000 × 3000 × 4 = 48,000,000 bytes

یعنی حدود ۴۸ مگابایت فقط برای یک تصویر. اگه چند تصویر بزرگ هم‌زمان داخل صفحه باشن، رسیدن به OutOfMemoryError خیلی دور از ذهن نیست. نباید تصویر اصلی رو با ابعاد کامل Decode کنیم و بعد داخل یک Image کوچک ۱۲۰ پیکسلی نمایش بدیم. کتابخانه‌هایی مثل Coil تصویر رو براساس اندازه مقصد Decode و Cache می‌کنن.

در Compose:

@Composable
fun ProductImage(
    imageUrl: String,
    contentDescription: String
) {
    AsyncImage(
        model =
            ImageRequest.Builder(
                LocalContext.current
            )
                .data(imageUrl)
                .crossfade(true)
                .size(
                    width = 300,
                    height = 300
                )
                .build(),
        contentDescription =
            contentDescription,
        modifier =
            Modifier.size(120.dp),
        contentScale =
            ContentScale.Crop
    )
}

@Composable
fun ProductImage(
    imageUrl: String,
    contentDescription: String
) {
    AsyncImage(
        model =
            ImageRequest.Builder(
                LocalContext.current
            )
                .data(imageUrl)
                .crossfade(true)
                .size(
                    width = 300,
                    height = 300
                )
                .build(),
        contentDescription =
            contentDescription,
        modifier =
            Modifier.size(120.dp),
        contentScale =
            ContentScale.Crop
    )
}

در خیلی از حالت‌ها خود Coil اندازه مقصد رو تشخیص میده، اما تعیین اندازه مشخص کمک می‌کنه تصویر غول‌پیکر بی‌دلیل Decode نشه. همچنین نباید Bitmap رو داخل ViewModel، rememberSaveable یا Singleton ذخیره کنیم. بهتره URL یا شناسه تصویر رو نگه داریم و اجازه بدیم کتابخانه تصویر Cache رو مدیریت کنه.

Cache باید محدود باشه

Cache باعث میشه داده‌ها سریع‌تر نمایش داده بشن، اما Cache نامحدود یعنی Memory Leak طراحی‌شده. نمونه بد:

object ProductCache {

    val products =
        mutableMapOf<Long, ProductDetails>()
}

object ProductCache {

    val products =
        mutableMapOf<Long, ProductDetails>()
}

اگه کاربر هزاران محصول رو باز کنه، این Map دائماً بزرگ‌تر میشه و هیچ چیزی از اون حذف نمیشه. برای Cache حافظه بهتره یک محدودیت مشخص داشته باشیم. LruCache وقتی ظرفیت پر میشه، قدیمی‌ترین موارد کم‌استفاده رو حذف می‌کنه:

class ProductMemoryCache {

    private val cache =
        object : LruCache<Long, ProductDetails>(
            100
        ) {}

    fun put(
        product: ProductDetails
    ) {
        cache.put(
            product.id,
            product
        )
    }

    fun get(
        productId: Long
    ): ProductDetails? {
        return cache.get(productId)
    }

    fun remove(
        productId: Long
    ) {
        cache.remove(productId)
    }

    fun clear() {
        cache.evictAll()
    }
}

class ProductMemoryCache {

    private val cache =
        object : LruCache<Long, ProductDetails>(
            100
        ) {}

    fun put(
        product: ProductDetails
    ) {
        cache.put(
            product.id,
            product
        )
    }

    fun get(
        productId: Long
    ): ProductDetails? {
        return cache.get(productId)
    }

    fun remove(
        productId: Long
    ) {
        cache.remove(productId)
    }

    fun clear() {
        cache.evictAll()
    }
}

اینجا حداکثر ۱۰۰ محصول نگه داشته میشه. البته بهتره ظرفیت براساس هزینه واقعی Objectها انتخاب بشه، نه یک عدد تصادفی. اگه ProductDetails شامل چند Bitmap یا متن بسیار بزرگه، حتی ۱۰۰ مورد هم ممکنه زیاد باشه.

برای داده‌هایی که باید مدت بیشتری باقی بمونن، Cache حافظه همیشه انتخاب مناسبی نیست. داده رو داخل Room ذخیره می‌کنیم و فقط بخش موردنیاز صفحه رو وارد RAM می‌کنیم.

لیست خیلی بزرگ رو یک‌جا وارد حافظه نکن

فرض کن سرور قیمت‌بان صد هزار رکورد قیمت داره. این کار اشتباهه:

@GET("products")
suspend fun getAllProducts():
    List<ProductResponse>

@GET("products")
suspend fun getAllProducts():
    List<ProductResponse>

چون پاسخ کامل باید دریافت، Parse و داخل حافظه نگهداری بشه. بعد ممکنه هم نسخه JSON، هم مدل شبکه، هم Entity و هم مدل UI برای مدتی هم‌زمان در RAM وجود داشته باشن. راه بهتر Pagination است:

interface ProductApi {

    @GET("products")
    suspend fun getProducts(
        @Query("page")
        page: Int,
        @Query("limit")
        limit: Int
    ): ProductPageResponse
}

interface ProductApi {

    @GET("products")
    suspend fun getProducts(
        @Query("page")
        page: Int,
        @Query("limit")
        limit: Int
    ): ProductPageResponse
}

مدل پاسخ:

data class ProductPageResponse(
    val items: List<ProductResponse>,
    val currentPage: Int,
    val hasNextPage: Boolean
)

data class ProductPageResponse(
    val items: List<ProductResponse>,
    val currentPage: Int,
    val hasNextPage: Boolean
)

در پروژه بزرگ‌تر می‌تونیم از Paging 3 استفاده کنیم تا فقط صفحات موردنیاز کاربر بارگذاری بشن:

class ProductPagingSource(
    private val api: ProductApi
) : PagingSource<Int, Product>() {

    override suspend fun load(
        params: LoadParams<Int>
    ): LoadResult<Int, Product> {
        val page =
            params.key ?: 1

        return try {
            val response =
                api.getProducts(
                    page = page,
                    limit = params.loadSize
                )

            LoadResult.Page(
                data =
                    response.items.map {
                        it.toDomain()
                    },
                prevKey =
                    if (page == 1) {
                        null
                    } else {
                        page - 1
                    },
                nextKey =
                    if (
                        response.hasNextPage
                    ) {
                        page + 1
                    } else {
                        null
                    }
            )
        } catch (
            exception: Exception
        ) {
            LoadResult.Error(exception)
        }
    }

    override fun getRefreshKey(
        state:
            PagingState<Int, Product>
    ): Int? {
        val anchorPosition =
            state.anchorPosition
                ?: return null

        val anchorPage =
            state.closestPageToPosition(
                anchorPosition
            )

        return anchorPage?.prevKey
            ?.plus(1)
            ?: anchorPage?.nextKey
                ?.minus(1)
    }
}

class ProductPagingSource(
    private val api: ProductApi
) : PagingSource<Int, Product>() {

    override suspend fun load(
        params: LoadParams<Int>
    ): LoadResult<Int, Product> {
        val page =
            params.key ?: 1

        return try {
            val response =
                api.getProducts(
                    page = page,
                    limit = params.loadSize
                )

            LoadResult.Page(
                data =
                    response.items.map {
                        it.toDomain()
                    },
                prevKey =
                    if (page == 1) {
                        null
                    } else {
                        page - 1
                    },
                nextKey =
                    if (
                        response.hasNextPage
                    ) {
                        page + 1
                    } else {
                        null
                    }
            )
        } catch (
            exception: Exception
        ) {
            LoadResult.Error(exception)
        }
    }

    override fun getRefreshKey(
        state:
            PagingState<Int, Product>
    ): Int? {
        val anchorPosition =
            state.anchorPosition
                ?: return null

        val anchorPage =
            state.closestPageToPosition(
                anchorPosition
            )

        return anchorPage?.prevKey
            ?.plus(1)
            ?: anchorPage?.nextKey
                ?.minus(1)
    }
}

Repository:

class ProductRepository(
    private val api: ProductApi
) {

    fun getProducts():
        Flow<PagingData<Product>> {
        return Pager(
            config =
                PagingConfig(
                    pageSize = 20,
                    prefetchDistance = 5,
                    enablePlaceholders =
                        false
                ),
            pagingSourceFactory = {
                ProductPagingSource(api)
            }
        ).flow
    }
}

class ProductRepository(
    private val api: ProductApi
) {

    fun getProducts():
        Flow<PagingData<Product>> {
        return Pager(
            config =
                PagingConfig(
                    pageSize = 20,
                    prefetchDistance = 5,
                    enablePlaceholders =
                        false
                ),
            pagingSourceFactory = {
                ProductPagingSource(api)
            }
        ).flow
    }
}

ViewModel:

class ProductListViewModel(
    repository: ProductRepository
) : ViewModel() {

    val products =
        repository
            .getProducts()
            .cachedIn(viewModelScope)
}

class ProductListViewModel(
    repository: ProductRepository
) : ViewModel() {

    val products =
        repository
            .getProducts()
            .cachedIn(viewModelScope)
}

Compose:

@Composable
fun ProductListRoute(
    viewModel: ProductListViewModel
) {
    val products =
        viewModel.products
            .collectAsLazyPagingItems()

    LazyColumn {
        items(
            count = products.itemCount,
            key = { index ->
                products[index]?.id
                    ?: index
            }
        ) { index ->
            val product =
                products[index]

            if (product != null) {
                ProductItem(product)
            }
        }
    }
}

@Composable
fun ProductListRoute(
    viewModel: ProductListViewModel
) {
    val products =
        viewModel.products
            .collectAsLazyPagingItems()

    LazyColumn {
        items(
            count = products.itemCount,
            key = { index ->
                products[index]?.id
                    ?: index
            }
        ) { index ->
            val product =
                products[index]

            if (product != null) {
                ProductItem(product)
            }
        }
    }
}

Paging هم مصرف شبکه رو کم می‌کنه و هم اجازه نمیده کل دیتاست یک‌جا وارد حافظه بشه.

State رابط کاربری رو بیش از حد بزرگ نکن

گاهی خود ViewModel تبدیل به انبار اطلاعات میشه:

data class ProductUiState(
    val allProducts:
        List<Product>,
    val allPriceHistory:
        Map<Long, List<PricePoint>>,
    val allImages:
        Map<Long, Bitmap>,
    val allSearchResults:
        List<Product>
)

data class ProductUiState(
    val allProducts:
        List<Product>,
    val allPriceHistory:
        Map<Long, List<PricePoint>>,
    val allImages:
        Map<Long, Bitmap>,
    val allSearchResults:
        List<Product>
)

هر بار که State جدید ساخته میشه، ممکنه Collectionهای بزرگی کپی یا برای مدت طولانی نگهداری بشن. بهتره State فقط اطلاعات لازم برای صفحه فعلی رو داشته باشه.

data class ProductDetailsUiState(
    val isLoading: Boolean = false,
    val product:
        ProductDetails? = null,
    val recentPrices:
        List<PricePoint> =
        emptyList(),
    val errorMessage:
        String? = null
)

data class ProductDetailsUiState(
    val isLoading: Boolean = false,
    val product:
        ProductDetails? = null,
    val recentPrices:
        List<PricePoint> =
        emptyList(),
    val errorMessage:
        String? = null
)

اگه تاریخچه قیمت هزاران نقطه داره، فقط بازه قابل‌نمایش رو می‌گیریم:

interface PriceHistoryDao {

    @Query(
        """
        SELECT *
        FROM price_history
        WHERE product_id = :productId
        ORDER BY created_at DESC
        LIMIT :limit
        """
    )
    suspend fun getRecentPrices(
        productId: Long,
        limit: Int
    ): List<PriceHistoryEntity>
}

interface PriceHistoryDao {

    @Query(
        """
        SELECT *
        FROM price_history
        WHERE product_id = :productId
        ORDER BY created_at DESC
        LIMIT :limit
        """
    )
    suspend fun getRecentPrices(
        productId: Long,
        limit: Int
    ): List<PriceHistoryEntity>
}

remember و rememberSaveable رو درست استفاده کن

در Compose، remember مقدار رو تا وقتی Composable در Composition باقی مونده نگه می‌داره:

val expanded =
    remember {
        mutableStateOf(false)
    }

val expanded =
    remember {
        mutableStateOf(false)
    }

rememberSaveable علاوه بر Recomposition، تلاش می‌کنه مقدار رو هنگام بازسازی Activity هم نگه داره:

var searchQuery by
    rememberSaveable {
        mutableStateOf("")
    }

var searchQuery by
    rememberSaveable {
        mutableStateOf("")
    }

اما نباید Objectهای بزرگ رو داخل rememberSaveable قرار بدیم، چون داده باید وارد Bundle یا Saved State بشه و علاوه بر مصرف حافظه ممکنه با محدودیت اندازه State روبه‌رو بشیم.

نمونه بد:

val products =
    rememberSaveable {
        mutableStateOf(
            hugeProductList
        )
    }

val products =
    rememberSaveable {
        mutableStateOf(
            hugeProductList
        )
    }

بهتره فقط شناسه یا ورودی کوچک رو ذخیره کنیم:

var selectedProductId by
    rememberSaveable {
        mutableLongStateOf(-1L)
    }

var selectedProductId by
    rememberSaveable {
        mutableLongStateOf(-1L)
    }

خود اطلاعات محصول از Repository یا ViewModel دوباره دریافت میشه. همچنین نباید Activity یا View رو داخل remember نگه داریم:

val activity =
    remember {
        context as Activity
    }

val activity =
    remember {
        context as Activity
    }

معمولاً همون Context فعلی رو مستقیم از LocalContext.current می‌گیریم و فقط در لحظه نیاز استفاده می‌کنیم.

Callbackهای Compose می‌تونن مقدار قدیمی رو نگه دارن

فرض کن یک عملیات زمان‌دار داریم:

@Composable
fun PriceMessage(
    onTimeout: () -> Unit
) {
    LaunchedEffect(Unit) {
        delay(3000)
        onTimeout()
    }
}

@Composable
fun PriceMessage(
    onTimeout: () -> Unit
) {
    LaunchedEffect(Unit) {
        delay(3000)
        onTimeout()
    }
}

اگه onTimeout در Recomposition تغییر کنه، Coroutine قبلی ممکنه هنوز Callback قدیمی رو نگه داشته باشه. برای نگه داشتن آخرین نسخه Callback از rememberUpdatedState استفاده می‌کنیم:

@Composable
fun PriceMessage(
    onTimeout: () -> Unit
) {
    val currentOnTimeout by
        rememberUpdatedState(
            newValue = onTimeout
        )

    LaunchedEffect(Unit) {
        delay(3000)
        currentOnTimeout()
    }
}

@Composable
fun PriceMessage(
    onTimeout: () -> Unit
) {
    val currentOnTimeout by
        rememberUpdatedState(
            newValue = onTimeout
        )

    LaunchedEffect(Unit) {
        delay(3000)
        currentOnTimeout()
    }
}

این مورد همیشه یک Memory Leak بزرگ ایجاد نمی‌کنه، اما جلوی نگهداری ناخواسته State یا Closure قدیمی رو می‌گیره و رفتار Composable رو قابل‌پیش‌بینی‌تر می‌کنه.

Resourceهایی که Garbage Collector نمی‌بنده

Garbage Collector حافظه Objectها رو مدیریت می‌کنه، اما Resourceهایی مثل فایل، Cursor، Stream، Socket و بعضی Objectهای Native باید صریحاً بسته بشن. بهتره از use استفاده کنیم تا حتی در صورت Exception هم Resource آزاد بشه.

خواندن فایل:

fun readTextFile(
    file: File
): String {
    return file
        .bufferedReader()
        .use { reader ->
            reader.readText()
        }
}

fun readTextFile(
    file: File
): String {
    return file
        .bufferedReader()
        .use { reader ->
            reader.readText()
        }
}

خواندن Cursor:

fun readProductNames(
    cursor: Cursor
): List<String> {
    return cursor.use {
        val result =
            mutableListOf<String>()

        val nameIndex =
            it.getColumnIndexOrThrow(
                "name"
            )

        while (it.moveToNext()) {
            result.add(
                it.getString(nameIndex)
            )
        }

        result
    }
}

fun readProductNames(
    cursor: Cursor
): List<String> {
    return cursor.use {
        val result =
            mutableListOf<String>()

        val nameIndex =
            it.getColumnIndexOrThrow(
                "name"
            )

        while (it.moveToNext()) {
            result.add(
                it.getString(nameIndex)
            )
        }

        result
    }
}

اگه Stream یا Cursor بسته نشن، فقط RAM مصرف نمیشه؛ ممکنه File Descriptorهای برنامه هم تمام بشن و برنامه با خطاهای غیرمنتظره روبه‌رو بشه.

برنامه هنگام کمبود حافظه چه کار می‌کنه؟

وقتی حافظه سیستم کم میشه، Android می‌تونه فرایندهای Cacheشده رو از بین ببره. بنابراین نباید فرض کنیم Singletonها، Cache حافظه یا متغیرهای سراسری برای همیشه زنده می‌مونن. State مهم باید در محل پایدارتری مثل Room، DataStore یا Saved State ذخیره بشه.

برای آزاد کردن Cacheهای غیرضروری می‌تونیم به onTrimMemory واکنش نشون بدیم. Android این Callback رو زمانی صدا می‌زنه که فرصت مناسبی برای کاهش مصرف حافظه وجود داشته باشه.

class GheimatBanApplication :
    Application(),
    ComponentCallbacks2 {

    lateinit var productMemoryCache:
        ProductMemoryCache

    override fun onCreate() {
        super.onCreate()

        productMemoryCache =
            ProductMemoryCache()
    }

    override fun onTrimMemory(
        level: Int
    ) {
        super.onTrimMemory(level)

        when {
            level >=
                ComponentCallbacks2
                    .TRIM_MEMORY_RUNNING_CRITICAL -> {
                productMemoryCache.clear()
                imageCache.clearMemory()
            }

            level >=
                ComponentCallbacks2
                    .TRIM_MEMORY_RUNNING_LOW -> {
                productMemoryCache.trimToHalf()
            }

            level >=
                ComponentCallbacks2
                    .TRIM_MEMORY_UI_HIDDEN -> {
                temporaryScreenCache.clear()
            }
        }
    }
}

class GheimatBanApplication :
    Application(),
    ComponentCallbacks2 {

    lateinit var productMemoryCache:
        ProductMemoryCache

    override fun onCreate() {
        super.onCreate()

        productMemoryCache =
            ProductMemoryCache()
    }

    override fun onTrimMemory(
        level: Int
    ) {
        super.onTrimMemory(level)

        when {
            level >=
                ComponentCallbacks2
                    .TRIM_MEMORY_RUNNING_CRITICAL -> {
                productMemoryCache.clear()
                imageCache.clearMemory()
            }

            level >=
                ComponentCallbacks2
                    .TRIM_MEMORY_RUNNING_LOW -> {
                productMemoryCache.trimToHalf()
            }

            level >=
                ComponentCallbacks2
                    .TRIM_MEMORY_UI_HIDDEN -> {
                temporaryScreenCache.clear()
            }
        }
    }
}

Cache رو کمی کامل‌تر می‌کنیم:

class ProductMemoryCache {

    private val maximumSize = 100

    private val cache =
        LruCache<Long, ProductDetails>(
            maximumSize
        )

    fun put(
        product: ProductDetails
    ) {
        cache.put(
            product.id,
            product
        )
    }

    fun get(
        productId: Long
    ): ProductDetails? {
        return cache.get(productId)
    }

    fun trimToHalf() {
        cache.trimToSize(
            maximumSize / 2
        )
    }

    fun clear() {
        cache.evictAll()
    }
}

class ProductMemoryCache {

    private val maximumSize = 100

    private val cache =
        LruCache<Long, ProductDetails>(
            maximumSize
        )

    fun put(
        product: ProductDetails
    ) {
        cache.put(
            product.id,
            product
        )
    }

    fun get(
        productId: Long
    ): ProductDetails? {
        return cache.get(productId)
    }

    fun trimToHalf() {
        cache.trimToSize(
            maximumSize / 2
        )
    }

    fun clear() {
        cache.evictAll()
    }
}

نباید در onTrimMemory اطلاعات مهم کاربر رو پاک کنیم یا عملیات طولانی انجام بدیم. اینجا فقط Resourceهایی رو آزاد می‌کنیم که دوباره قابل‌ساختن یا دریافت هستن.

OutOfMemoryError رو با Try/Catch حل نکن

ممکنه وسوسه بشیم چنین کاری انجام بدیم:

try {
    val bitmap =
        loadHugeBitmap()
} catch (
    error: OutOfMemoryError
) {
    System.gc()
}

try {
    val bitmap =
        loadHugeBitmap()
} catch (
    error: OutOfMemoryError
) {
    System.gc()
}

این راه‌حل قابل‌اعتماد نیست. وقتی برنامه به OutOfMemoryError رسیده، وضعیت حافظه ممکنه به‌شدت ناپایدار باشه و حتی ساخت Object لازم برای نمایش پیام خطا هم شکست بخوره. فراخوانی System.gc هم تضمین نمی‌کنه حافظه کافی آزاد بشه، چون مشکل ممکنه Objectهای همچنان قابل‌دسترسی یا Allocation بسیار بزرگ باشه.

راه درست پیشگیریه: تصویر رو در اندازه مناسب Decode کنیم، لیست‌ها رو صفحه‌بندی کنیم، Cache رو محدود کنیم، Referenceهای اضافی رو آزاد کنیم و Memory Leakها رو با ابزار پیدا کنیم.

Memory Profiler رو چطور استفاده کنیم؟

Android Studio ابزار Memory Profiler داره که مصرف حافظه برنامه رو در طول زمان نمایش میده. می‌تونیم ببینیم حافظه Java/Kotlin، Native، Graphics و Stack چطور تغییر می‌کنه، Garbage Collection چه زمانی رخ میده و چه تعداد Object ساخته شده. همچنین میشه Heap Dump گرفت و Objectهایی رو پیدا کرد که نباید هنوز زنده باشن.

برای بررسی Leak یک سناریوی مشخص اجرا می‌کنیم:

1. صفحه جزئیات محصول رو باز می‌کنیم.
2. از صفحه خارج میشیم.
3. این کار رو چند بار تکرار می‌کنیم.
4. Garbage Collection رو از Profiler اجرا می‌کنیم.
5. Heap Dump می‌گیریم.
6. دنبال چند نمونه از ProductActivity یا صفحه قبلی می‌گردیم.

اگه بعد از خروج همچنان چند Activity قدیمی زنده باشن، Retaining Path رو بررسی می‌کنیم تا بفهمیم چه Objectی Reference اون‌ها رو نگه داشته. ممکنه Singleton، Listener، Handler، Coroutine یا Callback یک SDK عامل Leak باشه.

Android Studio همچنین امکان بررسی Allocationها رو میده؛ یعنی می‌تونیم بفهمیم یک کلاس از کدوم خط ساخته شده و چرا تعداد زیادی نمونه از اون وجود داره.

LeakCanary رو به نسخه Debug اضافه می‌کنیم

LeakCanary کتابخانه‌ایه که بعد از نابود شدن Activity، Fragment یا View بررسی می‌کنه آیا Object همچنان در حافظه باقی مونده یا نه. این کتابخانه رو فقط به نسخه Debug اضافه می‌کنیم:

dependencies {
    debugImplementation(
        "com.squareup.leakcanary:" +
            "leakcanary-android:" +
            "CURRENT_VERSION"
    )
}

dependencies {
    debugImplementation(
        "com.squareup.leakcanary:" +
            "leakcanary-android:" +
            "CURRENT_VERSION"
    )
}

بعد از اضافه شدن، معمولاً نیاز به Initialization دستی نداره. برنامه رو اجرا می‌کنیم و صفحه‌ها رو باز و بسته می‌کنیم. اگه Leak شناسایی بشه، LeakCanary زنجیره Referenceها رو نمایش میده.

مثلاً ممکنه چنین مسیری پیدا بشه:

AnalyticsManager ↓ activityContext ↓ ProductActivity ↓ ComposeView ↓ Composition

این مسیر نشون میده AnalyticsManager باعث شده Activity قابل پاک شدن نباشه. خود عدد مصرف حافظه به تنهایی همیشه علت مشکل رو نشون نمیده؛ زنجیره Referenceهاست که به ما میگه کدوم Object، Object قبلی رو زنده نگه داشته.

مستندات Android Studio هم LeakCanary رو به عنوان یکی از ابزارهای مفید تشخیص Memory Leak معرفی می‌کنن.

اطلاعات حساس در Memory چه وضعیتی دارن؟

در درس قبلی داده‌ها رو با Android Keystore رمز کردیم، اما وقتی Token برای ارسال درخواست استفاده میشه، باید برای لحظه‌ای به صورت رمزگشایی‌شده وارد RAM بشه. هیچ راهی وجود نداره که برنامه از یک مقدار استفاده کنه ولی اون مقدار هیچ‌وقت در حافظه قابل‌دسترسی نباشه. روی دستگاه Rootشده یا فرایند Hookشده، مهاجم ممکنه Token رو در همین لحظه استخراج کنه.

پس هدف ما حذف کامل اطلاعات حساس از RAM نیست؛ هدف کاهش زمان و تعداد نسخه‌های اون در حافظه است. نباید Token رو داخل State رابط کاربری، Log، Singleton عمومی، Bundle یا چند مدل مختلف کپی کنیم.

نمونه بد:

data class AuthUiState(
    val email: String = "",
    val accessToken: String = "",
    val refreshToken: String = ""
)

data class AuthUiState(
    val email: String = "",
    val accessToken: String = "",
    val refreshToken: String = ""
)

UI هیچ نیازی به Token نداره. State بهتر:

data class AuthUiState(
    val email: String = "",
    val isAuthenticated: Boolean =
        false,
    val isLoading: Boolean = false,
    val errorMessage: String? = null
)

data class AuthUiState(
    val email: String = "",
    val isAuthenticated: Boolean =
        false,
    val isLoading: Boolean = false,
    val errorMessage: String? = null
)

Token فقط در لایه احراز هویت استفاده میشه:

class AuthHeaderProvider(
    private val tokenStore:
        SecureTokenStore
) {

    suspend fun createHeader():
        String? {
        val token =
            tokenStore
                .getAccessToken()
                ?: return null

        return "Bearer $token"
    }
}

class AuthHeaderProvider(
    private val tokenStore:
        SecureTokenStore
) {

    suspend fun createHeader():
        String? {
        val token =
            tokenStore
                .getAccessToken()
                ?: return null

        return "Bearer $token"
    }
}

بعد از اینکه String ساخته شد، JVM زمان دقیق پاک شدن حافظه اون رو در اختیار ما نمی‌ذاره. به همین دلیل نباید امنیت رو بر «پاک کردن کامل RAM» بنا کنیم. Access Token کوتاه‌عمر، Refresh Token قابل‌لغو و اعتبارسنجی سمت سرور همچنان دفاع اصلی هستن.

برای Secretهایی که خودمون تولید می‌کنیم و API اجازه میده، CharArray یا ByteArray از String کنترل‌پذیرتره، چون میشه محتوای آرایه رو بعد از استفاده بازنویسی کرد:

fun processSecret(
    secret: CharArray
) {
    try {
        authenticate(secret)
    } finally {
        secret.fill('\u0000')
    }
}

fun processSecret(
    secret: CharArray
) {
    try {
        authenticate(secret)
    } finally {
        secret.fill('\u0000')
    }
}

اما این کار هم تضمین نمی‌کنه هیچ نسخه دیگری توسط Keyboard، کتابخانه یا Runtime ساخته نشده باشه. فقط زمان ماندگاری نسخه‌ای رو که خودمون کنترل می‌کنیم کاهش میده.

یک Memory Policy برای قیمت‌بان

برای اینکه مدیریت حافظه پراکنده و سلیقه‌ای نباشه، بهتره یک سیاست ساده برای پروژه داشته باشیم. داده‌های عمومی قیمت می‌تونن داخل Room باقی بمونن و فقط صفحه فعلی وارد RAM بشه. تصاویر توسط Coil و با اندازه مقصد بارگذاری بشن. لیست‌های بزرگ با Paging دریافت بشن. Cacheهای حافظه محدود و قابل‌پاک شدن باشن. Activity و View داخل Singleton، Repository یا ViewModel نگهداری نشن. Coroutineها به lifecycleScope یا viewModelScope متصل باشن. Listenerها حتماً حذف بشن یا با Flow جایگزین بشن.

اطلاعات حساس مثل Access Token فقط در لایه احراز هویت رمزگشایی بشن و وارد UI State نشن. همچنین برنامه باید آماده باشه که فرایندش هر لحظه در پس‌زمینه متوقف بشه؛ بنابراین Cache حافظه نباید تنها نسخه اطلاعات مهم باشه.

جمع‌بندی

Memory در اندروید فقط یک عدد داخل Profiler نیست. هر Objectی که می‌سازیم، هر تصویر، هر List، هر Coroutine و هر Callback بخشی از RAM برنامه رو مصرف می‌کنه. Garbage Collector Objectهایی رو آزاد می‌کنه که دیگه قابل‌دسترسی نیستن، اما اگه Reference اون‌ها رو داخل Singleton، Listener، ViewModel یا Coroutine بلندعمر نگه داریم، حافظه آزاد نمیشه و Memory Leak شکل می‌گیره.

در این درس دیدیم که Activity Context نباید داخل Singleton نگهداری بشه، Collectionهای Flow باید با Lifecycle هماهنگ بشن، Coroutineها باید Scope مناسبی داشته باشن و ViewModel نباید Activity یا View رو نگه داره. تصاویر باید در ابعاد واقعی رابط کاربری Decode بشن، Cacheها باید محدود باشن و لیست‌های بزرگ باید با Pagination یا Paging 3 دریافت بشن. همچنین با onTrimMemory می‌تونیم Cacheهای غیرضروری رو هنگام فشار حافظه کم کنیم و با Memory Profiler و LeakCanary علت Leakها رو پیدا کنیم.

اصل مهم این درس اینه: Garbage Collector فقط آبجکت‌های بدون Reference رو پاک می‌کنه؛ این ما هستیم که باید تصمیم بگیریم هر داده و هر Object تا چه زمانی واقعاً باید زنده بمونه.

درس پنجاه‌وپنجم

Image Cache

Image Cache چیست؟

فرض کن داخل قیمت‌بان صفحه‌ای داریم که صد کالا را نمایش می‌دهد و کنار هر کالا هم تصویر آن قرار گرفته است. اگر هر بار که کاربر این صفحه را باز کند، برنامه مجبور باشد تمام تصاویر را دوباره از اینترنت دانلود کند، صفحه دیرتر باز می‌شود، مصرف اینترنت بالا می‌رود، اسکرول کردن روان نخواهد بود و حتی فشار بیشتری به سرور وارد می‌شود. به همین دلیل تقریباً تمام برنامه‌های حرفه‌ای دنیا از مفهومی به نام Image Cache استفاده می‌کنند. ایده آن هم بسیار ساده است؛ اگر قبلاً یک تصویر را دانلود کرده‌ایم، دفعه بعد به جای دانلود دوباره، همان نسخه ذخیره‌شده را نمایش می‌دهیم.

در عمل، Image Cache یکی از مهم‌ترین دلایل روان بودن رابط کاربری است. شاید کاربر اصلاً متوجه وجود آن نشود، اما اگر آن را حذف کنیم، تقریباً تمام صفحات برنامه کندتر، پرمصرف‌تر و آزاردهنده‌تر خواهند شد.

Image Cache چگونه کار می‌کند؟

فرض کن کاربر برای اولین بار صفحه محصولات را باز می‌کند. برنامه هیچ نسخه‌ای از تصاویر را ندارد، بنابراین آن‌ها را از اینترنت دانلود می‌کند. اما بعد از دانلود، فقط تصویر را نمایش نمی‌دهد؛ بلکه یک نسخه از آن را هم ذخیره می‌کند تا دفعه بعد دوباره نیازی به دانلود نباشد.

تقریباً تمام کتابخانه‌های حرفه‌ای سه مرحله را طی می‌کنند. ابتدا حافظه RAM بررسی می‌شود، چون سریع‌ترین محل دسترسی است. اگر تصویر آنجا پیدا نشود، حافظه داخلی گوشی بررسی می‌شود و اگر باز هم تصویری وجود نداشت، فایل از اینترنت دانلود می‌شود. بعد از دانلود نیز تصویر هم داخل حافظه و هم داخل Disk Cache ذخیره می‌شود تا درخواست‌های بعدی سریع‌تر انجام شوند.

Image Request
      │
      ▼
Memory Cache
      │
      ├── پیدا شد → نمایش تصویر
      │
      ▼
Disk Cache
      │
      ├── پیدا شد → نمایش تصویر
      │
      ▼
Network
      │
      ▼
دانلود تصویر
      │
      ▼
ذخیره در Disk Cache
      │
      ▼
ذخیره در Memory Cache
      │
      ▼
نمایش تصویر

به همین دلیل معمولاً اولین بار که صفحه باز می‌شود کمی زمان می‌برد، اما دفعات بعد تقریباً همه چیز بلافاصله نمایش داده می‌شود.

Memory Cache و Disk Cache چه تفاوتی دارند؟

Memory Cache داخل RAM قرار دارد و سریع‌ترین نوع Cache است. اگر کاربر بین چند صفحه جابه‌جا شود و دوباره به همان تصویر نیاز داشته باشد، معمولاً تصویر مستقیماً از RAM خوانده می‌شود و حتی نیازی به دسترسی به حافظه گوشی هم نیست. البته این Cache دائمی نیست و هر زمان سیستم به حافظه بیشتری نیاز داشته باشد یا برنامه بسته شود، ممکن است پاک شود.

در مقابل، Disk Cache داخل حافظه داخلی گوشی قرار می‌گیرد. سرعت آن از RAM کمتر است، اما همچنان چندین برابر سریع‌تر از دانلود دوباره تصویر از اینترنت است. مزیت مهم Disk Cache این است که حتی اگر برنامه را ببندیم و دوباره اجرا کنیم، تصاویر دانلودشده همچنان در اختیار برنامه خواهند بود.

به همین دلیل این دو Cache مکمل یکدیگر هستند؛ Memory Cache برای سرعت و Disk Cache برای ماندگاری.

چرا خودمان Image Cache نمی‌نویسیم؟

از نظر تئوری می‌توانیم تصاویر را خودمان دانلود کنیم، داخل فایل ذخیره کنیم و هر بار از همان فایل استفاده کنیم. اما وقتی پروژه کمی بزرگ‌تر شود، متوجه می‌شویم این کار بسیار پیچیده‌تر از چیزی است که به نظر می‌رسد.

مثلاً باید تصمیم بگیریم اگر حافظه RAM پر شد، کدام تصاویر حذف شوند. باید تصاویر خراب یا ناقص را مدیریت کنیم، اندازه مناسب برای هر تصویر را انتخاب کنیم، دانلودهای هم‌زمان را کنترل کنیم، از دانلود تکراری یک تصویر جلوگیری کنیم و حواسمان به مصرف حافظه هم باشد تا برنامه با OutOfMemoryError مواجه نشود. به همین دلیل تقریباً هیچ پروژه حرفه‌ای این سیستم را از صفر پیاده‌سازی نمی‌کند و از کتابخانه‌های تخصصی استفاده می‌کند.

چرا Coil بهترین انتخاب برای پروژه‌های Compose است؟

اگر پروژه با Jetpack Compose نوشته شده باشد، یکی از بهترین انتخاب‌ها کتابخانه Coil است. Coil کاملاً برای Kotlin و Compose طراحی شده، سبک است، از Coroutine استفاده می‌کند و تقریباً تمام کارهای مربوط به دانلود و مدیریت تصاویر را به صورت خودکار انجام می‌دهد.

ابتدا کتابخانه را اضافه می‌کنیم.

implementation("io.coil-kt:coil-compose:2.7.0")

implementation("io.coil-kt:coil-compose:2.7.0")

حالا نمایش تصویر فقط به چند خط کد نیاز دارد.

AsyncImage(
    model = product.imageUrl,
    contentDescription = product.name
)

AsyncImage(
    model = product.imageUrl,
    contentDescription = product.name
)

شاید این کد خیلی ساده به نظر برسد، اما پشت همین چند خط، Coil کارهای زیادی انجام می‌دهد. اگر تصویر قبلاً داخل Memory Cache باشد، همان را نمایش می‌دهد. اگر داخل Disk Cache باشد، آن را از حافظه می‌خواند. اگر هیچ نسخه‌ای وجود نداشته باشد، تصویر را دانلود می‌کند، Decode می‌کند، اندازه آن را متناسب با View تغییر می‌دهد و در نهایت داخل هر دو Cache ذخیره می‌کند.

نمایش Placeholder هنگام دانلود

یکی از اشتباه‌های رایج این است که تا زمان دانلود تصویر، یک فضای خالی نمایش دهیم. این کار باعث می‌شود صفحه مدام چشمک بزند و حس کندی به کاربر منتقل شود. Coil اجازه می‌دهد هنگام دانلود یک Placeholder نمایش دهیم و اگر دانلود با خطا مواجه شد، تصویر دیگری را جایگزین کنیم.

AsyncImage(
    model = ImageRequest.Builder(LocalContext.current)
        .data(product.imageUrl)
        .crossfade(true)
        .build(),
    placeholder = painterResource(R.drawable.loading),
    error = painterResource(R.drawable.no_image),
    contentDescription = product.name
)

AsyncImage(
    model = ImageRequest.Builder(LocalContext.current)
        .data(product.imageUrl)
        .crossfade(true)
        .build(),
    placeholder = painterResource(R.drawable.loading),
    error = painterResource(R.drawable.no_image),
    contentDescription = product.name
)

به این ترتیب کاربر همیشه چیزی روی صفحه می‌بیند و تجربه کاربری روان‌تر خواهد بود.

اگر تصویر روی سرور تغییر کرد چه؟

فرض کن کاربر عکس پروفایلش را عوض کرده است، اما URL تصویر همان قبلی است. در این حالت ممکن است برنامه همچنان نسخه Cacheشده را نمایش دهد. رایج‌ترین راه‌حل این است که نسخه فایل را داخل URL قرار دهیم.

https://example.com/avatar.jpg?v=2

یا

https://example.com/avatar.jpg?updated=1723456

از دید Coil این یک آدرس جدید است، بنابراین تصویر دوباره دانلود می‌شود و Cache هم به‌روزرسانی خواهد شد. این روش بسیار ساده‌تر و مطمئن‌تر از پاک کردن دستی Cache است.

چه تصاویری را بهتر است Cache نکنیم؟

همه تصاویر نباید وارد Cache شوند. بعضی تصاویر فقط یک بار استفاده می‌شوند یا اطلاعات حساسی دارند. برای مثال Captcha، QR Codeهای موقت، تصاویر احراز هویت یا فایل‌هایی که فقط چند دقیقه اعتبار دارند، معمولاً گزینه مناسبی برای Cache شدن نیستند. در این موارد بهتر است اجازه دهیم هر بار تصویر جدید از سرور دریافت شود.

جمع‌بندی

Image Cache یکی از مهم‌ترین بخش‌های هر برنامه اندرویدی است، چون مستقیماً روی سرعت، مصرف اینترنت، مصرف باتری و تجربه کاربری تأثیر می‌گذارد. تقریباً تمام برنامه‌های حرفه‌ای ابتدا Memory Cache، سپس Disk Cache و در نهایت Network را بررسی می‌کنند تا از دانلودهای غیرضروری جلوگیری شود. در پروژه‌های مبتنی بر Compose نیز کتابخانه Coil تقریباً تمام این پیچیدگی‌ها را به صورت خودکار مدیریت می‌کند؛ بنابراین به جای اینکه زمان زیادی برای پیاده‌سازی یک سیستم Cache صرف کنیم، بهتر است از ابزارهای استاندارد استفاده کنیم و تمرکزمان را روی توسعه قابلیت‌های اصلی برنامه بگذاریم.

درس پنجاه‌وششم

Lazy Loading

Lazy Loading چیست؟

فرض کن داخل قیمت‌بان صفحه‌ای داریم که هزار کالا را نمایش می‌دهد. اگر برنامه بخواهد از همان لحظه ورود کاربر، اطلاعات هر هزار کالا را از سرور دریافت کند، چند اتفاق بد می‌افتد؛ زمان زیادی صرف دانلود اطلاعات می‌شود، مصرف اینترنت بالا می‌رود، حافظه بیشتری اشغال می‌شود و مهم‌تر از همه، کاربر باید مدت زیادی منتظر بماند تا اولین صفحه نمایش داده شود.

اینجاست که مفهوم Lazy Loading وارد می‌شود. ایده آن بسیار ساده است؛ فقط چیزی را بارگذاری کن که همین حالا به آن نیاز داری و بقیه اطلاعات را زمانی دریافت کن که واقعاً لازم شوند. به همین دلیل تقریباً تمام اپلیکیشن‌های بزرگ دنیا، از اینستاگرام و یوتیوب گرفته تا دیجی‌کالا و آمازون، از Lazy Loading استفاده می‌کنند.

تفاوت Lazy Loading و Eager Loading

فرض کن سرور هزار محصول دارد. در روش Eager Loading برنامه از همان ابتدا هر هزار محصول را دریافت می‌کند؛ حتی اگر کاربر فقط ده محصول اول را ببیند.

اما در Lazy Loading ابتدا فقط اطلاعات موردنیاز، مثلاً بیست محصول اول، دریافت می‌شود. وقتی کاربر به انتهای لیست نزدیک شد، بیست محصول بعدی دانلود می‌شوند و این روند تا زمانی ادامه پیدا می‌کند که کاربر واقعاً به آن اطلاعات نیاز داشته باشد. در نتیجه، برنامه سریع‌تر اجرا می‌شود، اینترنت کمتری مصرف می‌کند و حافظه نیز بی‌دلیل اشغال نمی‌شود.

Lazy Loading در Compose

در Jetpack Compose یکی از ساده‌ترین ابزارها برای پیاده‌سازی Lazy Loading، کامپوننت LazyColumn است.

LazyColumn {
    items(products) { product ->

        ProductItem(product)

    }
}

LazyColumn {
    items(products) { product ->

        ProductItem(product)

    }
}

شاید اسم LazyColumn این تصور را ایجاد کند که فقط برای اسکرول کردن ساخته شده است، اما مهم‌ترین ویژگی آن این است که آیتم‌هایی را که خارج از صفحه قرار دارند، بی‌دلیل ایجاد نمی‌کند. فقط ویوهایی که کاربر می‌تواند ببیند ساخته می‌شوند و با اسکرول کردن، آیتم‌های جدید جایگزین آیتم‌های قبلی می‌شوند. همین موضوع باعث می‌شود مصرف حافظه به شکل محسوسی کاهش پیدا کند.

دریافت صفحه بعدی اطلاعات

فرض کن هر درخواست API فقط بیست محصول برمی‌گرداند.

اولین درخواست:

GET /products?page=1

کاربر اسکرول می‌کند و به انتهای لیست نزدیک می‌شود. در این لحظه درخواست بعدی ارسال می‌شود.

GET /products?page=2

بعد از آن:

GET /products?page=3

و همین روند تا پایان لیست ادامه پیدا می‌کند. به این روش Pagination هم گفته می‌شود و معمولاً همراه با Lazy Loading استفاده می‌شود.

تشخیص نزدیک شدن به انتهای لیست

برای اینکه بدانیم چه زمانی باید اطلاعات صفحه بعد را دریافت کنیم، می‌توانیم وضعیت اسکرول را بررسی کنیم.

val listState = rememberLazyListState()

LazyColumn(
    state = listState
) {

    items(products) { product ->

        ProductItem(product)

    }

}

val listState = rememberLazyListState()

LazyColumn(
    state = listState
) {

    items(products) { product ->

        ProductItem(product)

    }

}

حالا می‌توانیم بررسی کنیم که کاربر به انتهای لیست نزدیک شده است یا نه.

LaunchedEffect(listState) {

    snapshotFlow {

        listState.layoutInfo.visibleItemsInfo.lastOrNull()?.index

    }.collect { lastVisibleIndex ->

        if (lastVisibleIndex != null &&
            lastVisibleIndex >= products.size - 5
        ) {

            viewModel.loadNextPage()

        }

    }

}

LaunchedEffect(listState) {

    snapshotFlow {

        listState.layoutInfo.visibleItemsInfo.lastOrNull()?.index

    }.collect { lastVisibleIndex ->

        if (lastVisibleIndex != null &&
            lastVisibleIndex >= products.size - 5
        ) {

            viewModel.loadNextPage()

        }

    }

}

در این مثال، وقتی کاربر به پنج آیتم آخر نزدیک شود، صفحه بعدی اطلاعات از سرور دریافت خواهد شد. به این ترتیب، قبل از اینکه کاربر به انتهای لیست برسد، اطلاعات جدید آماده شده‌اند و اسکرول کاملاً روان باقی می‌ماند.

مراقب درخواست‌های تکراری باشید

یکی از اشتباه‌های رایج این است که هنگام اسکرول، چندین بار متوالی متد loadNextPage فراخوانی شود. در این حالت ممکن است هم‌زمان چند درخواست مشابه به سرور ارسال شوند و هم پهنای باند و هم منابع سرور هدر برود. به همین دلیل معمولاً داخل ViewModel یک متغیر برای وضعیت بارگذاری نگه می‌داریم.

private var isLoading = false

suspend fun loadNextPage() {

    if (isLoading) return

    isLoading = true

    try {

        repository.loadNextPage()

    } finally {

        isLoading = false

    }

}

private var isLoading = false

suspend fun loadNextPage() {

    if (isLoading) return

    isLoading = true

    try {

        repository.loadNextPage()

    } finally {

        isLoading = false

    }

}

به این ترتیب تا زمانی که درخواست قبلی تمام نشده باشد، درخواست جدیدی ارسال نخواهد شد.

نمایش Loading در انتهای لیست

اگر دریافت صفحه بعد چند ثانیه طول بکشد، بهتر است به کاربر اطلاع دهیم که برنامه در حال بارگذاری اطلاعات جدید است.

LazyColumn {

    items(products) { product ->

        ProductItem(product)

    }

    if (isLoading) {

        item {

            CircularProgressIndicator()

        }

    }

}

LazyColumn {

    items(products) { product ->

        ProductItem(product)

    }

    if (isLoading) {

        item {

            CircularProgressIndicator()

        }

    }

}

این کار باعث می‌شود کاربر تصور نکند برنامه متوقف شده است و تجربه کاربری بهتری داشته باشد.

Paging 3 یا Lazy Loading؟

اگر لیست نسبتاً کوچک باشد، پیاده‌سازی Lazy Loading به همین شکل کاملاً کافی است. اما وقتی با هزاران یا میلیون‌ها رکورد سروکار داریم، بهتر است از Paging 3 استفاده کنیم. این کتابخانه تقریباً تمام کارهای مربوط به Pagination، مدیریت حافظه، Retry، Refresh و هماهنگی با Compose را انجام می‌دهد و برای پروژه‌های بزرگ گزینه استاندارد اندروید محسوب می‌شود.

جمع‌بندی

Lazy Loading یکی از مهم‌ترین تکنیک‌های بهینه‌سازی عملکرد در اپلیکیشن‌های اندرویدی است. به جای اینکه همه اطلاعات را از همان ابتدا دریافت کنیم، فقط داده‌هایی بارگذاری می‌شوند که کاربر در همان لحظه به آن‌ها نیاز دارد. این کار باعث کاهش مصرف اینترنت، کاهش مصرف حافظه، افزایش سرعت اجرای برنامه و روان‌تر شدن اسکرول می‌شود. در پروژه‌های کوچک می‌توان Lazy Loading را با LazyColumn و چند درخواست صفحه‌بندی پیاده‌سازی کرد، اما برای پروژه‌های بزرگ، استفاده از Paging 3 بهترین و استانداردترین راهکار است.

درس پنجاه‌وهفتم

Performance

چرا Performance اهمیت دارد؟

وقتی درباره کیفیت یک اپلیکیشن صحبت می‌کنیم، خیلی‌ها اول از همه به ظاهر برنامه یا امکانات آن فکر می‌کنند. اما واقعیت این است که اگر یک برنامه کند باشد، حتی زیباترین طراحی دنیا هم نمی‌تواند تجربه خوبی برای کاربر بسازد. تصور کن داخل قیمت‌بان روی یک محصول لمس می‌کنی و دو یا سه ثانیه طول می‌کشد تا صفحه بعد باز شود. یا هنگام اسکرول کردن، لیست مدام گیر می‌کند و تصاویر با تأخیر نمایش داده می‌شوند. در چنین شرایطی کاربر معمولاً فکر می‌کند برنامه مشکل دارد، حتی اگر دلیل اصلی فقط بهینه نبودن کدها باشد.

Performance یعنی برنامه بتواند با کمترین مصرف منابع، سریع‌ترین و روان‌ترین تجربه ممکن را در اختیار کاربر قرار دهد. این موضوع فقط به سرعت پردازنده مربوط نمی‌شود؛ مصرف حافظه، تعداد درخواست‌های شبکه، نحوه رسم رابط کاربری و حتی تعداد Recompositionهای Compose هم روی Performance تأثیر می‌گذارند.

همیشه گلوگاه را پیدا کن

یکی از اشتباه‌های رایج این است که قبل از پیدا کردن مشکل، شروع به بهینه‌سازی کنیم. فرض کن صفحه محصولات کند باز می‌شود. شاید اولین حدس این باشد که مشکل از Recycler یا LazyColumn است، در حالی که بعد از بررسی متوجه می‌شوی ۹۰ درصد زمان صرف دانلود تصاویر از اینترنت می‌شود.

به همین دلیل همیشه قبل از هر تغییری، گلوگاه برنامه را پیدا کن. Android Studio ابزارهای بسیار خوبی مثل Profiler در اختیارمان قرار می‌دهد تا ببینیم زمان اجرای برنامه دقیقاً کجا مصرف می‌شود. اگر بدون اندازه‌گیری شروع به بهینه‌سازی کنیم، ممکن است ساعت‌ها روی بخشی کار کنیم که اصلاً مشکلی ندارد.

عملیات سنگین را روی Main Thread اجرا نکن

رابط کاربری اندروید روی Main Thread اجرا می‌شود. اگر این Thread چند ثانیه درگیر یک کار سنگین شود، برنامه دیگر نمی‌تواند به لمس کاربر پاسخ دهد و حتی ممکن است پیام Application Not Responding (ANR) نمایش داده شود.

فرض کن داخل قیمت‌بان هنگام ورود به صفحه محصولات، هزار رکورد را پردازش یا یک فایل بزرگ را از حافظه می‌خوانیم. اگر این کار روی Main Thread انجام شود، رابط کاربری کاملاً متوقف می‌شود.

راه‌حل این است که عملیات زمان‌بر را داخل Coroutine و Dispatcher مناسب اجرا کنیم.

viewModelScope.launch {

    val products = withContext(Dispatchers.IO) {

        repository.loadProducts()

    }

    _uiState.value = products

}

viewModelScope.launch {

    val products = withContext(Dispatchers.IO) {

        repository.loadProducts()

    }

    _uiState.value = products

}

به این ترتیب، عملیات شبکه یا خواندن فایل روی Thread دیگری اجرا می‌شود و رابط کاربری همچنان روان باقی می‌ماند.

از Recompositionهای غیرضروری جلوگیری کن

در Jetpack Compose هر بار که State تغییر می‌کند، بخشی از رابط کاربری دوباره رسم می‌شود. این ویژگی فوق‌العاده است، اما اگر Stateها را درست مدیریت نکنیم، ممکن است بخش بزرگی از صفحه بارها و بارها بدون دلیل دوباره ساخته شود.

فرض کن فقط تعداد محصولات داخل سبد خرید تغییر کرده است. اگر کل صفحه به همان State وابسته باشد، ممکن است صدها Composable دوباره اجرا شوند، در حالی که فقط آیکون سبد خرید نیاز به به‌روزرسانی داشته است.

به همین دلیل همیشه Stateها را تا حد ممکن کوچک و مستقل نگه دار و از ایجاد Stateهای بزرگ و همه‌کاره خودداری کن.

از LazyColumn به جای Column استفاده کن

اگر تعداد آیتم‌ها زیاد است، استفاده از Column انتخاب مناسبی نیست، چون تمام آیتم‌ها را یک‌جا می‌سازد؛ حتی آن‌هایی که هنوز روی صفحه دیده نمی‌شوند.

LazyColumn {

    items(products) { product ->

        ProductItem(product)

    }

}

LazyColumn {

    items(products) { product ->

        ProductItem(product)

    }

}

LazyColumn فقط آیتم‌هایی را می‌سازد که کاربر در همان لحظه می‌بیند. به همین دلیل هم حافظه کمتری مصرف می‌شود و هم اسکرول بسیار روان‌تر خواهد بود.

درخواست‌های شبکه را کمتر کن

گاهی مشکل Performance اصلاً از کدهای اندروید نیست. فرض کن برای نمایش هر محصول، یک درخواست جداگانه برای تصویر، یک درخواست برای قیمت و یک درخواست دیگر برای موجودی کالا ارسال کنیم. اگر صفحه بیست محصول داشته باشد، ممکن است شصت درخواست HTTP ارسال شود.

بهتر است APIها طوری طراحی شوند که اطلاعات موردنیاز هر صفحه را تا حد ممکن در یک درخواست برگردانند. این کار هم سرعت برنامه را بیشتر می‌کند و هم فشار روی سرور را کاهش می‌دهد.

تصاویر را با اندازه مناسب نمایش بده

یکی از اشتباه‌های رایج این است که یک تصویر ۴۰۰۰ در ۳۰۰۰ پیکسلی را برای یک آیکون کوچک دانلود کنیم. در این حالت هم اینترنت بیشتری مصرف می‌شود و هم Decode کردن تصویر زمان بیشتری می‌برد.

کتابخانه‌هایی مثل Coil می‌توانند تصویر را متناسب با اندازه View دریافت و پردازش کنند. به همین دلیل همیشه بهتر است از این کتابخانه‌ها استفاده کنیم و تصاویر را با اندازه واقعی موردنیاز نمایش دهیم.

از Cache استفاده کن

در درس قبل درباره Image Cache صحبت کردیم. Cache فقط مخصوص تصاویر نیست. هر داده‌ای که مرتب استفاده می‌شود و تغییرات کمی دارد، می‌تواند Cache شود.

مثلاً لیست دسته‌بندی محصولات، تنظیمات برنامه یا اطلاعات پروفایل کاربر معمولاً لازم نیست هر بار از سرور دریافت شوند. اگر این داده‌ها را Cache کنیم، هم سرعت برنامه بیشتر می‌شود و هم تعداد درخواست‌های شبکه کاهش پیدا می‌کند.

ابزارهای اندازه‌گیری را فراموش نکن

اندروید ابزارهای متعددی برای بررسی Performance در اختیار توسعه‌دهنده قرار می‌دهد. CPU Profiler میزان مصرف پردازنده را نشان می‌دهد، Memory Profiler وضعیت حافظه را بررسی می‌کند و Network Inspector تعداد و زمان درخواست‌های شبکه را نمایش می‌دهد.

بهترین برنامه‌نویس کسی نیست که همیشه حدس درستی بزند؛ بلکه کسی است که قبل از هر تصمیم، برنامه را اندازه‌گیری کند و بعد بر اساس داده واقعی مشکل را برطرف کند.

جمع‌بندی

Performance فقط به سریع بودن برنامه خلاصه نمی‌شود؛ بلکه مجموعه‌ای از تصمیم‌های درست در طراحی، مدیریت حافظه، ارتباط با شبکه و پیاده‌سازی رابط کاربری است. اگر عملیات سنگین را از Main Thread خارج کنیم، از Lazy Loading و Cache استفاده کنیم، درخواست‌های غیرضروری شبکه را حذف کنیم و Stateهای Compose را به‌درستی مدیریت کنیم، حتی روی گوشی‌های ضعیف هم می‌توان برنامه‌ای روان و لذت‌بخش ساخت. تفاوت یک اپلیکیشن معمولی با یک اپلیکیشن حرفه‌ای، معمولاً در همین جزئیات دیده می‌شود.

درس پنجاه‌وهشتم

Battery Optimization

چرا Battery Optimization اهمیت دارد؟

یکی از اشتباه‌های رایج بین برنامه‌نویس‌های تازه‌کار این است که فکر می‌کنند اگر برنامه از نظر ظاهری خوب کار کند، دیگر همه چیز تمام است. اما از دید کاربر، اگر یک اپلیکیشن باعث شود باتری گوشی زودتر خالی شود، خیلی سریع حذف خواهد شد؛ حتی اگر امکانات فوق‌العاده‌ای داشته باشد.

فرض کن کاربر قیمت‌بان را صبح باز کرده، قیمت چند کالا را دیده و بعد برنامه را بسته است. اگر برنامه بعد از بسته شدن همچنان هر چند ثانیه یک بار به سرور وصل شود، موقعیت مکانی را بخواند یا پردازش‌های غیرضروری انجام دهد، بدون اینکه کاربر متوجه شود، باتری گوشی در حال مصرف شدن است. شاید خود برنامه فقط چند دقیقه استفاده شده باشد، اما اثرش تا ساعت‌ها باقی بماند.

به همین دلیل، یکی از مهم‌ترین ویژگی‌های یک اپلیکیشن حرفه‌ای این است که وقتی لازم نیست کاری انجام دهد، واقعاً هیچ کاری انجام ندهد.

باتری بیشتر از پردازنده مصرف می‌شود یا شبکه؟

بیشتر توسعه‌دهنده‌ها تصور می‌کنند مصرف باتری فقط به پردازنده مربوط است، در حالی که ماجرا پیچیده‌تر از این است. روشن شدن آنتن شبکه، فعال شدن GPS، استفاده مداوم از دوربین، بلوتوث، Wi-Fi و حتی روشن کردن مکرر CPU، همگی روی مصرف باتری تأثیر می‌گذارند.

مثلاً اگر قیمت‌بان هر ده ثانیه یک بار برای بررسی قیمت کالاها به سرور درخواست بفرستد، شاید حجم اینترنت مصرفی ناچیز باشد، اما همین بیدار کردن مداوم رادیوی شبکه باعث مصرف قابل توجه باتری می‌شود.

به همین دلیل، تعداد دفعات انجام یک کار معمولاً از خود آن کار مهم‌تر است.

از Polling مداوم خودداری کن

فرض کن می‌خواهیم قیمت دلار یا موجودی یک کالا را به‌روز نگه داریم. ساده‌ترین راه این است که هر چند ثانیه یک درخواست جدید به سرور ارسال کنیم.

هر 10 ثانیه
│
▼
ارسال درخواست
│
▼
دریافت پاسخ
│
▼
تکرار…

این روش شاید پیاده‌سازی ساده‌ای داشته باشد، اما برای باتری و حتی سرور اصلاً مناسب نیست.

اگر اطلاعات باید به‌صورت لحظه‌ای تغییر کنند، معمولاً WebSocket انتخاب بسیار بهتری است، چون یک اتصال برقرار می‌شود و تا زمانی که لازم باشد همان اتصال حفظ می‌شود. اگر هم اطلاعات فقط هر چند ساعت یک بار تغییر می‌کنند، بهتر است از WorkManager استفاده کنیم تا اندروید خودش بهترین زمان اجرای کار را انتخاب کند.

اجازه بده اندروید زمان‌بندی را مدیریت کند

یکی از دلایل معرفی WorkManager همین موضوع بود. سیستم‌عامل بهتر از ما می‌داند چه زمانی گوشی در حال شارژ است، چه زمانی اینترنت مناسب وجود دارد و چه زمانی اجرای یک کار کمترین تأثیر را روی باتری می‌گذارد.

اگر قرار است قیمت‌بان هر شش ساعت یک بار قیمت کالاها را همگام‌سازی کند، بهتر است این کار را به WorkManager بسپاریم، نه اینکه خودمان یک سرویس دائمی اجرا کنیم. این کار هم مصرف باتری را کمتر می‌کند و هم باعث می‌شود برنامه با سیاست‌های جدید اندروید سازگار باشد.

از Wake Lock فقط در مواقع ضروری استفاده کن

گاهی لازم است هنگام انجام یک عملیات مهم، اجازه ندهیم گوشی به حالت Sleep برود. اندروید برای این کار مفهومی به نام Wake Lock دارد. اما Wake Lock یکی از پرمصرف‌ترین قابلیت‌های سیستم است. اگر اشتباه استفاده شود، ممکن است گوشی ساعت‌ها بیدار بماند و باتری با سرعت زیادی تخلیه شود. به همین دلیل فقط زمانی از Wake Lock استفاده کن که واقعاً هیچ راه‌حل دیگری وجود نداشته باشد و همیشه بعد از پایان کار آن را آزاد کن.

از Location بی‌دلیل استفاده نکن

اگر برنامه واقعاً به موقعیت مکانی نیاز ندارد، هر

بخش نهم — انتشار

درس پنجاه‌ونهم

Build Variant

Build Variant چیست؟

تا اینجا هر بار که برنامه رو اجرا کردیم، همیشه یک نسخه از اپلیکیشن ساخته شد. اما توی پروژه‌های واقعی تقریباً هیچ‌وقت فقط یک نسخه وجود نداره. فرض کن روی قیمت‌بان کار می‌کنی. خودت و اعضای تیم هر روز در حال اضافه کردن قابلیت‌های جدید هستین، ولی هم‌زمان هزاران کاربر هم دارن از نسخه اصلی برنامه استفاده می‌کنن. طبیعتاً نمی‌خوای نسخه‌ای که هنوز نصفه‌کاره است، دست کاربران واقعی برسه.

اینجاست که Build Variant به کمکمون میاد. Build Variant بهت اجازه میده از یک پروژه، چند نسخه مختلف بسازی؛ مثلاً یک نسخه برای توسعه، یک نسخه برای تست و یک نسخه برای انتشار نهایی. هر کدوم از این نسخه‌ها می‌تونن تنظیمات، آدرس سرور، آیکون، نام برنامه یا حتی قابلیت‌های متفاوتی داشته باشن، بدون اینکه مجبور بشی چند پروژه جدا نگه داری.

چرا به Build Variant نیاز داریم؟

فرض کن داخل قیمت‌بان دو سرور داری. یکی سرور اصلی که کاربران واقعی ازش استفاده می‌کنن و یکی هم سرور آزمایشی که برنامه‌نویس‌ها هر روز روش تغییر ایجاد می‌کنن.

اگر اشتباهی نسخه آزمایشی به سرور اصلی وصل بشه، ممکنه اطلاعات واقعی کاربران خراب بشه. برعکس، اگر نسخه منتشرشده به سرور تست وصل باشه، کاربران اطلاعات ناقص یا اشتباه می‌بینن.

به همین خاطر تقریباً تمام تیم‌های حرفه‌ای، محیط‌های مختلف رو از هم جدا می‌کنن و Build Variant دقیقاً برای همین کار ساخته شده.

رایج‌ترین Variantها

معمولاً پروژه‌ها حداقل سه Variant دارن.

Development نسخه‌ایه که برنامه‌نویس‌ها هر روز باهاش کار می‌کنن. توی این نسخه معمولاً لاگ‌ها فعاله، ابزارهای دیباگ وجود دارن و برنامه به سرور تست وصل میشه.

Staging تقریباً همون نسخه نهاییه، اما هنوز برای کاربران منتشر نشده. تیم تست قبل از انتشار، همه قابلیت‌ها رو روی این نسخه بررسی می‌کنه.

Release همون نسخه‌ایه که داخل Google Play منتشر میشه. این نسخه معمولاً سریع‌تره، لاگ‌های اضافی حذف شدن، کدها Obfuscate شدن و فقط به سرور اصلی وصل میشه.

Build Type با Product Flavor فرق داره

یکی از جاهایی که خیلی‌ها اول کار اشتباه می‌کنن، تفاوت بین Build Type و Product Flavor هست. Build Type مشخص می‌کنه برنامه چطوری ساخته بشه. مثلاً Debug یا Release.

اما Product Flavor مشخص می‌کنه اصلاً کدوم نسخه از برنامه ساخته بشه. مثلاً نسخه رایگان، نسخه پولی یا نسخه مخصوص یک کشور. فرض کن قیمت‌بان هم نسخه رایگان داره و هم نسخه حرفه‌ای. این تفاوت با Product Flavor مشخص میشه، نه Build Type. در عمل، این دو مفهوم با هم ترکیب میشن و Variantهای مختلف رو می‌سازن.

مثلاً:

freeDebug
freeRelease

proDebug
proRelease

یعنی چهار نسخه مختلف از یک پروژه.

تعریف Build Type

داخل فایل Gradle می‌تونیم Build Typeهای مختلف رو تعریف کنیم.

android {

    buildTypes {

        debug {

            applicationIdSuffix = ".debug"

            versionNameSuffix = "-DEBUG"

        }

        release {

            isMinifyEnabled = true

        }

    }

}

android {

    buildTypes {

        debug {

            applicationIdSuffix = ".debug"

            versionNameSuffix = "-DEBUG"

        }

        release {

            isMinifyEnabled = true

        }

    }

}

اینجا نسخه Debug با یک شناسه متفاوت نصب میشه. یعنی حتی می‌تونی نسخه اصلی و نسخه Debug رو هم‌زمان روی یک گوشی نصب داشته باشی.

تعریف Product Flavor

حالا فرض کن می‌خوای نسخه رایگان و حرفه‌ای برنامه رو از یک پروژه بسازی.

android {

    flavorDimensions += "version"

    productFlavors {

        create("free") {

            dimension = "version"

        }

        create("pro") {

            dimension = "version"

        }

    }

}

android {

    flavorDimensions += "version"

    productFlavors {

        create("free") {

            dimension = "version"

        }

        create("pro") {

            dimension = "version"

        }

    }

}

حالا اندروید استودیو خودش Variantهای مختلف رو می‌سازه و هر بار می‌تونی مشخص کنی دقیقاً کدوم نسخه Build بشه.

تنظیمات متفاوت برای هر Variant

یکی از جذاب‌ترین قابلیت‌های Build Variant اینه که هر نسخه می‌تونه تنظیمات مخصوص خودش رو داشته باشه.

مثلاً داخل نسخه Debug آدرس API این باشه:

https://test.gheimatban.com

ولی داخل نسخه Release برنامه به این آدرس وصل بشه:

https://api.gheimatban.com

یا مثلاً داخل نسخه Debug همه Logها فعال باشن، اما داخل Release هیچ اطلاعاتی داخل Logcat نوشته نشه. حتی می‌تونی اسم برنامه رو هم تغییر بدی تا موقع نصب راحت تشخیص بدی کدوم نسخه رو اجرا کردی.

مثلاً:

GheimatBan

و

GheimatBan Debug

Variant مناسب رو انتخاب کن

بالای Android Studio پنجره‌ای به نام Build Variants وجود داره. از همونجا مشخص می‌کنی که پروژه با کدوم Variant اجرا یا Build بشه. اگر روی Debug باشی، نسخه توسعه ساخته میشه. اگر Release رو انتخاب کنی، همون نسخه‌ای ساخته میشه که آماده انتشار روی Google Play هست. به همین خاطر قبل از گرفتن فایل APK یا AAB همیشه یک بار چک کن که اشتباهی روی Debug نباشی.

جمع‌بندی

Build Variant یکی از قابلیت‌هاییه که از همون روزهای اول پروژه ارزشش رو نشون میده. به جای اینکه برای هر نسخه یک پروژه جدا داشته باشی، می‌تونی همه نسخه‌ها رو داخل یک پروژه مدیریت کنی. نسخه توسعه به سرور تست وصل بشه، نسخه نهایی به سرور اصلی، نسخه رایگان قابلیت‌های محدود داشته باشه و نسخه حرفه‌ای امکانات کامل رو در اختیار کاربر بذاره. تقریباً تمام پروژه‌های حرفه‌ای اندروید از Build Variant استفاده می‌کنن، چون هم مدیریت پروژه رو ساده‌تر می‌کنه و هم احتمال خطا هنگام انتشار نسخه‌های جدید رو به شکل محسوسی کاهش میده.

درس شصتم

Signing

اصلاً چرا باید برنامه رو Sign کنیم؟

فرض کن یک شرکت خودروسازی ماشین تولید می‌کنه. قبل از اینکه ماشین از کارخانه خارج بشه، یک شماره شاسی و مهر کارخانه روی اون ثبت میشه. از اون لحظه به بعد، همه می‌تونن تشخیص بدن این ماشین واقعاً توسط همون شرکت ساخته شده یا نه.

دقیقاً همین اتفاق در اندروید هم میفته.

هر اپلیکیشنی که روی گوشی نصب میشه، باید یک امضای دیجیتال (Digital Signature) داشته باشه. این امضا مشخص می‌کنه برنامه توسط چه کسی ساخته شده و آیا از زمان ساخته شدن تا الان کسی فایلش رو دستکاری کرده یا نه. اگر فایل APK یا AAB امضا نشده باشه، اندروید اصلاً اجازه نصبش رو نمیده. پس Signing فقط یک مرحله برای انتشار برنامه نیست؛ بلکه بخشی از سیستم امنیتی اندرویده.

امضای دیجیتال یعنی چی؟

خیلی‌ها وقتی اسم امضای دیجیتال رو می‌شنون، فکر می‌کنن یعنی اسم برنامه‌نویس داخل فایل نوشته میشه. اما واقعیت کاملاً فرق داره. امضای دیجیتال بر پایه رمزنگاری ساخته شده. تو یک Key خصوصی داری که فقط باید دست خودت باشه. وقتی برنامه رو Build می‌کنی، اندروید با استفاده از اون Key یک امضای رمزنگاری‌شده روی فایل ایجاد می‌کنه. بعد هر بار که گوشی بخواد برنامه رو نصب یا آپدیت کنه، این امضا بررسی میشه.

اگر حتی یک بایت از فایل APK تغییر کرده باشه، امضا دیگه معتبر نیست و اندروید متوجه میشه فایل دستکاری شده.

یعنی Signing فقط برای شناسایی سازنده نیست؛ بلکه تضمین می‌کنه فایل دقیقاً همون چیزیه که برنامه‌نویس منتشر کرده.

چرا اندروید این‌قدر روی Signing حساسه؟

فرض کن نسخه ۱.۰ برنامه قیمت‌بان رو منتشر کردی و هزاران نفر نصبش کردن. شش ماه بعد نسخه ۲.۰ آماده میشه. حالا تصور کن یک نفر فایل APK خودش رو با همون Package Name منتشر کنه و کاربران هم اشتباهی اون نسخه رو نصب کنن.

اگر اندروید فقط Package Name رو بررسی می‌کرد، هر کسی می‌توانست خودش را جای توسعه‌دهنده اصلی جا بزند و نسخه جعلی منتشر کند. به همین خاطر اندروید علاوه بر Package Name، امضای دیجیتال را هم بررسی می‌کند. اگر نسخه جدید با همان کلیدی امضا شده باشد که نسخه قبلی با آن امضا شده بود، اندروید متوجه می‌شود این همان توسعه‌دهنده است و اجازه Update می‌دهد.

اما اگر امضا فرق کرده باشد، حتی اگر تمام فایل‌ها و Package Name یکسان باشند، اندروید آن را یک برنامه متفاوت می‌داند و اجازه جایگزین شدن نسخه قبلی را نمی‌دهد. این یکی از مهم‌ترین لایه‌های امنیتی اندروید است.

Debug Key و Release Key

وقتی اولین پروژه اندرویدت رو اجرا می‌کنی، احتمالاً هیچ Keyای نساختی. با این حال برنامه بدون مشکل روی گوشی نصب میشه. دلیلش اینه که Android Studio به‌صورت خودکار یک Debug Key برای توسعه تولید می‌کنه. این کلید فقط برای زمان برنامه‌نویسیه و هیچ‌وقت نباید باهاش برنامه منتشر بشه.

وقتی می‌خوای قیمت‌بان رو داخل Google Play منتشر کنی، باید یک Release Key مخصوص خودت داشته باشی. از اون لحظه به بعد، تمام نسخه‌های آینده برنامه باید با همین Key امضا بشن.

Keystore چیست؟

حالا سؤال مهم اینه که این Key کجا نگهداری میشه؟

اندروید فایل مخصوصی به نام Keystore داره.

Keystore مثل یک گاوصندوقه که کلیدهای رمزنگاری داخلش نگهداری میشن.

داخل این فایل اطلاعات مهمی وجود داره؛ مثل:

• کلید خصوصی
• Certificate
• Alias
• رمز عبور Keystore
• رمز عبور خود Key

در واقع وقتی می‌گی «کلید برنامه»، معمولاً منظورت همون اطلاعاتیه که داخل فایل Keystore قرار داره.

اگر Keystore رو گم کنیم چه اتفاقی میفته؟

این یکی از بزرگ‌ترین اشتباه‌هاییه که بعضی توسعه‌دهنده‌ها مرتکب میشن. فرض کن امروز نسخه ۱.۰ قیمت‌بان رو منتشر کردی. یک سال بعد نسخه ۲.۰ آماده شده، اما متوجه میشی فایل Keystore رو پاک کردی و هیچ نسخه پشتیبانی هم نداری. حالا چی میشه؟

دیگه نمی‌تونی نسخه جدید رو با همون امضا منتشر کنی. یعنی کاربران فعلی دیگه نسخه جدید رو به‌عنوان Update دریافت نمی‌کنن. در گذشته این اتفاق تقریباً فاجعه بود و بعضی توسعه‌دهنده‌ها مجبور می‌شدن یک برنامه کاملاً جدید با Package Name جدید منتشر کنن.

امروزه Google Play قابلیتی به نام Play App Signing ارائه کرده که بخش زیادی از این ریسک رو کم کرده، اما همچنان از دست دادن Keystore یا اطلاعات مربوط بهش می‌تونه دردسرهای جدی ایجاد کنه. به همین خاطر، از همون روز اول باید چند نسخه پشتیبان امن از Keystore تهیه کنی و در محل‌های مختلف نگه داری.

Android Studio چطور برنامه رو Sign می‌کنه؟

وقتی آماده انتشار باشی، از منوی Build گزینه ساخت نسخه Release رو انتخاب می‌کنی. در مراحل بعدی، Android Studio ازت اطلاعات زیر رو می‌خواد:

• فایل Keystore
• رمز Keystore
• Alias
• رمز Alias

بعد از وارد کردن این اطلاعات، برنامه با همان کلید امضا می‌شود و فایل نهایی APK یا AAB ساخته خواهد شد.

اگر اطلاعات اشتباه باشند، Build انجام نمی‌شود.

امضای خودکار در Gradle

در پروژه‌های واقعی معمولاً نمی‌خوان هر بار موقع Build کردن، رمزها رو دستی وارد کنن. به همین خاطر اطلاعات Signing داخل Gradle تعریف میشه.

نمونه ساده:

android {

    signingConfigs {

        create("release") {

            storeFile = file("release.jks")

            storePassword = "******"

            keyAlias = "gheimatban"

            keyPassword = "******"

        }

    }

}

android {

    signingConfigs {

        create("release") {

            storeFile = file("release.jks")

            storePassword = "******"

            keyAlias = "gheimatban"

            keyPassword = "******"

        }

    }

}

بعد Build Type مربوط به Release از همین تنظیمات استفاده می‌کنه.

buildTypes {

    release {

        signingConfig = signingConfigs.getByName("release")

    }

}

buildTypes {

    release {

        signingConfig = signingConfigs.getByName("release")

    }

}

البته در پروژه‌های حرفه‌ای هیچ‌وقت رمزها داخل کد نوشته نمی‌شن. معمولاً از فایل‌های محلی، Environment Variableها یا سیستم CI/CD استفاده می‌کنن تا اطلاعات حساس وارد مخزن Git نشه.

آیا میشه یک برنامه رو با کلید جدید منتشر کرد؟

اگر برنامه هنوز منتشر نشده، بله. هر زمان بخوای می‌تونی Keystore رو عوض کنی. اما بعد از اینکه نسخه اول منتشر شد و کاربران اون رو نصب کردن، داستان کاملاً فرق می‌کنه. از اون لحظه به بعد، تمام نسخه‌های بعدی باید با همان کلید امضا بشن؛ وگرنه اندروید اون‌ها رو نسخه جدید همون برنامه نمی‌شناسه.

به همین خاطر، Keystore یکی از ارزشمندترین دارایی‌های هر پروژه اندرویده. اگر سورس پروژه رو از دست بدی، شاید با داشتن نسخه پشتیبان بتونی دوباره بسازیش؛ اما اگر Keystore رو از دست بدی، ممکنه امکان انتشار نسخه‌های بعدی برای همان اپلیکیشن رو از دست بدی.

Play App Signing دقیقاً چه مشکلی رو حل می‌کنه؟

گوگل چند سالیه قابلیتی به نام Play App Signing رو معرفی کرده تا مسئولیت نگهداری کلید اصلی تا حد زیادی از دوش توسعه‌دهنده برداشته بشه. در این روش، اولین بار که برنامه رو منتشر می‌کنی، کلید اصلی امضا نزد گوگل نگهداری میشه. بعد از اون، تو معمولاً نسخه‌های جدید رو با یک Upload Key امضا می‌کنی و گوگل قبل از انتشار، فایل رو با کلید اصلی دوباره امضا می‌کنه.

مزیتش اینه که اگر Upload Key رو گم کنی، معمولاً امکان بازیابی یا جایگزین کردنش وجود داره؛ در حالی که در روش قدیمی، گم شدن کلید اصلی تقریباً به معنی پایان امکان انتشار نسخه‌های جدید بود.

البته این به معنی بی‌اهمیت شدن امنیت کلیدها نیست. همچنان باید هم Keystore و هم اطلاعات مربوط بهش رو با دقت نگهداری کنی، چون امنیت حساب توسعه‌دهنده و فرآیند انتشار برنامه به اون‌ها وابسته است.

جمع‌بندی

Signing یکی از مهم‌ترین بخش‌های انتشار اپلیکیشن اندرویده و فقط برای نصب شدن برنامه نیست. امضای دیجیتال هویت توسعه‌دهنده رو مشخص می‌کنه، جلوی دستکاری فایل رو می‌گیره و باعث میشه اندروید مطمئن باشه نسخه جدید واقعاً ادامه همون برنامه قبلیه. به همین دلیل، فایل Keystore و کلیدهای داخل اون از باارزش‌ترین دارایی‌های هر پروژه محسوب میشن و باید مثل رمز حساب بانکی ازشون محافظت کرد. وقتی مفهوم Signing رو خوب بفهمی، خیلی راحت‌تر متوجه میشی چرا گوگل روی امنیت فرآیند انتشار برنامه این‌قدر حساسه و چرا مدیریت درست کلیدها یکی از مسئولیت‌های مهم هر برنامه‌نویس اندرویده.

درس شصت‌ویکم

ProGuard

اصلاً ProGuard چه مشکلی رو حل می‌کنه؟

وقتی روی پروژه‌ای مثل قیمت‌بان چند ماه یا چند سال کار می‌کنی، کم‌کم حجم کدها زیاد میشه. کتابخانه‌های مختلف اضافه میشن، کلاس‌های زیادی ساخته میشن و بخشی از کدها هم به مرور بلااستفاده میشن. در نهایت، وقتی نسخه Release رو Build می‌کنی، ممکنه فایل APK یا AAB خیلی بزرگ‌تر از چیزی باشه که واقعاً لازمه.

اما حجم برنامه فقط یکی از مشکلاته.

فرض کن یک نفر فایل APK برنامه رو از روی گوشی استخراج کنه. اگر هیچ محافظتی وجود نداشته باشه، می‌تونه فایل رو Decompile کنه و بخش زیادی از ساختار برنامه رو ببینه؛ اسم کلاس‌ها، متدها، مدل‌های داده و حتی منطق برنامه تا حد زیادی قابل تشخیص خواهد بود. شاید نتونه دقیقاً سورس اصلی Kotlin رو به دست بیاره، اما اطلاعاتی که استخراج می‌کنه گاهی برای فهمیدن ساختار برنامه کاملاً کافیه.

اینجاست که ProGuard وارد ماجرا میشه. البته اگر بخوای دقیق‌تر بگیم، از نسخه‌های جدید Android Gradle Plugin ابزار اصلی R8 هست، نه ProGuard. با این حال، چون سال‌هاست برنامه‌نویس‌ها به این فرایند میگن «فعال کردن ProGuard»، هنوز هم این اسم بین توسعه‌دهنده‌های اندروید رایجه. در واقع، امروز R8 کارهایی رو انجام میده که قبلاً ProGuard انجام می‌داد و حتی امکانات بیشتری هم داره.

اگر ProGuard وجود نداشت چه اتفاقی می‌افتاد؟

فرض کن داخل پروژه قیمت‌بان کلاس‌هایی با اسم‌های زیر داری:

ProductRepository

UserManager

PaymentService

DiscountCalculator

ApiSecurityManager

ProductRepository

UserManager

PaymentService

DiscountCalculator

ApiSecurityManager

حتی اگر هیچ خطی از کد رو هم نخونی، فقط از روی اسم این کلاس‌ها میشه حدس زد هر بخش از برنامه چه کاری انجام میده. حالا تصور کن صدها کلاس با همین سبک داخل پروژه وجود داشته باشن. کسی که برنامه رو مهندسی معکوس می‌کنه، خیلی راحت می‌تونه معماری کلی پروژه رو درک کنه.

اما وقتی R8 یا همان چیزی که همه به اسم ProGuard می‌شناسن فعال باشه، ممکنه همین کلاس‌ها به چیزی شبیه این تبدیل بشن:

a

b

c

d

e

و متدها هم اسم‌هایی مثل این پیدا کنن:

a()

b()

c()

a()

b()

c()

حالا حتی اگر کسی برنامه رو Decompile کنه، فهمیدن اینکه هر کلاس چه کاری انجام میده، چندین برابر سخت‌تر میشه.

ProGuard دقیقاً چه کارهایی انجام میده؟

بیشتر برنامه‌نویس‌ها فکر می‌کنن ProGuard فقط اسم کلاس‌ها رو عوض می‌کنه، در حالی که این فقط یکی از وظایفشه.

اولین کاری که انجام میده Code Shrinking هست. یعنی کدهایی که هیچ‌وقت استفاده نمی‌شن رو حذف می‌کنه. فرض کن سه کتابخانه به پروژه اضافه کردی، اما فقط از ده درصد قابلیت‌های اون‌ها استفاده می‌کنی. R8 بخش زیادی از کدهای بلااستفاده رو حذف می‌کنه تا حجم برنامه کمتر بشه.

دومین کار Resource Shrinking هست. گاهی داخل پروژه عکس‌ها، آیکون‌ها یا فایل‌هایی وجود دارن که دیگه هیچ بخشی از برنامه ازشون استفاده نمی‌کنه. این فایل‌ها هم می‌تونن حذف بشن و حجم نهایی برنامه رو کمتر کنن. سومین کار Optimization هست. بعضی از کدها می‌تونن ساده‌تر یا سریع‌تر اجرا بشن. R8 در بعضی شرایط این بهینه‌سازی‌ها رو هم انجام میده.

و در نهایت مهم‌ترین بخشی که بیشتر توسعه‌دهنده‌ها باهاش آشنا هستن، Obfuscation یا مبهم‌سازی کده؛ یعنی تغییر اسم کلاس‌ها، متدها و فیلدها تا مهندسی معکوس برنامه سخت‌تر بشه.

آیا ProGuard برنامه رو غیرقابل هک می‌کنه؟

نه. این یکی از رایج‌ترین سوءتفاهم‌هاست. بعضی‌ها فکر می‌کنن اگر ProGuard رو فعال کنن، دیگه هیچ‌کس نمی‌تونه برنامه‌شون رو مهندسی معکوس کنه. واقعیت اینه که ProGuard فقط کار مهاجم رو سخت‌تر می‌کنه، نه غیرممکن.

فرض کن می‌خوای وارد یک ساختمان بشی. اگر درِ ساختمان قفل نداشته باشه، هر کسی به راحتی وارد میشه. اما اگر چند قفل، دوربین و سیستم امنیتی وجود داشته باشه، ورود خیلی سخت‌تر میشه. با این حال، هنوز هم از نظر تئوری ممکنه یک مهاجم حرفه‌ای وارد بشه. ProGuard هم دقیقاً همین نقش رو داره. هدفش این نیست که امنیت مطلق ایجاد کنه؛ هدفش اینه که زمان، هزینه و سختی مهندسی معکوس رو تا جای ممکن بالا ببره.

فعال کردن ProGuard

در نسخه Release معمولاً R8 به همین شکل فعال میشه:

buildTypes {

    release {

        isMinifyEnabled = true

        isShrinkResources = true

        proguardFiles(

            getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ),
            "proguard-rules.pro"
        )

    }

}

buildTypes {

    release {

        isMinifyEnabled = true

        isShrinkResources = true

        proguardFiles(

            getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ),
            "proguard-rules.pro"
        )

    }

}

هر کدوم از این تنظیمات یک وظیفه دارن. isMinifyEnabled باعث فعال شدن فرایند کوچک‌سازی، بهینه‌سازی و Obfuscation میشه. isShrinkResources هم منابع بلااستفاده مثل تصاویر و فایل‌های اضافی رو حذف می‌کنه. فایل proguard-rules.pro هم جاییه که قوانین مخصوص پروژه خودت رو داخلش می‌نویسی.

چرا بعضی برنامه‌ها بعد از فعال کردن ProGuard خراب میشن؟

این اتفاق بیشتر از چیزی که فکر می‌کنی رایجه. فرض کن یک کتابخانه با Reflection کار می‌کنه. یعنی اسم کلاس یا متدها رو در زمان اجرا پیدا می‌کنه. اگر R8 اسم اون کلاس‌ها رو تغییر بده، کتابخانه دیگه نمی‌تونه پیداشون کنه و برنامه Crash می‌کنه.

یا مثلاً بعضی کتابخانه‌ها از Annotationها یا Serialization استفاده می‌کنن. اگر قوانین مناسب براشون نوشته نشه، ممکنه بخشی از کلاس‌ها حذف بشن و برنامه دیگه درست کار نکنه.

به همین دلیل، فعال کردن ProGuard فقط زدن یک گزینه نیست. بعد از فعال کردنش باید نسخه Release رو کامل تست کنی، چون ممکنه مشکلی به وجود بیاد که در نسخه Debug اصلاً وجود نداشت.

فایل proguard-rules.pro چیست؟

این فایل در واقع دفترچه دستورهای تو برای R8 هست. اینجا مشخص می‌کنی چه کلاس‌هایی حذف نشن، چه کلاس‌هایی تغییر نام ندن و چه بخش‌هایی دست‌نخورده باقی بمونن. مثلاً اگر بخوای یک کلاس خاص هیچ‌وقت Obfuscate نشه، می‌تونی قانونی شبیه این بنویسی:

-keep class com.gheimatban.network.ApiService {
    *;
}

-keep class com.gheimatban.network.ApiService {
    *;
}

یعنی این کلاس و تمام اعضای داخلش باید بدون تغییر باقی بمونن. در پروژه‌های واقعی، به مرور زمان ممکنه ده‌ها یا حتی صدها قانون داخل این فایل نوشته بشه؛ مخصوصاً وقتی از کتابخانه‌های مختلف استفاده می‌کنی.

آیا همیشه باید ProGuard رو فعال کنیم؟

برای نسخه Debug معمولاً نه. دلیلش ساده است. وقتی در حال توسعه برنامه هستی، می‌خوای پیام‌های خطا واضح باشن، اسم کلاس‌ها تغییر نکرده باشه و دیباگ کردن راحت انجام بشه. اما برای نسخه Release تقریباً همیشه توصیه میشه R8 فعال باشه؛ چون هم حجم برنامه رو کمتر می‌کنه، هم اجرای بعضی بخش‌ها رو بهینه‌تر می‌کنه و هم مهندسی معکوس رو سخت‌تر می‌کنه.

به همین خاطر، اگر فایل Gradle اکثر پروژه‌های حرفه‌ای اندروید رو ببینی، متوجه میشی که isMinifyEnabled فقط برای Release فعال شده و نسخه Debug بدون این مرحله Build میشه.

جمع‌بندی

خیلی‌ها ProGuard رو فقط یک ابزار امنیتی می‌بینن، در حالی که نقشش خیلی گسترده‌تر از اینه. امروزه این وظایف توسط R8 انجام میشه؛ ابزاری که هم کدها و منابع بلااستفاده رو حذف می‌کنه، هم حجم برنامه رو کاهش میده، هم بعضی بهینه‌سازی‌ها رو انجام میده و هم با مبهم کردن نام کلاس‌ها و متدها، مهندسی معکوس رو سخت‌تر می‌کنه. البته نباید انتظار داشت که این ابزار برنامه رو غیرقابل هک کنه. هدف اصلیش اینه که استخراج و تحلیل کد برای افراد غیرمجاز زمان‌برتر و پرهزینه‌تر بشه، در حالی که خود برنامه همچنان با سرعت و حجم بهتری روی گوشی کاربران اجرا بشه.

درس شصت‌ودوم

انتشار اپلیکیشن در کافه‌بازار و گوگل‌پلی

تا اینجا برنامه قیمت‌بان رو ساختیم، نسخه Release رو از نسخه Debug جدا کردیم، امضای دیجیتال برنامه رو شناختیم و با R8 یا همون ProGuard کاری کردیم که کدهای اضافی حذف بشن و مهندسی معکوس برنامه سخت‌تر بشه. حالا باید خروجی نهایی رو از محیط توسعه بیرون بیاریم و در اختیار کاربران واقعی قرار بدیم. این مرحله فقط آپلود کردن یک فایل داخل سایت نیست. برای انتشار موفق باید نسخه برنامه رو درست تنظیم کنیم، خروجی مناسب هر مارکت رو بسازیم، مطمئن بشیم فایل با کلید صحیح امضا شده، برنامه رو روی نسخه Release آزمایش کنیم، صفحه معرفی برنامه رو کامل کنیم و بعد هم نسخه رو ابتدا در مسیر آزمایشی و سپس در مسیر عمومی منتشر کنیم.

در این درس فرض می‌کنیم نسخه اول قیمت‌بان آماده شده و می‌خوایم اون رو هم در کافه‌بازار و هم در Google Play منتشر کنیم. بخش زیادی از آماده‌سازی فنی برای هر دو مارکت مشترکه، اما نوع فایل، شیوه امضا و بعضی مراحل پنل انتشار تفاوت دارن. Google Play برای برنامه‌های جدید از Android App Bundle استفاده می‌کنه و خود گوگل از داخل فایل AAB، فایل‌های APK مناسب هر دستگاه رو تولید می‌کنه. در مارکت‌های دیگه ممکنه APK یا AAB پذیرفته بشه، اما باید قبل از هر انتشار، فرمت‌های پذیرفته‌شده و قوانین روز همون مارکت رو داخل پنل رسمی بررسی کنی؛ چون جزئیات پنل‌ها و سیاست‌های انتشار ممکنه تغییر کنن.

قبل از انتشار، نسخه Release واقعی رو آماده می‌کنیم

اولین اشتباه خطرناک اینه که برنامه رو در حالت Debug تست کنیم و تصور کنیم نسخه Release هم دقیقاً همون رفتار رو خواهد داشت. نسخه Release ممکنه از آدرس سرور متفاوتی استفاده کنه، لاگ‌هاش غیرفعال باشن، R8 کلاس‌ها رو حذف یا Obfuscate کنه، امضای متفاوتی داشته باشه و حتی بعضی سرویس‌ها مثل ورود گوگل، نقشه، Firebase یا APIهای دارای محدودیت امضا در اون کار نکنن. بنابراین چیزی که باید آزمایش بشه، دقیقاً همون فایل امضاشده‌ایه که قراره در مارکت منتشر بشه.

در فایل build.gradle.kts ماژول app باید مشخصات نسخه، شناسه برنامه و تنظیمات Release رو بررسی کنیم. نمونه زیر یک پیکربندی معقول برای نسخه اول قیمت‌بان هست:

android {
    namespace = "com.gheimatban.app"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.gheimatban.app"

        minSdk = 24
        targetSdk = 36

        versionCode = 1
        versionName = "1.0.0"
    }

    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
            versionNameSuffix = "-debug"

            isDebuggable = true
            isMinifyEnabled = false
            isShrinkResources = false
        }

        release {
            isDebuggable = false
            isMinifyEnabled = true
            isShrinkResources = true

            proguardFiles(
                getDefaultProguardFile(
                    "proguard-android-optimize.txt"
                ),
                "proguard-rules.pro"
            )
        }
    }
}

android {
    namespace = "com.gheimatban.app"
    compileSdk = 36

    defaultConfig {
        applicationId = "com.gheimatban.app"

        minSdk = 24
        targetSdk = 36

        versionCode = 1
        versionName = "1.0.0"
    }

    buildTypes {
        debug {
            applicationIdSuffix = ".debug"
            versionNameSuffix = "-debug"

            isDebuggable = true
            isMinifyEnabled = false
            isShrinkResources = false
        }

        release {
            isDebuggable = false
            isMinifyEnabled = true
            isShrinkResources = true

            proguardFiles(
                getDefaultProguardFile(
                    "proguard-android-optimize.txt"
                ),
                "proguard-rules.pro"
            )
        }
    }
}

مقدار applicationId هویت فنی برنامه در اندروید و مارکت‌هاست. کاربر معمولاً این مقدار رو نمی‌بینه، اما Google Play و کافه‌بازار برنامه رو با همین شناسه می‌شناسن. بنابراین com.gheimatban.app با com.gheimatban.android دو برنامه کاملاً متفاوت محسوب میشن. بعد از اینکه اولین نسخه رو در یک مارکت ثبت کردی، نباید شناسه برنامه رو تغییر بدی؛ چون نسخه جدید دیگه به‌عنوان به‌روزرسانی نسخه قبلی شناخته نمیشه و عملاً یک برنامه تازه به وجود میاد. Google Play هم Package Name رو یک شناسه یکتا و دائمی می‌دونه و بعد از بارگذاری فایل، نمی‌تونی اون رو برای همون برنامه عوض کنی.

وجود applicationIdSuffix = ".debug" هم باعث میشه نسخه Debug با شناسه زیر نصب بشه:

com.gheimatban.app.debug

اما نسخه Release با شناسه اصلی نصب میشه:

com.gheimatban.app

این کار بسیار مفیده، چون می‌تونی نسخه توسعه و نسخه واقعی GheimatBan رو هم‌زمان روی یک گوشی نصب داشته باشی. اگر چنین پسوندی نداشته باشی، نصب نسخه Debug ممکنه نسخه واقعی برنامه رو جایگزین کنه یا به دلیل تفاوت امضا با خطای نصب روبه‌رو بشه.

تفاوت versionCode و versionName

برای انتشار برنامه باید دو مقدار نسخه رو تنظیم کنیم:

defaultConfig {
    versionCode = 1
    versionName = "1.0.0"
}

defaultConfig {
    versionCode = 1
    versionName = "1.0.0"
}

versionName همون شماره‌ایه که کاربر می‌بینه. برای مثال می‌تونه 1.0.0، 1.1.0 یا 2.0.0 باشه. این مقدار بیشتر برای ارتباط با کاربر و تیم توسعه استفاده میشه. اما versionCode یک عدد صحیح داخلیه که اندروید و مارکت‌ها با اون تشخیص میدن کدوم نسخه جدیدتره. هر فایل جدیدی که منتشر می‌کنی باید versionCode بزرگ‌تری از تمام نسخه‌های قبلی داشته باشه. استفاده دوباره از یک versionCode قبلی باعث میشه Google Play فایل جدید رو نپذیره.

برای نسخه اول می‌تونیم این تنظیم رو داشته باشیم:

versionCode = 1
versionName = "1.0.0"

versionCode = 1
versionName = "1.0.0"

اگر یک باگ کوچک رو برطرف کردیم:

versionCode = 2
versionName = "1.0.1"

versionCode = 2
versionName = "1.0.1"

اگر یک قابلیت تازه مثل هشدار کاهش قیمت اضافه کردیم:

versionCode = 3
versionName = "1.1.0"

versionCode = 3
versionName = "1.1.0"

و اگر معماری یا تجربه کاربری برنامه به‌صورت اساسی تغییر کرد:

versionCode = 10
versionName = "2.0.0"

versionCode = 10
versionName = "2.0.0"

لازم نیست versionCode شبیه versionName باشه. می‌تونی نسخه 3.7.2 رو با versionCode = 48 منتشر کنی. نکته اصلی اینه که versionCode همیشه افزایش پیدا کنه. برای پروژه‌های تیمی بهتره افزایش این عدد بخشی از فرایند انتشار باشه تا کسی فراموشش نکنه.

اطلاعات حساس امضا رو داخل Git قرار نمی‌دیم

در درس Signing کلید انتشار رو ساختیم. حالا باید مطمئن بشیم اطلاعات Keystore داخل فایل Gradle و مخزن Git منتشر نشده. یک راه معمول اینه که اطلاعات رو داخل فایل محلی جداگانه قرار بدیم. برای مثال، در ریشه پروژه فایلی با نام keystore.properties می‌سازیم:

storeFile=../keys/gheimatban-release.jks
storePassword=YOUR_STORE_PASSWORD
keyAlias=gheimatban
keyPassword=YOUR_KEY_PASSWORD

storeFile=../keys/gheimatban-release.jks
storePassword=YOUR_STORE_PASSWORD
keyAlias=gheimatban
keyPassword=YOUR_KEY_PASSWORD

این فایل رو داخل .gitignore قرار می‌دیم:

keystore.properties
*.jks
*.keystore

keystore.properties
*.jks
*.keystore

سپس در build.gradle.kts ماژول app اطلاعات رو می‌خونیم:

import java.util.Properties

val keystoreProperties = Properties()
val keystorePropertiesFile = rootProject.file("keystore.properties")

if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(
        keystorePropertiesFile.inputStream()
    )
}

import java.util.Properties

val keystoreProperties = Properties()
val keystorePropertiesFile = rootProject.file("keystore.properties")

if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(
        keystorePropertiesFile.inputStream()
    )
}

حالا Signing Config رو می‌سازیم:

android {
    signingConfigs {
        create("release") {
            storeFile = file(
                keystoreProperties["storeFile"] as String
            )

            storePassword =
                keystoreProperties["storePassword"] as String

            keyAlias =
                keystoreProperties["keyAlias"] as String

            keyPassword =
                keystoreProperties["keyPassword"] as String
        }
    }

    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")

            isDebuggable = false
            isMinifyEnabled = true
            isShrinkResources = true

            proguardFiles(
                getDefaultProguardFile(
                    "proguard-android-optimize.txt"
                ),
                "proguard-rules.pro"
            )
        }
    }
}

android {
    signingConfigs {
        create("release") {
            storeFile = file(
                keystoreProperties["storeFile"] as String
            )

            storePassword =
                keystoreProperties["storePassword"] as String

            keyAlias =
                keystoreProperties["keyAlias"] as String

            keyPassword =
                keystoreProperties["keyPassword"] as String
        }
    }

    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")

            isDebuggable = false
            isMinifyEnabled = true
            isShrinkResources = true

            proguardFiles(
                getDefaultProguardFile(
                    "proguard-android-optimize.txt"
                ),
                "proguard-rules.pro"
            )
        }
    }
}

در این حالت هر بار که نسخه Release ساخته میشه، Gradle اون رو با کلید اصلی قیمت‌بان امضا می‌کنه. فایل Keystore و رمزها باید چند نسخه پشتیبان امن داشته باشن. اگر برنامه رو به‌صورت APK در یک مارکت منتشر کرده باشی و کلید امضای اصلی رو از دست بدی، معمولاً دیگه نمی‌تونی به‌روزرسانی سازگار با نسخه نصب‌شده کاربران تولید کنی. اندروید فقط زمانی فایل جدید رو به‌عنوان آپدیت می‌پذیره که شناسه برنامه یکسان، versionCode بزرگ‌تر و امضای مورد اعتماد سازگار باشه.

Google Play برای برنامه‌های جدید از Play App Signing استفاده می‌کنه. در این ساختار، فایل AAB رو با Upload Key امضا می‌کنی و برای گوگل می‌فرستی؛ سپس Google Play فایل‌های نهایی تحویلی به کاربران رو با App Signing Key امضا می‌کنه. بنابراین Upload Key و App Signing Key دو نقش متفاوت دارن.

ساخت فایل AAB برای Google Play

فایل AAB مستقیماً مثل APK روی گوشی نصب نمیشه. این فایل مجموعه‌ای از کدها و منابع برنامه‌ست که Google Play بر اساس مدل دستگاه، معماری پردازنده، زبان و تراکم صفحه، APKهای مناسب رو از داخل اون تولید می‌کنه. برای برنامه‌های جدید Google Play، انتشار با Android App Bundle الزام اصلیه.

برای ساخت فایل از داخل Android Studio به مسیر زیر می‌ریم:

Build
→ Generate Signed Bundle / APK

Build
→ Generate Signed Bundle / APK

سپس گزینه زیر رو انتخاب می‌کنیم:

Android App Bundle

در مرحله بعد، فایل Keystore، رمز، Alias و رمز کلید رو انتخاب می‌کنیم. Build Variant رو روی release قرار می‌دیم و ساخت فایل رو شروع می‌کنیم. بعد از پایان فرایند، معمولاً فایل در مسیری مشابه این قرار می‌گیره:

app/build/outputs/bundle/release/app-release.aab

Android Studio برای ساخت خروجی امضاشده، Wizard مخصوص Generate Signed Bundle / APK رو ارائه میده و خروجی Bundle رو داخل پوشه build/outputs/bundle/ قرار میده.

همین کار رو می‌تونیم از Terminal هم انجام بدیم. در ویندوز:

gradlew.bat bundleRelease

در macOS یا Linux:

./gradlew bundleRelease

بعد از موفقیت Build، فایل رو در این مسیر پیدا می‌کنیم:

app/build/outputs/bundle/release/app-release.aab

اگر چند Flavor داشته باشیم، نام Task تغییر می‌کنه. مثلاً اگر Flavor نهایی برنامه production باشه، ممکنه Task این باشه:

./gradlew bundleProductionRelease

و فایل خروجی در مسیری مشابه این ساخته بشه:

app/build/outputs/bundle/productionRelease/

ساخت فایل APK برای تست و مارکت‌های دیگر

برای انتشار مستقیم روی وب‌سایت، ارسال فایل به تسترها یا مارکتی که APK می‌پذیره، باید APK امضاشده Release بسازیم. از داخل Android Studio دوباره وارد این مسیر می‌شیم:

Build
→ Generate Signed Bundle / APK

Build
→ Generate Signed Bundle / APK

این بار گزینه زیر رو انتخاب می‌کنیم:

APK

بعد از انتخاب Keystore و Variant نسخه Release، فایل معمولاً در این مسیر ساخته میشه:

app/build/outputs/apk/release/app-release.apk

از خط فرمان هم می‌تونیم بنویسیم:

./gradlew assembleRelease

در ویندوز:

gradlew.bat assembleRelease

دقت کن دکمه Run در Android Studio خروجی مناسب انتشار عمومی تولید نمی‌کنه. خروجی Run ممکنه دارای testOnly باشه و فقط از طریق ADB نصب بشه. برای فایل قابل توزیع باید از Build APK یا Generate Signed Bundle / APK استفاده کنیم.

قبل از آپلود، فایل Release رو واقعاً نصب می‌کنیم

فایل AAB رو مستقیماً نمی‌تونیم مثل APK باز کنیم، اما APK Release رو باید قبل از انتشار روی یک گوشی تمیز نصب کنیم. بهتره ابتدا نسخه Debug رو حذف کنیم تا مطمئن بشیم داده‌های باقی‌مانده، ورود قبلی یا تنظیمات توسعه باعث مخفی شدن باگ‌ها نشده. سپس APK رو با ADB نصب می‌کنیم:

adb install app/build/outputs/apk/release/app-release.apk

اگر نسخه قبلی قیمت‌بان با همون امضا روی گوشی نصب شده و فقط می‌خوایم آپدیتش کنیم:

adb install -r app/build/outputs/apk/release/app-release.apk

اگر با خطایی شبیه INSTALL_FAILED_UPDATE_INCOMPATIBLE روبه‌رو شدیم، معمولاً نسخه نصب‌شده با کلید متفاوتی امضا شده. مثلاً نسخه Debug روی گوشی نصبه، اما حالا APK Release رو با همون applicationId نصب می‌کنیم. در این حالت یا باید نسخه قبلی حذف بشه یا برای Debug از applicationIdSuffix استفاده کنیم.

نسخه Release رو فقط باز نمی‌کنیم و بگیم «اجرا شد، پس سالمه». باید مسیرهای اصلی رو کامل آزمایش کنیم: ثبت‌نام، ورود، خروج، افزودن محصول، دریافت قیمت، اعلان کاهش قیمت، باز کردن Deep Link، حالت بدون اینترنت، منقضی شدن Token، آپلود عکس، اجرای برنامه بعد از بسته شدن کامل، دریافت اعلان در Foreground و Background و رفتن از اعلان به صفحه درست. اگر R8 فعاله، باید بخش‌هایی که با Reflection، Serialization یا کتابخانه‌های خاص کار می‌کنن هم بررسی بشن؛ چون احتمال داره نسخه Debug سالم باشه اما Release Crash کنه.

کنترل لاگ‌ها و آدرس سرور در نسخه نهایی

نباید نسخه نهایی قیمت‌بان به سرور تست یا Localhost متصل باشه. یکی از بهترین راه‌ها اینه که آدرس API رو بر اساس Build Type تنظیم کنیم:

android {
    buildTypes {
        debug {
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://staging-api.gheimatban.com/\""
            )
        }

        release {
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.gheimatban.com/\""
            )
        }
    }

    buildFeatures {
        buildConfig = true
    }
}

android {
    buildTypes {
        debug {
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://staging-api.gheimatban.com/\""
            )
        }

        release {
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.gheimatban.com/\""
            )
        }
    }

    buildFeatures {
        buildConfig = true
    }
}

بعد در Retrofit از همین مقدار استفاده می‌کنیم:

val retrofit = Retrofit.Builder()
    .baseUrl(BuildConfig.BASE_URL)
    .addConverterFactory(
        GsonConverterFactory.create()
    )
    .build()

val retrofit = Retrofit.Builder()
    .baseUrl(BuildConfig.BASE_URL)
    .addConverterFactory(
        GsonConverterFactory.create()
    )
    .build()

برای لاگ‌ها هم می‌تونیم یک Wrapper ساده داشته باشیم:

object AppLogger {

    fun d(tag: String, message: String) {
        if (BuildConfig.DEBUG) {
            Log.d(tag, message)
        }
    }

    fun e(
        tag: String,
        message: String,
        throwable: Throwable? = null
    ) {
        if (BuildConfig.DEBUG) {
            Log.e(tag, message, throwable)
        }
    }
}

object AppLogger {

    fun d(tag: String, message: String) {
        if (BuildConfig.DEBUG) {
            Log.d(tag, message)
        }
    }

    fun e(
        tag: String,
        message: String,
        throwable: Throwable? = null
    ) {
        if (BuildConfig.DEBUG) {
            Log.e(tag, message, throwable)
        }
    }
}

البته خطاهای واقعی نسخه Release رو نباید کاملاً نادیده بگیریم. به‌جای چاپ Token، شماره تلفن یا پاسخ کامل سرور در Logcat، بهتره Crashها و خطاهای کنترل‌شده رو با ابزاری مثل Firebase Crashlytics ثبت کنیم. موضوع Crash Reporting رو در درس جداگانه بررسی می‌کنیم.

بررسی شناسه برنامه، مجوزها و Manifest نهایی

قبل از انتشار باید Manifest ادغام‌شده رو هم بررسی کنیم. کتابخانه‌ها می‌تونن Permissionها، Serviceها، Receiverها و Providerهای خودشون رو به Manifest اضافه کنن. بنابراین فقط نگاه کردن به فایل AndroidManifest.xml پروژه کافی نیست. در Android Studio فایل Manifest رو باز می‌کنیم و تب Merged Manifest رو می‌بینیم.

برای قیمت‌بان ممکنه این مجوزها لازم باشن:

<uses-permission
    android:name="android.permission.INTERNET" />

<uses-permission
    android:name="android.permission.ACCESS_NETWORK_STATE" />

<uses-permission
    android:name="android.permission.POST_NOTIFICATIONS" />

<uses-permission
    android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

<uses-permission
    android:name="android.permission.INTERNET" />

<uses-permission
    android:name="android.permission.ACCESS_NETWORK_STATE" />

<uses-permission
    android:name="android.permission.POST_NOTIFICATIONS" />

<uses-permission
    android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

اما اگر Permission حساسی می‌بینی که برنامه واقعاً بهش نیاز نداره، نباید فقط برای راحتی نگهش داری. مارکت‌ها ممکنه درباره دسترسی‌هایی مثل موقعیت مکانی، SMS، تماس‌ها، فایل‌ها، دوربین، میکروفون یا نصب برنامه‌های ناشناس توضیح و مستندات بیشتری بخوان. علاوه بر اون، جمع‌آوری داده باید با عملکرد واقعی برنامه، صفحه Privacy Policy و فرم‌های Data Safety هماهنگ باشه. Google Play مسئولیت اعلام درست داده‌های جمع‌آوری‌شده توسط خود برنامه و SDKهای جانبی رو بر عهده توسعه‌دهنده قرار میده.

ساخت حساب و برنامه در Google Play Console

بعد از ساخت حساب توسعه‌دهنده، وارد Play Console می‌شیم و گزینه Create app رو انتخاب می‌کنیم. در این مرحله زبان اصلی، نام نمایشی برنامه، نوع App یا Game، رایگان یا پولی بودن برنامه و ایمیل پشتیبانی رو تعیین می‌کنیم. همچنین باید قوانین توسعه‌دهندگان، مقررات صادرات و شرایط Play App Signing رو تأیید کنیم.

برای پروژه ما نام برنامه می‌تونه این باشه:

قیمت‌بان

Package Name از داخل فایل AAB خونده میشه و بعد از اولین بارگذاری به برنامه متصل خواهد شد:

com.gheimatban.app

نام نمایشی بعداً قابل ویرایشه، اما Package Name رو نباید انتخاب موقت در نظر بگیری. برای مثال اگر فایل آزمایشی رو با شناسه زیر بارگذاری کنی:

com.example.gheimatban

بعداً نمی‌تونی همون برنامه ثبت‌شده رو به این شناسه تبدیل کنی:

com.gheimatban.app

مجبور میشی برنامه تازه‌ای در پنل بسازی.

صفحه معرفی برنامه در Google Play

قبل از انتشار عمومی باید Store Listing رو کامل کنیم. صفحه معرفی فقط یک فرم اداری نیست؛ ویترین قیمت‌بان محسوب میشه. کاربر قبل از نصب، نام، آیکون، توضیحات، تصاویر، امتیاز و اطلاعات حریم خصوصی رو می‌بینه و بر اساس اون‌ها تصمیم می‌گیره.

توضیح کوتاه می‌تونه چیزی شبیه این باشه:

قیمت کالاها رو دنبال کن و از کاهش قیمت‌ها باخبر شو.

توضیح کامل باید به‌جای شعارهای مبهم، مسئله و امکانات برنامه رو روشن توضیح بده:

قیمت‌بان به شما کمک می‌کند قیمت محصولات موردنظرتان را دنبال کنید و هنگام کاهش قیمت، اعلان دریافت کنید. با قیمت‌بان می‌توانید: • محصولات موردعلاقه‌تان را ذخیره کنید. • تغییرات قیمت را مشاهده کنید. • برای قیمت هدف تعیین کنید. • هنگام رسیدن محصول به قیمت دلخواه اعلان بگیرید. • فهرست محصولات را بین دستگاه‌های مختلف همگام کنید.

اسکرین‌شات‌ها هم نباید فقط تصاویر خام و نامفهوم باشن. بهتره هر تصویر یک قابلیت مشخص رو نمایش بده: صفحه پیگیری محصولات، نمودار تغییر قیمت، ساخت هشدار، اعلان کاهش قیمت و صفحه جزئیات محصول. متن روی تصویر باید کوتاه و خوانا باشه. آیکون، تصاویر و ابعاد موردنیاز ممکنه در طول زمان تغییر کنن، بنابراین عددها و محدودیت‌های دقیق رو موقع انتشار از خود Play Console بگیر، نه از یک مقاله قدیمی.

Privacy Policy و حذف حساب کاربری

قیمت‌بان حساب کاربری داره، اطلاعات محصولات ذخیره می‌کنه، به اینترنت متصله و احتمالاً از Firebase برای اعلان یا تحلیل خطا استفاده می‌کنه. پس باید یک Privacy Policy واقعی داشته باشیم. این صفحه نباید چند جمله عمومی باشه که از سایت دیگری کپی شده. باید مشخص کنه چه داده‌هایی جمع میشن، چرا جمع میشن، کجا ذخیره میشن، با چه سرویس‌هایی به اشتراک گذاشته میشن، چطور محافظت میشن، چه مدت نگهداری میشن و کاربر چطور می‌تونه درخواست حذف داده‌هاش رو ثبت کنه.

طبق سیاست فعلی Google Play، همه برنامه‌ها باید لینک Privacy Policy رو در Play Console ثبت کنن و متن یا لینک اون رو داخل خود برنامه هم در دسترس قرار بدن. حتی برنامه‌ای که داده شخصی جمع نمی‌کنه هم باید فرم مربوط رو تکمیل و Privacy Policy ارائه کنه. لینک باید عمومی، فعال و قابل دسترسی باشه.

می‌تونیم داخل صفحه تنظیمات قیمت‌بان گزینه‌ای برای باز کردن Privacy Policy قرار بدیم:

fun openPrivacyPolicy(context: Context) {
    val intent = Intent(
        Intent.ACTION_VIEW,
        Uri.parse(
            "https://gheimatban.com/privacy-policy"
        )
    )

    context.startActivity(intent)
}

fun openPrivacyPolicy(context: Context) {
    val intent = Intent(
        Intent.ACTION_VIEW,
        Uri.parse(
            "https://gheimatban.com/privacy-policy"
        )
    )

    context.startActivity(intent)
}

و در Compose:

TextButton(
    onClick = {
        openPrivacyPolicy(context)
    }
) {
    Text("سیاست حفظ حریم خصوصی")
}

TextButton(
    onClick = {
        openPrivacyPolicy(context)
    }
) {
    Text("سیاست حفظ حریم خصوصی")
}

اگر کاربر بتونه داخل برنامه حساب بسازه، Google Play الزام می‌کنه مسیر قابل‌دسترسی برای درخواست حذف حساب و داده‌های مرتبط وجود داشته باشه؛ این مسیر باید هم داخل برنامه و هم از طریق یک منبع وب در دسترس باشه. غیرفعال کردن موقت حساب جای حذف واقعی رو نمی‌گیره.

برای مثال، در تنظیمات برنامه دکمه حذف حساب داریم:

interface AccountApi {

    @DELETE("account")
    suspend fun deleteAccount(): Response<Unit>
}

interface AccountApi {

    @DELETE("account")
    suspend fun deleteAccount(): Response<Unit>
}

و در ViewModel:

class SettingsViewModel(
    private val accountApi: AccountApi,
    private val tokenStorage: TokenStorage
) : ViewModel() {

    private val _deleteState =
        MutableStateFlow<DeleteAccountState>(
            DeleteAccountState.Idle
        )

    val deleteState =
        _deleteState.asStateFlow()

    fun deleteAccount() {
        viewModelScope.launch {
            _deleteState.value =
                DeleteAccountState.Loading

            try {
                val response =
                    accountApi.deleteAccount()

                if (response.isSuccessful) {
                    tokenStorage.clear()

                    _deleteState.value =
                        DeleteAccountState.Success
                } else {
                    _deleteState.value =
                        DeleteAccountState.Error(
                            "حذف حساب انجام نشد."
                        )
                }
            } catch (exception: Exception) {
                _deleteState.value =
                    DeleteAccountState.Error(
                        "ارتباط با سرور برقرار نشد."
                    )
            }
        }
    }
}

class SettingsViewModel(
    private val accountApi: AccountApi,
    private val tokenStorage: TokenStorage
) : ViewModel() {

    private val _deleteState =
        MutableStateFlow<DeleteAccountState>(
            DeleteAccountState.Idle
        )

    val deleteState =
        _deleteState.asStateFlow()

    fun deleteAccount() {
        viewModelScope.launch {
            _deleteState.value =
                DeleteAccountState.Loading

            try {
                val response =
                    accountApi.deleteAccount()

                if (response.isSuccessful) {
                    tokenStorage.clear()

                    _deleteState.value =
                        DeleteAccountState.Success
                } else {
                    _deleteState.value =
                        DeleteAccountState.Error(
                            "حذف حساب انجام نشد."
                        )
                }
            } catch (exception: Exception) {
                _deleteState.value =
                    DeleteAccountState.Error(
                        "ارتباط با سرور برقرار نشد."
                    )
            }
        }
    }
}

و State مربوط:

sealed interface DeleteAccountState {

    data object Idle : DeleteAccountState

    data object Loading : DeleteAccountState

    data object Success : DeleteAccountState

    data class Error(
        val message: String
    ) : DeleteAccountState
}

sealed interface DeleteAccountState {

    data object Idle : DeleteAccountState

    data object Loading : DeleteAccountState

    data object Success : DeleteAccountState

    data class Error(
        val message: String
    ) : DeleteAccountState
}

سمت سرور هم نباید فقط Token رو باطل کنه. باید طبق سیاست اعلام‌شده، حساب و داده‌های مرتبط رو حذف یا در مواردی که قانون اجازه حذف فوری نمیده، روند نگهداری و حذف رو شفاف اجرا کنه.

تکمیل Data Safety در Google Play

داخل Play Console باید بخش Data Safety رو براساس رفتار واقعی قیمت‌بان پر کنیم. برای مثال باید بررسی کنیم آیا این داده‌ها جمع میشن یا نه:

نام و نام خانوادگی ایمیل یا شماره تلفن شناسه کاربر اطلاعات خرید محصولات ذخیره‌شده تاریخچه جست‌وجو شناسه دستگاه Crash Log اطلاعات عملکرد برنامه

وجود یک SDK هم می‌تونه پاسخ فرم رو تغییر بده. مثلاً اگر Firebase Crashlytics، Analytics، تبلیغات یا سرویس Push داده‌ای رو دریافت می‌کنه، نمی‌تونی فقط کدهایی رو که خودت نوشته‌ای بررسی کنی. Google Play صریحاً اعلام می‌کنه اطلاعات SDKهای شخص ثالث هم باید در فرم Data Safety لحاظ بشن و مسئولیت صحت پاسخ‌ها با توسعه‌دهنده‌ست.

اشتباه خطرناک اینه که برای سریع‌تر تمام شدن فرم، همه پاسخ‌ها رو روی «No» بگذاری. اگر عملکرد واقعی برنامه، Manifest، SDKها یا ترافیک شبکه با فرم مغایرت داشته باشه، برنامه ممکنه رد یا بعداً تعلیق بشه. فرم Data Safety، Privacy Policy و رفتار واقعی برنامه باید سه روایت یکسان از شیوه مدیریت داده ارائه بدن.

انتشار آزمایشی در Google Play

بهتره اولین فایل رو مستقیم وارد Production نکنیم. Google Play مسیرهای مختلفی برای تست داره:

Internal Testing برای تست سریع توسط گروه کوچکی از اعضای تیم یا افراد مورد اعتماد مناسبه و حداکثر تا ۱۰۰ تستر رو پشتیبانی می‌کنه. Closed Testing برای گروه کنترل‌شده بزرگ‌تره، Open Testing اجازه میده افراد بیشتری وارد آزمایش عمومی بشن و Production نسخه‌ایه که برای کاربران عمومی کشورهای انتخاب‌شده منتشر میشه.

برای اولین تست قیمت‌بان وارد مسیر Internal Testing می‌شیم، یک Release جدید می‌سازیم و فایل زیر رو آپلود می‌کنیم:

app-release.aab

بعد Release Notes رو وارد می‌کنیم:

نسخه آزمایشی اولیه قیمت‌بان

• افزودن و پیگیری محصولات
• مشاهده آخرین قیمت
• تعیین قیمت هدف
• دریافت اعلان کاهش قیمت

سپس ایمیل تسترها رو اضافه می‌کنیم و لینک عضویت در تست رو برای اون‌ها می‌فرستیم. مزیت این روش اینه که برنامه تقریباً از همون مسیر واقعی Google Play نصب میشه و به امضای Play، سرویس‌های خرید، محدودیت‌های دستگاه و فرایند تحویل واقعی نزدیک‌تره. Google Play پیشنهاد می‌کنه تست داخلی قبل از مسیرهای گسترده‌تر انجام بشه.

یک نکته مهم برای حساب‌های شخصی جدید وجود داره. براساس شرایط فعلی، حساب‌های شخصی ساخته‌شده بعد از ۱۳ نوامبر ۲۰۲۳ باید پیش از دسترسی به انتشار Production، یک Closed Test با حداقل ۱۲ تستر داشته باشن که دست‌کم ۱۴ روز پیوسته در تست عضو مونده باشن. بعد از برآورده شدن این شرط، توسعه‌دهنده باید برای Production Access درخواست بده و درباره فرایند تست و آمادگی برنامه توضیح ارائه کنه. این قانون ممکنه در آینده تغییر کنه، بنابراین مقدار دقیق شرط رو در Dashboard حساب خودت بررسی کن.

ساخت Release در Google Play

بعد از تکمیل بخش‌های اجباری برنامه وارد مسیر موردنظر می‌شیم:

Test and release
→ Testing
→ Internal testing

Test and release
→ Testing
→ Internal testing

یا برای انتشار نهایی:

Test and release
→ Production

Test and release
→ Production

سپس گزینه ساخت Release جدید رو می‌زنیم، فایل AAB رو آپلود می‌کنیم، هشدارها رو بررسی می‌کنیم و Release Notes رو می‌نویسیم. Google Play بعد از آپلود Bundle، اطلاعاتی مثل دستگاه‌های پشتیبانی‌شده، نسخه، سطح API و فایل‌های تولیدشده رو تحلیل می‌کنه. هر Release می‌تونه در وضعیت Draft، Active یا Archived قرار داشته باشه.

اگر هشدار زیر رو دیدیم:

Version code 1 has already been used

باید Gradle رو تغییر بدیم:

versionCode = 2
versionName = "1.0.1"

بعد دوباره خروجی بگیریم:

./gradlew clean bundleRelease

اگر خطای Package Name دیدیم، باید بررسی کنیم فایل مربوط به Variant درست رو ساخته‌ایم. ممکنه به‌جای نسخه Production، فایل Flavor آزمایشی رو با شناسه زیر بارگذاری کرده باشیم:

com.gheimatban.app.staging

در حالی که برنامه ثبت‌شده این شناسه رو انتظار داره:

com.gheimatban.app

اگر خطای Signing دیدیم، معمولاً Bundle با Upload Key صحیح امضا نشده یا برنامه‌ای که قبلاً ثبت شده از کلید دیگری استفاده می‌کنه.

انتشار در کافه‌بازار

برای کافه‌بازار هم ابتدا باید حساب توسعه‌دهنده و اطلاعات هویتی یا حقوقی رو تکمیل کنیم، سپس داخل پیشخان یک برنامه جدید بسازیم. روند کلی شامل ساخت برنامه، انتخاب دسته‌بندی، بارگذاری بسته، تکمیل نام و توضیحات، بارگذاری آیکون و تصاویر، درج اطلاعات پشتیبانی و ارسال نسخه برای بررسی یا انتشار میشه. نام دقیق گزینه‌ها و فرمت‌های قابل‌قبول ممکنه با تغییرات پیشخان عوض بشه، بنابراین هنگام انتشار باید راهنمای داخل خود پنل رو مرجع نهایی قرار بدی.

بسته‌ای که بارگذاری می‌کنی باید نسخه Release امضاشده باشه، نه APK Debug. اگر پنل برای برنامه تو APK بخواد، فایل مناسب اینه:

app/build/outputs/apk/release/app-release.apk

اگر AAB پذیرفته بشه و بخوای Bundle منتشر کنی، فایل اینه:

app/build/outputs/bundle/release/app-release.aab

کافه‌بازار پشتیبانی از انتشار App Bundle رو اعلام کرده، اما چون قابلیت‌ها و الزامات پنل ممکنه تغییر کنن، انتخاب نهایی رو براساس گزینه‌های فعال در پیشخان انجام بده.

برای توضیح کوتاه بازار می‌تونیم بنویسیم:

با قیمت‌بان، تغییر قیمت محصولات رو دنبال کن و هنگام رسیدن به قیمت دلخواه باخبر شو.

توضیح کامل فارسی هم باید خوانا، دقیق و بدون وعده غیرواقعی باشه. اگر قیمت‌بان قیمت‌ها رو با تأخیر به‌روزرسانی می‌کنه، نباید بنویسیم «تمام قیمت‌های بازار در هر ثانیه به‌صورت قطعی و لحظه‌ای». توضیحات صفحه مارکت بخشی از تعهد محصول به کاربره.

یک برنامه در دو مارکت و مسئله امضا

بهتره نسخه Google Play و کافه‌بازار از یک Package Name استفاده کنن تا از دید اندروید یک برنامه باشن:

com.gheimatban.app

اما باید با دقت درباره مدل امضا تصمیم بگیری. Google Play در حالت Play App Signing، APK نهایی کاربران رو با App Signing Key خودش امضا می‌کنه. اگر نسخه کافه‌بازار رو با کلید محلی متفاوتی امضا کنی، کاربری که نسخه یک مارکت رو نصب کرده نمی‌تونه نسخه مارکت دیگه رو به‌عنوان آپدیت روی همون نصب دریافت کنه؛ چون امضاها متفاوتن. در بعضی سناریوها این موضوع مهم نیست، چون هر کاربر از همون مارکت خودش آپدیت می‌گیره. اما اگر می‌خوای امکان جابه‌جایی بین مارکت‌ها وجود داشته باشه، باید راهبرد امضا رو از ابتدا آگاهانه طراحی کنی.

یک راه دیگه اینه که برای هر مارکت Application ID متفاوت تعریف کنیم:

android {
    flavorDimensions += "store"

    productFlavors {
        create("googlePlay") {
            dimension = "store"
            applicationId = "com.gheimatban.app"
        }

        create("bazaar") {
            dimension = "store"
            applicationId = "com.gheimatban.app.bazaar"
        }
    }
}

android {
    flavorDimensions += "store"

    productFlavors {
        create("googlePlay") {
            dimension = "store"
            applicationId = "com.gheimatban.app"
        }

        create("bazaar") {
            dimension = "store"
            applicationId = "com.gheimatban.app.bazaar"
        }
    }
}

در این حالت دو برنامه مستقل ایجاد میشن و حتی می‌تونن هم‌زمان روی گوشی نصب بشن. اما این کار معایبی هم داره: آمار نصب، Deep Link، Firebase، OAuth، اعلان‌ها، تنظیمات Backend و مدیریت نسخه‌ها از هم جدا میشن. برای بیشتر برنامه‌ها بهتره بدون دلیل جدی، Package Name رو بین مارکت‌ها جدا نکنیم.

می‌تونیم Flavorها رو فقط برای وابستگی‌های مخصوص مارکت استفاده کنیم و Application ID رو یکسان نگه داریم:

android {
    flavorDimensions += "store"

    productFlavors {
        create("googlePlay") {
            dimension = "store"

            buildConfigField(
                "String",
                "STORE_NAME",
                "\"Google Play\""
            )
        }

        create("bazaar") {
            dimension = "store"

            buildConfigField(
                "String",
                "STORE_NAME",
                "\"Cafe Bazaar\""
            )
        }
    }
}

android {
    flavorDimensions += "store"

    productFlavors {
        create("googlePlay") {
            dimension = "store"

            buildConfigField(
                "String",
                "STORE_NAME",
                "\"Google Play\""
            )
        }

        create("bazaar") {
            dimension = "store"

            buildConfigField(
                "String",
                "STORE_NAME",
                "\"Cafe Bazaar\""
            )
        }
    }
}

حالا اگر بخوایم صفحه برنامه در مارکت مربوط رو باز کنیم، می‌تونیم براساس Flavor رفتار متفاوتی داشته باشیم:

fun openStorePage(context: Context) {
    val packageName = context.packageName

    val uri = when (BuildConfig.STORE_NAME) {
        "Cafe Bazaar" -> {
            Uri.parse(
                "bazaar://details?id=$packageName"
            )
        }

        else -> {
            Uri.parse(
                "market://details?id=$packageName"
            )
        }
    }

    val intent = Intent(
        Intent.ACTION_VIEW,
        uri
    )

    context.startActivity(intent)
}

fun openStorePage(context: Context) {
    val packageName = context.packageName

    val uri = when (BuildConfig.STORE_NAME) {
        "Cafe Bazaar" -> {
            Uri.parse(
                "bazaar://details?id=$packageName"
            )
        }

        else -> {
            Uri.parse(
                "market://details?id=$packageName"
            )
        }
    }

    val intent = Intent(
        Intent.ACTION_VIEW,
        uri
    )

    context.startActivity(intent)
}

برای اینکه در صورت نصب نبودن مارکت برنامه Crash نکنه، نسخه مقاوم‌تری می‌نویسیم:

fun openStorePage(context: Context) {
    val packageName = context.packageName

    val primaryUrl = when (BuildConfig.STORE_NAME) {
        "Cafe Bazaar" -> {
            "bazaar://details?id=$packageName"
        }

        else -> {
            "market://details?id=$packageName"
        }
    }

    val fallbackUrl = when (BuildConfig.STORE_NAME) {
        "Cafe Bazaar" -> {
            "https://cafebazaar.ir/app/$packageName"
        }

        else -> {
            "https://play.google.com/store/apps/details?id=$packageName"
        }
    }

    try {
        context.startActivity(
            Intent(
                Intent.ACTION_VIEW,
                Uri.parse(primaryUrl)
            )
        )
    } catch (exception: ActivityNotFoundException) {
        context.startActivity(
            Intent(
                Intent.ACTION_VIEW,
                Uri.parse(fallbackUrl)
            )
        )
    }
}

fun openStorePage(context: Context) {
    val packageName = context.packageName

    val primaryUrl = when (BuildConfig.STORE_NAME) {
        "Cafe Bazaar" -> {
            "bazaar://details?id=$packageName"
        }

        else -> {
            "market://details?id=$packageName"
        }
    }

    val fallbackUrl = when (BuildConfig.STORE_NAME) {
        "Cafe Bazaar" -> {
            "https://cafebazaar.ir/app/$packageName"
        }

        else -> {
            "https://play.google.com/store/apps/details?id=$packageName"
        }
    }

    try {
        context.startActivity(
            Intent(
                Intent.ACTION_VIEW,
                Uri.parse(primaryUrl)
            )
        )
    } catch (exception: ActivityNotFoundException) {
        context.startActivity(
            Intent(
                Intent.ACTION_VIEW,
                Uri.parse(fallbackUrl)
            )
        )
    }
}

انتشار نسخه دوم قیمت‌بان

فرض کن نسخه 1.0.0 منتشر شده و کاربران گزارش دادن بعد از قطع و وصل شدن اینترنت، بعضی قیمت‌ها تازه‌سازی نمیشن. مشکل رو اصلاح کردیم و حالا می‌خوایم نسخه جدید منتشر کنیم. اول نسخه رو افزایش می‌دیم:

defaultConfig {
    versionCode = 2
    versionName = "1.0.1"
}

defaultConfig {
    versionCode = 2
    versionName = "1.0.1"
}

سپس تست‌ها رو اجرا می‌کنیم:

./gradlew test

اگر تست‌های Instrumented داریم:

./gradlew connectedAndroidTest

بعد خروجی Release رو می‌سازیم:

./gradlew clean bundleRelease
./gradlew assembleRelease

AAB رو برای Google Play و APK یا AAB موردنیاز رو برای کافه‌بازار آپلود می‌کنیم. Release Notes نسخه دوم باید برای کاربر قابل‌فهم باشه:

تغییرات نسخه ۱.۰.۱ • برطرف شدن مشکل به‌روزرسانی قیمت پس از اتصال مجدد اینترنت • بهبود سرعت نمایش فهرست محصولات • رفع چند خطای جزئی

نوشتن عبارت‌هایی مثل «Bug Fix» یا «بهبودهای مختلف» برای تمام نسخه‌ها اطلاعات مفیدی به کاربر نمیده. لازم نیست جزئیات فنی بنویسیم، اما باید مشخص باشه نسخه چه چیزی رو بهتر کرده.

خطاهای رایج زمان انتشار

یکی از خطاهای متداول اینه که نسخه Release به API وصل نمیشه، در حالی که Debug درست کار می‌کنه. معمولاً آدرس BASE_URL اشتباهه، فایل تنظیمات Release ناقصه، Certificate Pinning با گواهی واقعی هماهنگ نیست یا سرور درخواست‌های نسخه نهایی رو رد می‌کنه.

خطای دوم مربوط به Firebaseه. اگر امضای Release با Debug فرق داشته باشه، ممکنه سرویس‌هایی مثل Google Sign-In درست کار نکنن. باید SHA-1 و SHA-256 کلید مربوط رو استخراج کنیم:

keytool -list -v \
-keystore gheimatban-release.jks \
-alias gheimatban

keytool -list -v \
-keystore gheimatban-release.jks \
-alias gheimatban

در ویندوز هم دستور به همین صورته و فقط مسیر فایل ممکنه فرق کنه. اثر انگشت‌های لازم رو در تنظیمات Firebase یا سرویس مربوط ثبت می‌کنیم. در Google Play باید توجه کنیم که گواهی App Signing نهایی ممکنه با Upload Key متفاوت باشه؛ پس برای بعضی سرویس‌ها باید SHA گواهی App Signing موجود در Play Console هم اضافه بشه.

خطای سوم، Crash شدن نسخه Release به دلیل R8 هست. در این حالت باید Stack Trace رو با فایل Mapping تحلیل کنیم. فایل Mapping معمولاً در این مسیر ساخته میشه:

app/build/outputs/mapping/release/mapping.txt

این فایل رو برای هر نسخه نگه می‌داریم. اگر Stack Trace مبهم‌شده داشته باشیم، می‌تونیم اون رو Retrace کنیم. حذف این فایل باعث میشه تحلیل Crashهای Obfuscateشده بسیار سخت‌تر بشه.

خطای چهارم، فراموش کردن افزایش versionCode هست. پیش از هر Build انتشار باید این مقدار رو بررسی کنیم. خطای پنجم هم آپلود کردن Variant اشتباهه؛ مثلاً stagingRelease به‌جای productionRelease. نام سرور، Package Name و حتی آیکون برنامه می‌تونه در این دو Variant متفاوت باشه.

چک‌لیست عملی قبل از انتشار

قبل از اینکه نسخه قیمت‌بان رو برای بررسی نهایی بفرستیم، این موارد رو یک‌بار کامل کنترل می‌کنیم:

• applicationId نهایی و صحیح باشه.
• versionCode از تمام نسخه‌های قبلی بزرگ‌تر باشه.
• versionName درست نمایش داده بشه.
• فایل با Keystore صحیح امضا شده باشه.
• نسخه Release روی گوشی واقعی نصب و تست شده باشه.
• ورود، خروج، ثبت‌نام و حذف حساب کار کنن.
• API نسخه نهایی به سرور Production متصل باشه.
• Log شامل Token، رمز، شماره تلفن یا پاسخ حساس سرور نباشه.
• R8 باعث Crash یا حذف مدل‌ها نشده باشه.
• اعلان‌ها در Foreground و Background کار کنن.
• Deep Linkها به صفحه درست برن.
• آیکون و نام Release صحیح باشن.
• Permission اضافی داخل Merged Manifest وجود نداشته باشه.
• Privacy Policy با رفتار واقعی برنامه هماهنگ باشه.
• Data Safety براساس SDKها و داده‌های واقعی تکمیل شده باشه.
• لینک حذف حساب فعال باشه.
• اسکرین‌شات‌ها و توضیحات مارکت نهایی شده باشن.
• mapping.txt نسخه Release ذخیره شده باشه.
• Keystore و رمزهای اون پشتیبان امن داشته باشن.
• Release Notes نوشته شده باشه.
• نسخه ابتدا در مسیر آزمایشی منتشر شده باشه.

جمع‌بندی

انتشار اپلیکیشن صرفاً گرفتن یک APK و گذاشتن اون داخل یک مارکت نیست. ما باید هویت ثابت برنامه رو با applicationId مشخص کنیم، نسخه‌ها رو با versionCode مدیریت کنیم، فایل Release رو با کلید درست امضا کنیم، AAB مناسب Google Play و خروجی مناسب کافه‌بازار رو بسازیم، دقیقاً همون نسخه نهایی رو روی دستگاه واقعی آزمایش کنیم و اطلاعات حریم خصوصی، حذف حساب، داده‌های جمع‌آوری‌شده و صفحه معرفی برنامه رو با رفتار واقعی محصول هماهنگ نگه داریم.

برای انتشار نسخه اول قیمت‌بان، مسیر مطمئن اینه که ابتدا APK Release رو روی چند دستگاه آزمایش کنیم، AAB امضاشده رو در Internal Testing گوگل‌پلی قرار بدیم، تسترها مسیرهای اصلی برنامه رو بررسی کنن، سپس شرایط Closed Testing و Production حساب رو تکمیل کنیم. هم‌زمان نسخه مناسب کافه‌بازار رو در پیشخان بارگذاری می‌کنیم و بعد از بررسی اطلاعات، اون رو برای انتشار می‌فرستیم. از نسخه دوم به بعد هم هر بار versionCode رو افزایش می‌دیم، خروجی تازه می‌سازیم، Release Notes می‌نویسیم و به‌جای انتشار عجولانه برای تمام کاربران، ابتدا نسخه رو روی گروه کوچکی آزمایش می‌کنیم. این فرایند باعث میشه انتشار برنامه از یک اتفاق پرریسک به یک روند کنترل‌شده و قابل‌تکرار تبدیل بشه.

درس شصت‌وسوم

مقیاس‌پذیری و مدیریت کاربران هم‌زمان

تا وقتی قیمت‌بان فقط روی گوشی خودت و چند نفر از دوستانت نصبه، تقریباً هر معماری‌ای خوب به نظر می‌رسه. کاربر صفحه محصولات رو باز می‌کنه، برنامه یک درخواست به API می‌فرسته، سرور از دیتابیس اطلاعات رو می‌خونه و جواب رو برمی‌گردونه. چون تعداد درخواست‌ها کمه، حتی اگر Queryها بهینه نباشن، پاسخ API کمی سنگین باشه یا کاربر با هر بار لمس دکمه چند درخواست تکراری ایجاد کنه، احتمالاً هیچ مشکلی دیده نمیشه. اما وقتی تعداد کاربران افزایش پیدا می‌کنه، ضعف‌هایی که قبلاً پنهان بودن هم‌زمان خودشون رو نشون میدن؛ CPU سرور درگیر میشه، تعداد اتصال‌های دیتابیس بالا میره، صف درخواست‌ها طولانی میشه، زمان پاسخ افزایش پیدا می‌کنه و کاربران برای اینکه صفحه باز نشده دوباره دکمه رو لمس می‌کنن. همین رفتار، درخواست‌های بیشتری تولید می‌کنه و فشار سیستم رو شدیدتر می‌کنه.

مقیاس‌پذیری یعنی سیستم با افزایش تعداد کاربران و حجم درخواست‌ها، همچنان بتونه عملکرد قابل‌قبولی داشته باشه. این تعریف به این معنا نیست که یک سرور باید بی‌نهایت درخواست رو تحمل کنه. هیچ سیستم واقعی ظرفیت نامحدود نداره. مسئله اینه که معماری برنامه طوری طراحی بشه که با رشد کاربران، بتونیم ظرفیت رو به‌شکل کنترل‌شده افزایش بدیم و از تولید درخواست‌های غیرضروری جلوگیری کنیم. مدیریت چند هزار کاربر هم‌زمان فقط مسئولیت Backend نیست؛ اپلیکیشن اندروید هم می‌تونه با Cache، Pagination، Debounce، Retry صحیح و همگام‌سازی هوشمند، بخش بزرگی از فشار غیرضروری روی سرور رو کم کنه.

«کاربر هم‌زمان» دقیقاً یعنی چی؟

فرض کن قیمت‌بان صد هزار کاربر ثبت‌شده داشته باشه. این عدد به‌تنهایی نمیگه سرور باید در هر لحظه صد هزار درخواست رو پاسخ بده. ممکنه فقط پنج هزار نفر در یک ساعت مشخص برنامه رو باز کنن و هرکدوم هم چند درخواست بفرستن. بنابراین برای سنجش فشار واقعی سیستم، باید به تعداد درخواست در ثانیه، زمان پردازش هر درخواست، تعداد اتصال‌های فعال و حجم داده منتقل‌شده توجه کنیم.

فرض کن ده هزار کاربر تقریباً در یک زمان برنامه رو باز می‌کنن و صفحه اصلی قیمت‌بان هنگام اجرا سه API رو فراخوانی می‌کنه:

GET /profile
GET /tracked-products
GET /notifications/unread-count

در این حالت، ده هزار کاربر می‌تونن در مدت کوتاهی سی هزار درخواست تولید کنن. اگر WorkManager هم هم‌زمان قیمت‌ها رو Sync کنه و هر محصول جداگانه از سرور درخواست بشه، تعداد درخواست‌ها خیلی بیشتر میشه. مثلاً اگر هر کاربر پنجاه محصول ذخیره‌شده داشته باشه و برنامه برای هر محصول یک درخواست بفرسته، ده هزار کاربر می‌تونن پانصد هزار درخواست ایجاد کنن:

10,000 users × 50 products = 500,000 requests

مشکل اصلی همیشه تعداد کاربران نیست؛ گاهی طراحی اشتباه API و رفتار اپلیکیشن باعث میشه یک کاربر به‌اندازه ده‌ها کاربر به سرور فشار وارد کنه. به همین دلیل قبل از خرید سرور قوی‌تر باید بفهمیم درخواست‌ها از کجا تولید میشن و آیا واقعاً ضروری هستن یا نه.

اولین قانون مقیاس‌پذیری: درخواست غیرضروری رو اصلاً ایجاد نکن

بهینه‌ترین درخواست، درخواستی نیست که سرور اون رو در ده میلی‌ثانیه پاسخ بده؛ بهینه‌ترین درخواست، درخواستیه که اصلاً لازم نباشه به سرور ارسال بشه. فرض کن کاربر در صفحه جست‌وجوی قیمت‌بان عبارت «لپ‌تاپ» رو تایپ می‌کنه. اگر با وارد شدن هر حرف فوراً API جست‌وجو فراخوانی بشه، تایپ همین یک کلمه می‌تونه چند درخواست تولید کنه:

ل
لپ
لپ‌
لپ‌ت
لپ‌تا
لپ‌تاپ

پیاده‌سازی ساده ممکنه به این شکل باشه:

fun onSearchTextChanged(query: String) {
    viewModelScope.launch {
        repository.searchProducts(query)
    }
}

fun onSearchTextChanged(query: String) {
    viewModelScope.launch {
        repository.searchProducts(query)
    }
}

در این مدل، هر تغییر متن یک Coroutine تازه و یک درخواست شبکه ایجاد می‌کنه. اگر کاربر سریع تایپ کنه، درخواست مربوط به عبارت ناقص هنوز در حال اجراست که درخواست بعدی فرستاده میشه. حتی ممکنه پاسخ درخواست قدیمی دیرتر برگرده و نتیجه جدیدتر رو با داده منسوخ جایگزین کنه.

راه مناسب استفاده از StateFlow، debounce و distinctUntilChanged هست:

class ProductSearchViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val searchQuery =
        MutableStateFlow("")

    val searchResult =
        searchQuery
            .map { query ->
                query.trim()
            }
            .debounce(500)
            .distinctUntilChanged()
            .flatMapLatest { query ->
                if (query.length < 2) {
                    flowOf(emptyList())
                } else {
                    repository.searchProducts(query)
                }
            }
            .stateIn(
                scope = viewModelScope,
                started = SharingStarted.WhileSubscribed(5_000),
                initialValue = emptyList()
            )

    fun onSearchTextChanged(query: String) {
        searchQuery.value = query
    }
}

class ProductSearchViewModel(
    private val repository: ProductRepository
) : ViewModel() {

    private val searchQuery =
        MutableStateFlow("")

    val searchResult =
        searchQuery
            .map { query ->
                query.trim()
            }
            .debounce(500)
            .distinctUntilChanged()
            .flatMapLatest { query ->
                if (query.length < 2) {
                    flowOf(emptyList())
                } else {
                    repository.searchProducts(query)
                }
            }
            .stateIn(
                scope = viewModelScope,
                started = SharingStarted.WhileSubscribed(5_000),
                initialValue = emptyList()
            )

    fun onSearchTextChanged(query: String) {
        searchQuery.value = query
    }
}

debounce(500) صبر می‌کنه تا کاربر برای پانصد میلی‌ثانیه تایپ رو متوقف کنه. distinctUntilChanged() اجازه نمیده عبارت یکسان دوباره پردازش بشه و flatMapLatest هم وقتی عبارت جدیدی وارد میشه، دریافت نتیجه قبلی رو کنار می‌گذاره. بنابراین تایپ یک کلمه معمولاً به‌جای شش درخواست، فقط یک درخواست نهایی تولید می‌کنه. این تغییر روی یک گوشی ساده به نظر می‌رسه، اما در مقیاس ده‌ها هزار کاربر می‌تونه میلیون‌ها درخواست اضافی رو حذف کنه.

همین منطق برای دکمه Refresh هم لازمه. کاربر ممکنه به‌خاطر کند بودن اینترنت چند بار پشت سر هم دکمه رو لمس کنه. اگر هر لمس یک درخواست مستقل بسازه، برنامه ناخواسته حمله کوچکی علیه سرور خودش انجام میده. ساده‌ترین راه اینه که هنگام اجرای درخواست، دکمه غیرفعال بشه:

data class PriceUiState(
    val isLoading: Boolean = false,
    val products: List<Product> = emptyList(),
    val errorMessage: String? = null
)

data class PriceUiState(
    val isLoading: Boolean = false,
    val products: List<Product> = emptyList(),
    val errorMessage: String? = null
)

class PriceViewModel(
    private val repository: PriceRepository
) : ViewModel() {

    private val _uiState =
        MutableStateFlow(PriceUiState())

    val uiState =
        _uiState.asStateFlow()

    fun refreshPrices() {
        if (_uiState.value.isLoading) {
            return
        }

        viewModelScope.launch {
            _uiState.update {
                it.copy(
                    isLoading = true,
                    errorMessage = null
                )
            }

            runCatching {
                repository.refreshPrices()
            }.onSuccess { products ->
                _uiState.value = PriceUiState(
                    isLoading = false,
                    products = products
                )
            }.onFailure {
                _uiState.update { state ->
                    state.copy(
                        isLoading = false,
                        errorMessage =
                            "به‌روزرسانی قیمت‌ها انجام نشد."
                    )
                }
            }
        }
    }
}

class PriceViewModel(
    private val repository: PriceRepository
) : ViewModel() {

    private val _uiState =
        MutableStateFlow(PriceUiState())

    val uiState =
        _uiState.asStateFlow()

    fun refreshPrices() {
        if (_uiState.value.isLoading) {
            return
        }

        viewModelScope.launch {
            _uiState.update {
                it.copy(
                    isLoading = true,
                    errorMessage = null
                )
            }

            runCatching {
                repository.refreshPrices()
            }.onSuccess { products ->
                _uiState.value = PriceUiState(
                    isLoading = false,
                    products = products
                )
            }.onFailure {
                _uiState.update { state ->
                    state.copy(
                        isLoading = false,
                        errorMessage =
                            "به‌روزرسانی قیمت‌ها انجام نشد."
                    )
                }
            }
        }
    }
}

در رابط Compose هم وضعیت دکمه رو به isLoading متصل می‌کنیم:

Button(
    onClick = viewModel::refreshPrices,
    enabled = !uiState.isLoading
) {
    if (uiState.isLoading) {
        CircularProgressIndicator()
    } else {
        Text("به‌روزرسانی قیمت‌ها")
    }
}

Button(
    onClick = viewModel::refreshPrices,
    enabled = !uiState.isLoading
) {
    if (uiState.isLoading) {
        CircularProgressIndicator()
    } else {
        Text("به‌روزرسانی قیمت‌ها")
    }
}

این کنترل فقط برای تجربه کاربری نیست؛ بخشی از حفاظت ظرفیت سرور محسوب میشه.

همه اطلاعات رو یک‌جا دریافت نکن

فرض کن یک کاربر در قیمت‌بان پنج هزار محصول رو دنبال می‌کنه. اگر API تمام محصولات رو در یک پاسخ برگردونه، سرور باید پنج هزار ردیف رو از دیتابیس بخونه، اون‌ها رو تبدیل به JSON کنه و روی شبکه بفرسته. اپلیکیشن هم باید کل پاسخ رو در حافظه نگه داره، Parse کنه و در دیتابیس محلی ذخیره کنه؛ در حالی که کاربر در لحظه فقط چند محصول اول رو می‌بینه.

API نامناسب ممکنه این‌طور طراحی شده باشه:

GET /tracked-products

و بدون محدودیت، همه رکوردها رو برگردونه. API مناسب باید Pagination داشته باشه:

GET /tracked-products?page=1&pageSize=30

یا در سیستم‌های بزرگ‌تر از Cursor استفاده کنه:

GET /tracked-products?cursor=eyJpZCI6MTUwMH0=&limit=30

در Retrofit می‌تونیم Endpoint صفحه‌بندی‌شده تعریف کنیم:

interface ProductApi {

    @GET("tracked-products")
    suspend fun getTrackedProducts(
        @Query("page") page: Int,
        @Query("pageSize") pageSize: Int
    ): ProductPageDto
}

interface ProductApi {

    @GET("tracked-products")
    suspend fun getTrackedProducts(
        @Query("page") page: Int,
        @Query("pageSize") pageSize: Int
    ): ProductPageDto
}

data class ProductPageDto(
    val items: List<ProductDto>,
    val page: Int,
    val pageSize: Int,
    val hasNextPage: Boolean
)

data class ProductPageDto(
    val items: List<ProductDto>,
    val page: Int,
    val pageSize: Int,
    val hasNextPage: Boolean
)

اگر از Paging 3 استفاده کنیم، برنامه فقط صفحه‌های موردنیاز رو دریافت می‌کنه:

class TrackedProductPagingSource(
    private val api: ProductApi
) : PagingSource<Int, Product>() {

    override suspend fun load(
        params: LoadParams<Int>
    ): LoadResult<Int, Product> {
        val page = params.key ?: 1

        return try {
            val response = api.getTrackedProducts(
                page = page,
                pageSize = params.loadSize
            )

            LoadResult.Page(
                data = response.items.map {
                    it.toDomain()
                },
                prevKey = if (page == 1) {
                    null
                } else {
                    page - 1
                },
                nextKey = if (response.hasNextPage) {
                    page + 1
                } else {
                    null
                }
            )
        } catch (exception: Exception) {
            LoadResult.Error(exception)
        }
    }

    override fun getRefreshKey(
        state: PagingState<Int, Product>
    ): Int? {
        val anchorPosition =
            state.anchorPosition ?: return null

        val anchorPage =
            state.closestPageToPosition(
                anchorPosition
            )

        return anchorPage?.prevKey?.plus(1)
            ?: anchorPage?.nextKey?.minus(1)
    }
}

class TrackedProductPagingSource(
    private val api: ProductApi
) : PagingSource<Int, Product>() {

    override suspend fun load(
        params: LoadParams<Int>
    ): LoadResult<Int, Product> {
        val page = params.key ?: 1

        return try {
            val response = api.getTrackedProducts(
                page = page,
                pageSize = params.loadSize
            )

            LoadResult.Page(
                data = response.items.map {
                    it.toDomain()
                },
                prevKey = if (page == 1) {
                    null
                } else {
                    page - 1
                },
                nextKey = if (response.hasNextPage) {
                    page + 1
                } else {
                    null
                }
            )
        } catch (exception: Exception) {
            LoadResult.Error(exception)
        }
    }

    override fun getRefreshKey(
        state: PagingState<Int, Product>
    ): Int? {
        val anchorPosition =
            state.anchorPosition ?: return null

        val anchorPage =
            state.closestPageToPosition(
                anchorPosition
            )

        return anchorPage?.prevKey?.plus(1)
            ?: anchorPage?.nextKey?.minus(1)
    }
}

در Repository یک Pager می‌سازیم:

class ProductRepository(
    private val api: ProductApi
) {

    fun getTrackedProducts():
        Flow<PagingData<Product>> {

        return Pager(
            config = PagingConfig(
                pageSize = 30,
                prefetchDistance = 5,
                enablePlaceholders = false
            ),
            pagingSourceFactory = {
                TrackedProductPagingSource(api)
            }
        ).flow
    }
}

class ProductRepository(
    private val api: ProductApi
) {

    fun getTrackedProducts():
        Flow<PagingData<Product>> {

        return Pager(
            config = PagingConfig(
                pageSize = 30,
                prefetchDistance = 5,
                enablePlaceholders = false
            ),
            pagingSourceFactory = {
                TrackedProductPagingSource(api)
            }
        ).flow
    }
}

و در ViewModel جریان داده رو Cache می‌کنیم:

class ProductListViewModel(
    repository: ProductRepository
) : ViewModel() {

    val products =
        repository
            .getTrackedProducts()
            .cachedIn(viewModelScope)
}

class ProductListViewModel(
    repository: ProductRepository
) : ViewModel() {

    val products =
        repository
            .getTrackedProducts()
            .cachedIn(viewModelScope)
}

این معماری هم مصرف حافظه اپلیکیشن رو کاهش میده و هم فشار واردشده به API و دیتابیس رو کنترل می‌کنه. البته Pagination فقط زمانی مؤثره که Backend هم Query درست داشته باشه. اگر سرور برای برگرداندن سی محصول، ابتدا تمام پنج هزار رکورد رو بخونه و بعد سی مورد رو جدا کنه، فقط پاسخ شبکه کوچک شده و فشار دیتابیس همچنان باقی مونده.

یک درخواست برای چند محصول، نه یک درخواست برای هر محصول

یکی از اشتباه‌های رایج در اپلیکیشن‌های قیمت و فروشگاه اینه که برای هر آیتم یک API جداگانه فراخوانی بشه:

products.forEach { product ->
    repository.getLatestPrice(product.id)
}

products.forEach { product ->
    repository.getLatestPrice(product.id)
}

اگر کاربر پنجاه محصول داشته باشه، این حلقه پنجاه درخواست شبکه تولید می‌کنه. در مقیاس هزار کاربر، همین صفحه می‌تونه پنجاه هزار درخواست ایجاد کنه. راه بهتر طراحی Endpoint گروهیه:

POST /products/latest-prices

بدنه درخواست:

{
  "productIds": [101, 102, 103, 104, 105]
}

{
  "productIds": [101, 102, 103, 104, 105]
}

پاسخ:

{
  "prices": [
    {
      "productId": 101,
      "price": 42500000
    },
    {
      "productId": 102,
      "price": 18600000
    }
  ]
}

{
  "prices": [
    {
      "productId": 101,
      "price": 42500000
    },
    {
      "productId": 102,
      "price": 18600000
    }
  ]
}

در Retrofit:

data class LatestPriceRequest(
    val productIds: List<Long>
)

data class LatestPriceRequest(
    val productIds: List<Long>
)

interface PriceApi {

    @POST("products/latest-prices")
    suspend fun getLatestPrices(
        @Body request: LatestPriceRequest
    ): List<LatestPriceDto>
}

interface PriceApi {

    @POST("products/latest-prices")
    suspend fun getLatestPrices(
        @Body request: LatestPriceRequest
    ): List<LatestPriceDto>
}