بهینه سازی مصرف باتری و شبکه در اندروید: راهنمای پروفایلینگ

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

سیستم عامل اندروید در نسخه های اخیر با معرفی مکانیزم های سخت گیرانه انرژی نظیر Doze Mode و App Standby Buckets، محدودیت های شدیدی برای پردازش های پس زمینه وضع کرده است. برنامه هایی با مصرف غیر اصولی جریمه می شوند.

در الگوریتم های رتبه بندی گوگل پلی، شاخص های عملکردی موسوم به Android Vitals به دقت نرخ بیداری های مکرر (Excessive Wakeups) و مصرف اینترنت در پس زمینه را تحلیل می کنند و رتبه اپ های پرمصرف را تنزل می دهند.

۱. ماشین وضعیت امواج رادیویی (Radio State Machine) و هزینه پنهان شبکه

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

این سه وضعیت شامل حالت فعال (Full Power)، حالت نیمه فعال با توان پایین (Low Power) و حالت آماده به کار (Standby) هستند. هنگامی که برنامه حتی یک بایت داده ارسال می کند، مودم بلافاصله به وضعیت توان کامل می رود.

پس از پایان ارسال داده، مودم فوراً خاموش نمی شود؛ بلکه به مدت ۱۰ تا ۳۰ ثانیه در وضعیت پرمصرف باقی می ماند تا از تاخیر اتصال مجدد جلوگیری کند. ارسال های مکرر و پراکنده بزرگ ترین عامل تخلیه باتری هستند.

اگر در آغاز مسیر توسعه نرم افزار اندروید هستید، برای تسلط بر الگو های مدرن معماری، راهنمای آموزش برنامه نویسی اندروید به عنوان نقشه راه اصلی به شما پیشنهاد می شود.

۲. کالبدشکافی سیستم های صرفه جویی انرژی: Doze Mode و App Standby

شرکت گوگل از اندروید ۶ مکانیزم دوز مود (Doze Mode) را معرفی کرد. زمانی که تلفن همراه بدون اتصال به شارژر و بدون حرکت روی سطحی ثابت قرار می گیرد، سیستم عامل وارد حالت خواب عمیق می شود.

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

علاوه بر دوز مود، سیستم سبد های آماده به کار (App Standby Buckets) برنامه ها را بر اساس میزان استفاده کاربر در ۴ گروه دسته بندی می کند: فعال (Active)، کاری (Working Set)، مکرر (Frequent) و نادر (Rare).

۳. تجمیع پردازش ها و زمان بندی هوشمند با WorkManager

برای اجرای وظایف پس زمینه بدون تخلیه باتری کاربر، به هیچ عنوان نباید از سرویس های قدیمی نظیر Service معمولی یا AlarmManager های مکرر استفاده کرد. راهکار استاندارد و پیشنهادی گوگل بهره گیری از WorkManager است.

ورک منیجر این امکان را فراهم می سازد تا با تعیین شروط هوشمند (Constraints)، اجرای کارها را به زمان اتصال به وای فای، اتصال به شارژر یا آزاد بودن پردازنده موکول کنید:

val networkConstraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.UNMETERED) // صرفاً وای فای نامحدود
    .setRequiresCharging(true) // صرفاً در زمان اتصال به شارژر
    .setRequiresBatteryNotLow(true) // جلوگیری از اجرا در باتری ضعیف
    .build()

val syncWorkRequest = OneTimeWorkRequestBuilder()
    .setConstraints(networkConstraints)
    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 15, TimeUnit.MINUTES)
    .build()

WorkManager.getInstance(context).enqueueUniqueWork(
    "unique_sync_task",
    ExistingWorkPolicy.KEEP,
    syncWorkRequest
)

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

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

پیشنهاد مطالعه

آموزش ورک منیجر WorkManager در اندروید: اجرای تسک پس زمینه

راهنمای جامع آموزش ورک منیجر WorkManager در اندروید؛ مدیریت تسک های پایدار پس زمینه، پیاده سازی CoroutineWorker، محدودیت های هوشمند باتری و شبکه و مق…

مشاهده مقاله ←

۴. پروفایلینگ مصرف انرژی با Android Studio Energy Profiler

محیط اندروید استودیو مجهز به ابزار پیشرفته ای به نام Energy Profiler است. این ابزار مصرف تخمینی انرژی برنامه را به تفکیک سه مولفه سخت افزاری کلیدی یعنی پردازنده (CPU)، شبکه (Network) و مکان یابی (Location) نمایش می دهد.

هنگام اجرای برنامه روی دستگاه واقعی، نوار رنگی Energy Profiler میزان مصرف را در سه رده سبک (Light)، متوسط (Medium) و سنگین (Heavy) مصورسازی می کند:

• سطح سبک (سبز): پردازش های عادی یو آی و فعالیت های استاندارد بدون فعال سازی مدام رادیو.
• سطح متوسط (زرد): دانلود مداوم فایل های سبک یا رندرینگ انیمیشن های متوالی.
• سطح سنگین (قرمز): فعال ماندن طولانی سنسور GPS، پخش مداوم ویدیو و ایجاد مکرر ارتباطات سوکت.

// ثبت رویداد های سفارشی در پنجره پروفایلر برای سنجش زمان مصرف
Trace.beginSection("HeavyImageProcessingTask")
try {{
    processBitmapFilters(bitmap)
}} finally {{
    Trace.endSection()
}}

استفاده از کلاس Trace به مهندسان کمک می کند تا بخش های پرمصرف الگوریتم های برنامه را دقیقاً در لاگ پروفایلر ردیابی کنند.

۵. تحلیل داده های تخلیه باتری با ابزار رسمی Battery Historian

ابزار Battery Historian نرم افزار تحلیلی قدرتمند شرکت گوگل است که فایل گزارش های خطای سیستم عامل (Bugreport) را به یک داشبورد تعاملی HTML تبدیل می کند. این ابزار ریشه تمامی بیداری های ناخواسته را آشکار می سازد.

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

# آماده سازی شمارنده های باتری و ریست آمار های قبلی
adb shell dumpsys batterystats --reset

# اجرای سناریوی تست توسط کاربر یا اسکریپت خودکار...

# استخراج گزارش کامل به صورت فایل فشرده
adb bugreport bugreport_energy.zip

با بارگذاری فایل زیپ در داشبورد Battery Historian، می توان خط زمانی WakeLock ها، مدت زمان فعال بودن امواج رادیویی و درصد افت شارژ به ازای هر ساعت را تحلیل کرد.

۶. بهینه سازی لایه شبکه با رتروفیت و تنظیمات پیشرفته OkHttp

لایه ارتباط با وب سرویس یکی از بخش های اصلی مصرف ترافیک اینترنت و انرژی است. با پیاده سازی سیاست های کش هوشمند و فشرده سازی دیتا، می توان حجم تبادلات را تا ۷۵ درصد کاهش داد.

فعال سازی فشرده سازی Gzip و Brotli

کلاینت OkHttp به صورت پیش فرض از هدر Accept-Encoding: gzip پشتیبانی می کند. مطمئن شوید سرور هایی شما نیز پاسخ ها را به صورت فشرده ارسال می کنند تا حجم داده های متنی JSON به حداقل برسد.

پیاده سازی کش محلی مبتنی بر هدر ETag

استفاده از مکانیسم اعتبار سنجی ETag از دانلود مجدد پاسخ هایی که در سرور تغییری نکرده اند جلوگیری می کند:

val cacheSize = 25L * 1024 * 1024 // تخصیص ۲۵ مگابایت کش دیسک
val httpCache = Cache(File(context.cacheDir, "http_cache"), cacheSize)

val okHttpClient = OkHttpClient.Builder()
    .cache(httpCache)
    .addNetworkInterceptor {{ chain ->
        val response = chain.proceed(chain.request())
        response.newBuilder()
            .header("Cache-Control", "public, max-age=3600") // نگه داری کش تا یک ساعت
            .build()
    }}
    .build()

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

۷. بهینه سازی مصرف سنسور های مکانی (Location Profiling)

سنسور GPS دقیق ترین و در عین حال پرمصرف ترین قطعه سخت افزاری دستگاه است. روشن نگه داشتن مداوم تراشه GPS می تواند باتری پرچمدار ترین گوشی ها را ظرف کمتر از ۳ ساعت به طور کامل تخلیه کند.

برای کنترل مصرف، استفاده از سرویس FusedLocationProviderClient و تنظیم هوشمند اولویت دقت الزامی است:

val balancedLocationRequest = LocationRequest.Builder(
    Priority.PRIORITY_BALANCED_POWER_ACCURACY, // دقت متعادل بر پایه وای فای و دکل
    TimeUnit.MINUTES.toMillis(5) // دریافت موقعیت هر ۵ دقیقه یک بار
).apply {{
    setMinUpdateIntervalMillis(TimeUnit.MINUTES.toMillis(2))
    setMaxUpdateDelayMillis(TimeUnit.MINUTES.toMillis(10)) // امکان تجمیع توسط سیستم
}}.build()

قابلیت setMaxUpdateDelayMillis به سیستم عامل اجازه می دهد رویدادهای مکانی چند برنامه را با هم تجمیع کرده و با یک بار روشن کردن سنسور به همه تحویل دهد.

۸. مدیریت لایف سایکل کوروتین ها و جلوگیری از نشت درخواست های شبکه

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

همواره باید از اسکوپ های متصل به چرخه حیات نظیر viewModelScope استفاده شود تا با نابودی ویومدل، درخواست های شبکه ای به شکل خودکار لغو (Cancel) شوند:

class WeatherViewModel(private val repository: WeatherRepository) : ViewModel() {
    fun loadForecast() {
        viewModelScope.launch {
            // با خروج کاربر از صفحه این کورتین بلافاصله متوقف می شود
            val result = repository.fetchForecastData()
            _uiState.value = result
        }
    }
}

برای تسلط بر نحوه لغو ساختار یافته وظایف همزمان و مدیریت خطاها در کاتلین، مقاله مرجع مدیریت همزمانی در کاتلین با کورتین ها را مطالعه نمایید.

۹. تاثیر تم تیره (Dark Mode) بر کاهش مصرف انرژی نمایشگرهای OLED

در نمایشگرهای با فناوری OLED و AMOLED، هر پیکسل به صورت مستقل نور تولید می کند. در این پنل ها، نمایش رنگ سیاه خالص (True Black با کد رنگی #000000) به معنای خاموش بودن کامل پیکسل است.

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

@Composable
fun AppTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit
) {{
    val colorScheme = if (darkTheme) {{
        DarkColorScheme.copy(background = Color.Black, surface = Color(0xFF121212))
    }} else {{
        LightColorScheme
    }}
    MaterialTheme(colorScheme = colorScheme, content = content)
}}

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

۱۰. پایش شاخص های Android Vitals و خطاهای Excessive Wakeups

کنسول گوگل پلی رفتار اپلیکیشن ها در دنیای واقعی را مانیتور می کند. اگر نرخ بیداری های مکرر برنامه شما از آستانه خطر (Bad Behavior Threshold) بالاتر برود، رتبه جستجوی برنامه در پلی استور افت می کند.

دو شاخص بحرانی در بخش Android Vitals شامل موارد زیر هستند:

• بیدار ماندن بیش از حد پردازنده (Excessive Wake Locks): نگه داشتن WakeLock به مدت بیش از ۱ ساعت در پس زمینه. آستانه مجاز گوگل کمتر از ۰.۷ درصد جلسات است.
• تکرار زیاد بیدارباش ها (Excessive Wakeups): بیدار کردن دستگاه با AlarmManager با نرخ بیش از ۶۰ بار در ساعت. آستانه مجاز کمتر از ۰.۱ درصد جلسات است.

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

پیشنهاد مطالعه

آموزش پروفایلینگ در اندروید: بهینه سازی مصرف رم و حل Memory Leak

پروفایلینگ حافظه و رفع نشت حافظه (Memory Leak) یکی از کلیدی ترین مهارت های مهندسان ارشد اندروید است. در این راهنمای جامع، معماری حافظه ART، ابزار های…

مشاهده مقاله ←

۱۱. بهینه سازی ساختار بیلد و فرآیندهای توسعه در گریدل

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

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

۱۲. بهینه سازی سریال سازی داده ها با Protocol Buffers و kotlinx.serialization

تجزیه و تحلیل متون سنگین JSON در رشته اصلی پردازنده، علاوه بر تاخیر در پاسخگویی رابط کاربری، مصرف باتری را افزایش می دهد. استفاده از کتابخانه های قدیمی نظیر Gson به دلیل استفاده از بازتاب (Reflection) سربار محاسباتی زیادی دارد.

مهاجرت به kotlinx.serialization به دلیل تولید کدهای بهینه در زمان کامپایل، سرعت تبدیل داده ها را تا ۳ برابر بهبود می بخشد:

@Serializable
data class UserTelemetry(
    val deviceId: String,
    val batteryLevel: Int,
    val timestamp: Long
)

// سریال سازی سریع بدون استفاده از رفلکشن
val jsonString = Json.encodeToString(UserTelemetry.serializer(), telemetry)

در سناریوهای با حجم دیتای بسیار بالا، جایگزینی کامل JSON با ساختار باینری Protocol Buffers (Protobuf) حجم تبادلات شبکه را تا ۶۰ درصد و زمان پردازش را تا ۵ برابر کاهش می دهد.

۱۳. مدیریت استخر اتصالات (Connection Pooling) در OkHttp

برقراری یک اتصال امن جدید با سرور از طریق پروتکل HTTPS نیازمند فرآیند چند مرحله ای دست دهی (TLS Handshake) و ارسال و دریافت چندین بسته متوالی در شبکه است. این فرآیند تاخیر و مصرف باتری بالایی ایجاد می کند.

کلاینت OkHttp از ساز و کاری به نام Connection Pool برای نگه داری سوکت های باز و استفاده مجدد از آنها برای درخواست های بعدی بهره می برد:

val connectionPool = ConnectionPool(
    maxIdleConnections = 5, // حداکثر ۵ سوکت بیکار باز
    keepAliveDuration = 5, // نگه داری سوکت به مدت ۵ دقیقه
    timeUnit = TimeUnit.MINUTES
)

val client = OkHttpClient.Builder()
    .connectionPool(connectionPool)
    .retryOnConnectionFailure(true)
    .build()

استفاده مجدد از اتصالات موجود مانع از رفتن بیهوده مودم رادیویی به حالت دست دهی مجدد می شود و زمان پاسخگویی درخواست ها را به زیر ۲۰۰ میلی ثانیه کاهش می دهد.

۱۴. پیاده سازی صفحه بندی هوشمند با Paging ۳ برای کاهش مصرف پهنای باند

یکی از بدترین الگو های طراحی در اپلیکیشن های موبایل، دریافت تمامی آیتم های یک لیست (مانند ۱۰۰۰ محصول یا مقاله) در اولین درخواست شبکه است. این کار حجم زیادی از اینترنت کاربر را مصرف کرده و بخش بزرگی از حافظه رم را اشغال می کند.

کتابخانه استاندارد Paging ۳ داده ها را به صورت تکه های کوچک (مثلاً ۲۰ آیتم در هر صفحه) و صرفاً هنگام نزدیک شدن کاربر به انتهای لیست بارگذاری می کند:

class ArticlePagingSource(private val api: ApiService) : PagingSource() {{
    override suspend fun load(params: LoadParams): LoadResult {{
        val page = params.key ?: 1
        return try {{
            val response = api.getArticles(page = page, pageSize = params.loadSize)
            LoadResult.Page(
                data = response.items,
                prevKey = if (page == 1) null else page - 1,
                nextKey = if (response.items.isEmpty()) null else page + 1
            )
        }} catch (e: Exception) {{
            LoadResult.Error(e)
        }}
    }}
    override fun getRefreshKey(state: PagingState): Int? = null
}}

این استراتژی مصرف ترافیک برنامه را تا ۹۰ درصد کاهش می دهد و کاربرانی که صرفاً چند آیتم اول را مشاهده می کنند، هزینه ای بابت دیتای کل کاتالوگ متحمل نمی شوند.

۱۵. مانیتورینگ هوشمند شبکه با NetworkCallback در کاتلین

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

با ثبت یک شنونده در ConnectivityManager، می توان نوع اتصال را تشخیص داد و در صورت استفاده از دیتای سیم کارت، دانلود های پس زمینه را به حالت تعلیق درآورد:

val connectivityManager = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

val networkCallback = object : ConnectivityManager.NetworkCallback() {{
    override fun onCapabilitiesChanged(network: Network, capabilities: NetworkCapabilities) {{
        val isWifi = capabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI)
        val isMetered = !capabilities.hasCapability(NetworkCapabilities.NET_CAPABILITY_NOT_METERED)
        
        if (isMetered) {{
            // کاهش کیفیت پیش نمایش تصاویر در شبکه های حجمی
            ImageLoaderConfig.enableDataSaverMode()
        }}
    }}
}}

val request = NetworkRequest.Builder()
    .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    .build()

connectivityManager.registerNetworkCallback(request, networkCallback)

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

۱۶. انطباق رفتار برنامه با شارژ باقی مانده از طریق BatteryManager

زمانی که شارژ باتری کاربر به زیر ۱۵ درصد می رسد، اولویت اول دستگاه زنده ماندن تا اتصال به شارژر است. اپلیکیشن شما نباید در این شرایط با اجرای انیمیشن های سنگین یا دانلود ویدیو موجب خاموشی ناگهانی گوشی شود.

با دریافت وضعیت از سیستم با کلاس BatteryManager، می توان فعالیت های غیرضروری را موقتاً غیرفعال کرد:

val batteryStatus: Intent? = IntentFilter(Intent.ACTION_BATTERY_CHANGED).let {{ filter ->
    context.registerReceiver(null, filter)
}}

val level: Int = batteryStatus?.getIntExtra(BatteryManager.EXTRA_LEVEL, -1) ?: -1
val scale: Int = batteryStatus?.getIntExtra(BatteryManager.EXTRA_SCALE, -1) ?: -1
val batteryPct: Float = level * 100 / scale.toFloat()

if (batteryPct 

این استراتژی های دفاعی موجب می شود که برنامه شما در ارزیابی های میدانی کاربران به عنوان یک نرم افزار سبک، محافظ باتری و باکیفیت شناخته شود.

۱۷. بهینه سازی مصرف باتری در کدهای Jetpack Compose

رندرینگ مداوم و بازترسیم های غیرضروری (Unnecessary Recomposition) در کامپوز موجب کارکرد مداوم پردازنده گرافیکی (GPU) و هسته های CPU می شود که یکی از ریشه های اصلی گرم شدن گوشی و افت شارژ است.

با بهره گیری از ابزار های هوشمندی نظیر derivedStateOf، ارسال لامبدا ها به جای مقادیر متغیر و استفاده از مودیفایرهای فاز Draw، می توان محاسبات اضافی را فیلتر کرد:

// فیلتر کردن تغییرات سریع اسکرول و جلوگیری از ریکامپوزیشن مداوم
val showScrollToTopButton by remember {{
    derivedStateOf {{ listState.firstVisibleItemIndex > 5 }}
}}

// استفاده از فاز Draw به جای فاز Recomposition برای تغییر رنگ پس زمینه
Modifier.drawBehind {{
    drawRect(animatedBackgroundColor)
}}

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

۱۸. معماری کش آفلاین داده ها با پایگاه داده محلی Room

اتکا به اینترنت برای هر بار باز شدن صفحات، بزرگ ترین خطای مهندسی در اپلیکیشن های تجاری است. طبق الگوی منبع واحد حقیقت (Single Source of Truth)، داده ها ابتدا باید در دیتابیس محلی ذخیره شده و UI مستقیماً از حافظه داخلی تغذیه شود.

با بهره گیری از کتابخانه Room و جریان های واکنشی Flow، کاربر بلافاصله به اطلاعات دسترسی پیدا می کند و ارتباطات رادیویی سلولار صرفاً برای آپدیت های جدید فعال می شوند:

@Dao
interface ProductDao {{
    @Query("SELECT * FROM products ORDER BY id DESC")
    fun getAllProductsFlow(): Flow>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertAll(products: List)
}}

برای پیاده سازی لایه های پایگاه داده محلی و الگو های کش آفلاین در کاتلین، راهنمای آموزش دیتابیس Room در اندروید را به عنوان مرجع مطالعه فرمایید.

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

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

۱۹. چک لیست طلایی مهندسی برای کاهش ۵۰ درصدی مصرف انرژی

پیش از انتشار نسخه نهایی اپلیکیشن در استورها، این چک لیست دفاعی را در کدهای خود ارزیابی کنید:

1. تجمیع لاگ های تحلیلی: لاگ های کاربری را بلافاصله ارسال نکنید؛ آنها را ذخیره کرده و به صورت بسته های ۵۰ تایی با WorkManager منتقل نمایید.
2. حذف WakeLock های دستی: به جای استفاده مستقیم از PowerManager.WakeLock، وظایف را به WorkManager با قید شارژر واگذار کنید.
3. فشرده سازی تصاویر قبل از آپلود: تصاویر ارسالی کاربر را با ابعاد متناسب کوچک کرده و به فرمت WebP تبدیل کنید تا زمان تبادل رادیویی کوتاه شود.
4. تنظیم تایم اوت کوتاه تر برای سوکت ها: مدت زمان Connect Timeout و Read Timeout در OkHttp را به جای مقادیر طولانی، روی ۱۵ ثانیه محدود نمایید.
5. بهره گیری از وب سوکت به جای Polling: برای دریافت دیتای زنده، از ارسال درخواست های متوالی هر ۱۰ ثانیه یک بار خودداری کرده و از سوکت یا اعلان Push استفاده کنید.
6. اجتناب از آپدیت های موقعیت مکانی مکرر: از سنسور GPS صرفاً در صفحات فعال نقشه استفاده کنید و در سایر بخش ها به مکان یابی شبکه ای اکتفا نمایید.
7. تست مداوم با ابزار Bugreport: پیش از هر ریلیز، خروجی داده های تخلیه باتری را در نرم افزار Battery Historian بررسی نمایید.

۲۰. پرسش های متداول پیرامون بهینه سازی باتری و شبکه در اندروید