استفاده از رادیو بی‌سیم برای انتقال داده‌ها به‌طور بالقوه یکی از مهم‌ترین منابع تخلیه باتری برنامه شما است. برای به‌حداقل رساندن تخلیه باتری مرتبط با فعالیت شبکه، بسیار مهم است که بدانید مدل اتصال شما چگونه بر سخت‌افزار رادیویی زیربنایی تأثیر می‌گذارد.
این بخش ماشین حالت رادیویی بی‌سیم را معرفی می‌کند و توضیح می‌دهد که مدل اتصال‌پذیری برنامه‌تان چگونه با آن تعامل می‌کند. سپس چندین تکنیک ارائه می‌دهد که درصورت دنبال کردن آن‌ها، به حداقل رساندن تأثیر مصرف داده برنامه‌تان بر باتری کمک می‌کند.
ماشین حالت رادیو
رادیو بی‌سیم در دستگاه کاربرتان ویژگی‌های داخلی صرفه‌جویی در مصرف باتری دارد که کمک می‌کند میزان مصرف باتری به حداقل برسد. وقتی رادیو بی‌سیم کاملاً فعال باشد، برق زیادی مصرف می‌کند، اما وقتی غیرفعال یا در حالت آماده‌به‌کار باشد، برق بسیار کمی مصرف می‌کند.
یک عامل مهم که باید به‌خاطر داشته باشید این است که رادیو نمی‌تواند فوراً از حالت آماده‌به‌کار به حالت کاملاً فعال تغییر کند. یک دوره تأخیر مرتبط با «روشن کردن» رادیو وجود دارد. بنابراین باتری به‌آرامی از حالت‌های انرژی بالاتر به حالت‌های انرژی پایین‌تر می‌رود تا در زمانی که از آن استفاده نمی‌شود، انرژی را حفظ کند و درعین‌حال تلاش می‌کند تأخیر مربوط به «روشن کردن» رادیو را به حداقل برساند.
ماشین حالت برای رادیو شبکه 3G معمولی از سه حالت انرژی تشکیل شده است:
- قدرت کامل: زمانی استفاده می‌شود که اتصال فعال باشد و به دستگاه اجازه می‌دهد داده‌ها را با بالاترین نرخ ممکن منتقل کند.
- کم‌مصرف: حالتی میانی که مصرف شارژ باتری را حدود ۵۰٪ کاهش می‌دهد.
- آماده‌به‌کار: حالت حداقل مصرف برق که در آن هیچ اتصال شبکه‌ای فعال نیست.
درحالی‌که حالت‌های کم و آماده‌به‌کار به‌طور قابل‌توجهی باتری کمتری مصرف می‌کنند، تأخیر قابل‌توجهی نیز در درخواست‌های شبکه ایجاد می‌کنند. بازگشت به حالت توان کامل از حالت توان کم حدود ۱٫۵ ثانیه طول می‌کشد و رفتن از حالت آماده‌به‌کار به حالت توان کامل می‌تواند بیش‌از ۲ ثانیه طول بکشد.
برای به‌حداقل رساندن تأخیر، ماشین حالت از تأخیر برای به‌تعویق انداختن انتقال به حالت‌های انرژی پایین‌تر استفاده می‌کند. شکل ۱ از زمان‌بندی‌های AT&T برای یک رادیو 3G معمولی استفاده می‌کند.
شکل ۱. ماشین حالت رادیویی بی‌سیم 3G معمولی.
ماشین حالت رادیویی در هر دستگاه، به‌ویژه تأخیر انتقال مرتبط («زمان دنباله») و تأخیر راه‌اندازی، براساس فناوری رادیویی بی‌سیم به‌کاررفته (3G، LTE، 5G، و غیره) متفاوت خواهد بود و توسط شبکه شرکت مخابراتی که دستگاه در آن کار می‌کند تعریف و پیکربندی می‌شود.
این صفحه یک ماشین حالت نماینده را برای یک رادیو بی‌سیم 3G معمولی، براساس داده‌های ارائه شده توسط AT&T، توصیف می‌کند. بااین‌حال، اصول کلی و روال‌های مطلوب حاصل از آن برای همه پیاده‌سازی‌های رادیویی بی‌سیم قابل‌اجرا است.
این رویکرد به‌ویژه برای مرور وب تلفن همراه معمولی مؤثر است زیرا از تأخیر ناخواسته هنگام مرور وب توسط کاربران جلوگیری می‌کند. زمان دنباله نسبتاً کم نیز تضمین می‌کند که پس‌از پایان جلسه مرور، رادیو می‌تواند به حالت انرژی پایین‌تری منتقل شود.
متأسفانه این رویکرد می‌تواند به برنامه‌های ناکارآمد در سیستم‌عامل‌های تلفن هوشمند مدرن مانند Android منجر شود، جایی که برنامه‌ها هم در پیش‌زمینه (جایی که تأخیر مهم است) و هم در پس‌زمینه (جایی که عمر باتری باید در اولویت قرار گیرد) اجرا می‌شوند.
نحوه تأثیر برنامه‌ها بر ماشین حالت رادیو
هربار که اتصال شبکه جدیدی ایجاد می‌کنید، رادیو به حالت تمام‌توان منتقل می‌شود. در مورد ماشین حالت رادیویی معمولی 3G که قبلاً توضیح داده شد، برای مدت انتقال شما در حالت توان کامل باقی می‌ماند—به‌علاوه ۵ ثانیه زمان دنباله اضافی—و به‌دنبال آن ۱۲ ثانیه در حالت انرژی کم قرار می‌گیرد. بنابراین برای یک دستگاه 3G معمولی، هر جلسه انتقال داده باعث می‌شود که رادیو حداقل ۱۸ ثانیه انرژی مصرف کند.
در عمل، این بدان معناست که برنامه‌ای که انتقال داده یک ثانیه‌ای را انجام می‌دهد، سه بار در دقیقه، رادیو بی‌سیم را برای همیشه فعال نگه می‌دارد و آن را جابجا می‌کند درست زمانی که وارد حالت آماده به کار می‌شود، به قدرت بالا برگردید.
شکل ۲. مصرف نسبی برق رادیو بی‌سیم برای انتقال یک ثانیه‌ای که سه بار در هر دقیقه اجرا می‌شود. این رقم شامل تأخیر «روشن شدن» بین اجراها نمی‌شود.
درمقابل، اگر همان برنامه انتقال داده‌هایش را دسته‌بندی کند و هر دقیقه یک انتقال سه‌ثانیه‌ای انجام دهد، این کار باعث می‌شود رادیو در هر دقیقه فقط ۲۰ ثانیه در حالت پرمصرف بماند. این کار به رادیو اجازه می‌دهد تا در هر دقیقه ۴۰ ثانیه در حالت آماده‌به‌کار باشد، که منجر به کاهش قابل‌توجهی در مصرف باتری می‌شود.
شکل ۳. مصرف نسبی برق رادیویی بی‌سیم برای انتقال‌های سه ثانیه‌ای
که هر دقیقه یک‌بار اجرا می‌شود.
تکنیک‌های بهینه‌سازی
اکنون که متوجه شدید دسترسی به شبکه چگونه بر عمر باتری تأثیر می‌گذارد، بیایید درباره چند کاری صحبت کنیم که می‌توانید برای کمک به کاهش مصرف باتری انجام دهید و درعین‌حال تجربه کاربری سریع و روانی ارائه دهید.
انتقال داده‌های بسته‌ای
همان‌طور که در بخش قبلی گفته شد، دسته‌بندی انتقال داده‌ها به‌گونه‌ای که داده‌های بیشتری را در دفعات کمتری منتقل کنید، یکی از بهترین راه‌ها برای بهبود کارایی باتری است.
البته اگر برنامه‌تان نیاز داشته باشد که در پاسخ به کنش کاربر فوراً داده دریافت یا ارسال کند، همیشه نمی‌توان این کار را انجام داد. می‌توانید با پیش‌بینی و پیش‌واکشی داده‌ها این مشکل را کاهش دهید. سناریوهای دیگر، مانند ارسال گزارش‌ها یا تجزیه‌وتحلیل‌ها به سرور و سایر انتقال‌های داده غیرفوری که توسط برنامه آغاز شده‌اند، برای دسته‌بندی و بسته‌بندی بسیار مناسب هستند. برای دریافت نکاتی درباره زمان‌بندی انتقال‌های شبکه پس‌زمینه، به بهینه‌سازی تکالیف شروع‌شده توسط برنامه مراجعه کنید.
واکشی اولیه داده‌ها
پیش‌واکشی داده‌ها روش مؤثر دیگری برای کاهش تعداد جلسه‌های مستقل انتقال داده است که برنامه‌تان اجرا می‌کند. با واکشی پیشاپیش، وقتی کاربر کنشی را در برنامه‌تان انجام می‌دهد، برنامه پیش‌بینی می‌کند که کدام داده‌ها به احتمال زیاد برای مجموعه بعدی کنش‌های کاربر موردنیاز خواهد بود و آن داده‌ها را در یک انفجار واحد، ازطریق یک اتصال واحد، با ظرفیت کامل واکشی می‌کند.
با بارگذاری اولیه انتقال‌ها، تعداد فعال‌سازی‌های رادیویی موردنیاز برای بارگیری داده‌ها را کاهش می‌دهید. درنتیجه، نه‌تنها در مصرف باتری صرفه‌جویی می‌کنید، بلکه تأخیر را بهبود می‌بخشید، پهنای باند موردنیاز را کاهش می‌دهید، و زمان بارگیری را کاهش می‌دهید.
پیش‌واکشی همچنین با به‌حداقل رساندن تأخیر درون‌برنامه ناشی از انتظار برای تکمیل بارگیری‌ها قبل‌از انجام کنش یا مشاهده داده‌ها، تجربه کاربری را بهبود می‌بخشد.
در اینجا یک مثال کاربردی آورده شده است.
خبرخوان
بسیاری از برنامه‌های خبری تلاش می‌کنند تا با بارگیری عناوین فقط پس‌از انتخاب یک دسته، بارگیری مقالات کامل فقط زمانی که کاربر می‌خواهد آن‌ها را بخواند، و بارگیری ریزعکس‌ها درست زمانی که در دیدرس قرار می‌گیرند، پهنای باند را کاهش دهند.
بااستفاده از این رویکرد، رادیو مجبور است برای اکثر جلسه‌های خواندن اخبار کاربران فعال بماند، زیرا آن‌ها عناوین را پیمایش می‌کنند، دسته‌ها را تغییر می‌دهند، و مقاله‌ها را می‌خوانند. نه تنها این، بلکه جابه‌جایی مداوم بین حالت‌های انرژی منجر به تأخیر قابل‌توجهی هنگام جابه‌جایی دسته‌ها یا خواندن مقاله‌ها می‌شود.
رویکرد بهتر این است که مقدار معقولی از داده‌ها را در زمان راه‌اندازی پیش‌واکشی کنید، با اولین مجموعه از عناوین خبری و تصاویر کوچک شروع کنید—تضمین زمان راه‌اندازی با تأخیر کم—و با عناوین و تصاویر کوچک باقی‌مانده ادامه دهید، و همچنین متن مقاله برای هر مقاله موجود از حداقل فهرست عناوین اصلی.
یک جایگزین دیگر این است که هر عنوان، ریزعکس، متن مقاله، و احتمالاً حتی تصاویر کامل مقاله را پیش‌واکشی کنید—معمولاً در پس‌زمینه و طبق یک برنامه ازپیش تعیین‌شده. این رویکرد خطر مصرف پهنای باند و عمر باتری قابل‌توجهی را برای بارگیری محتوایی که هرگز استفاده نمی‌شود به‌همراه دارد، بنابراین باید با احتیاط اجرا شود.
سایر ملاحظات
درحالی‌که واکشی پیشاپیش داده‌ها مزایای زیادی دارد، استفاده بیش‌ازحد از آن خطر افزایش تخلیه باتری و مصرف پهنای باند و همچنین سهمیه بارگیری را با بارگیری داده‌هایی که استفاده نمی‌شوند به‌همراه دارد. همچنین مهم است که مطمئن شوید واکشی پیشاپیش باعث تأخیر در راه‌اندازی برنامه نمی‌شود، درحالی‌که برنامه منتظر تکمیل واکشی پیشاپیش است. در عمل، این ممکن است به‌معنای پردازش تدریجی داده‌ها یا شروع انتقال‌های متوالی با اولویت‌بندی باشد، به‌طوری‌که داده‌های موردنیاز برای راه‌اندازی برنامه ابتدا بارگیری و پردازش شوند.
اینکه چقدر تهاجمی داده‌ها را پیش‌واکشی می‌کنید به اندازه داده‌های درحال بارگیری و احتمال استفاده از آن‌ها بستگی دارد. به‌عنوان یک راهنمای کلی، براساس ماشین حالت که قبلاً توضیح داده شد، برای داده‌هایی که ۵۰٪ احتمال دارد در جلسه کاربر فعلی استفاده شوند، معمولاً می‌توانید حدود ۶ ثانیه (تقریباً ۱ تا ۲ مگابایت) پیش‌واکشی کنید، قبل از اینکه هزینه احتمالی بارگیری داده‌های استفاده‌نشده با صرفه‌جویی احتمالی ناشی از بارگیری نکردن آن داده‌ها مطابقت داشته باشد.
به‌طور کلی، پیش‌واکشی داده‌ها به نحوی که فقط هر ۲ تا ۵ دقیقه یک‌بار نیاز به شروع بارگیری دیگری داشته باشید و به ترتیب ۱ تا ۵ مگابایت باشد، روش خوبی است.
با پیروی از این اصل، بارگیری‌های بزرگ (مانند فایل‌های ویدیویی) باید در فواصل زمانی منظم (هر ۲ تا ۵ دقیقه) به‌صورت تکه‌تکه بارگیری شوند، به‌طوری‌که فقط داده‌های ویدیویی که احتمالاً در چند دقیقه آینده مشاهده می‌شوند به‌طور مؤثر پیش‌واکشی شوند.
یک راه‌حل این است که بارگیری کامل را فقط برای زمانی‌که به Wi-Fi متصل هستید و احتمالاً فقط زمانی‌که دستگاه درحال شارژ است زمان‌بندی کنید. WorkManager API دقیقاً از این مورد استفاده پشتیبانی می‌کند و به شما امکان می‌دهد کار پس‌زمینه را محدود کنید تا زمانی که دستگاه معیارهای مشخص‌شده توسط توسعه‌دهنده را برآورده کند، مانند شارژ شدن و متصل بودن به Wi-Fi.
قبل‌از درخواست دادن، اتصال را بررسی کنید
جستجوی سیگنال تلفن همراه یکی از عملیات‌هایی است که بیشترین مصرف باتری را در دستگاه همراه دارد. روال مطلوب برای درخواست‌های آغازشده توسط کاربر این است که ابتدا اتصال را بااستفاده از
ConnectivityManager بررسی کنید، همان‌طور که در
نظارت بر وضعیت اتصال و اندازه‌گیری اتصال نشان داده شده است.
اگر شبکه‌ای وجود نداشته باشد، برنامه می‌تواند با اجبار نکردن رادیو تلفن همراه به جستجو، در مصرف باتری صرفه‌جویی کند. سپس می‌توان درخواست را زمان‌بندی کرد و پس‌از برقراری اتصال، آن را به‌صورت دسته‌ای با درخواست‌های دیگر اجرا کرد.
اتصال‌های استخر
راهبرد دیگری که می‌تواند علاوه‌بر دسته‌بندی و واکشی پیشاپیش کمک کند، ادغام اتصال‌های شبکه برنامه‌تان است.
به‌طور کلی، استفاده مجدد از اتصالات شبکه موجود کارآمدتر از ایجاد اتصالات جدید است. استفاده مجدد از اتصالات همچنین به شبکه اجازه می‌دهد تا به‌طور هوشمندانه‌تری به ازدحام و مشکلات مربوط به داده‌های شبکه واکنش نشان دهد.
HttpURLConnection و اکثر کارخواه‌های HTTP، مثل OkHttp، به‌طور پیش‌فرض تجمیع اتصال را فعال می‌کنند و از اتصال یکسان برای چندین درخواست استفاده می‌کنند.
خلاصه و پیش‌نگری
در این بخش، مطالب زیادی درباره رادیو بی‌سیم و برخی راهبردها یاد گرفتید که می‌توانید به‌طور گسترده برای ارائه تجربه کاربری سریع و پاسخگو و درعین‌حال کاهش مصرف باتری اعمال کنید.
در بخش بعدی، نگاهی دقیق به سه نوع متمایز از تعاملات شبکه که در اکثر برنامه‌ها رایج است خواهیم داشت. با درایورهای هریک از این انواع و همچنین تکنیک‌های مدرن و میاناهای برنامه‌سازی کاربردی برای مدیریت کارآمد این تعاملات آشنا خواهید شد.