ব্যাকগ্রাউন্ড প্রসেস মেমরি ও ব্যাটারি বেশি খরচ করতে পারে। যেমন, কোনও ইমপ্লিসিট ব্রডকাস্ট শুনতে রেজিস্টার করা অনেক ব্যাকগ্রাউন্ড প্রসেস শুরু করতে পারে, এমনকি সেই প্রসেসগুলি বেশি কাজ না করলেও। এটি ডিভাইসের পারফর্ম্যান্স ও ব্যবহারকারীর অভিজ্ঞতা, দুটির উপরেই উল্লেখযোগ্য প্রভাব ফেলতে পারে।
সিস্টেম সংক্রান্ত বিধিনিষেধ এড়াতে, ব্যাকগ্রাউন্ড টাস্কের জন্য সঠিক API ব্যবহার করছেন কিনা তা নিশ্চিত করুন। ব্যাকগ্রাউন্ড টাস্ক ওভারভিউ ডকুমেন্টেশন আপনাকে প্রয়োজন অনুযায়ী সঠিক API বেছে নিতে সাহায্য করে।
ব্যবহারকারীর দ্বারা শুরু করা বিধিনিষেধ
কোনও অ্যাপ যদি Android vitals-এ বর্ণিত কিছু খারাপ পারফর্ম্যান্স দেখায়, তাহলে সিস্টেম ব্যবহারকারীকে সিস্টেম রিসোর্সে সেই অ্যাপের অ্যাক্সেস সীমাবদ্ধ করতে প্রম্পট করে।
সিস্টেম যদি লক্ষ্য করে যে কোনও অ্যাপ অতিরিক্ত রিসোর্স ব্যবহার করছে, তাহলে এটি ব্যবহারকারীকে জানায় এবং ব্যবহারকারীকে অ্যাপের অ্যাকশন সীমাবদ্ধ করার বিকল্প দেয়। যেসব আচরণের জন্য বিজ্ঞপ্তি পাঠানো হতে পারে তার মধ্যে এগুলি অন্তর্ভুক্ত:
- অতিরিক্ত ওয়েক লক: স্ক্রিন বন্ধ থাকার সময় ১টি আংশিক ওয়েক লক এক ঘণ্টা ধরে রাখা হয়েছে
- অতিরিক্ত ব্যাকগ্রাউন্ড পরিষেবা: অ্যাপের টার্গেট API লেভেল ২৬-এর কম হলে এবং অতিরিক্ত ব্যাকগ্রাউন্ড পরিষেবা থাকলে
ডিভাইস প্রস্তুতকারক সুনির্দিষ্ট বিধিনিষেধ নির্ধারণ করেন। যেমন, AOSP বিল্ডে, সীমাবদ্ধ অ্যাপগুলি কাজ চালাতে, অ্যালার্ম ট্রিগার করতে বা নেটওয়ার্ক ব্যবহার করতে পারে না, তবে অ্যাপটি ফোরগ্রাউন্ডে থাকলে তা করতে পারে।
নেটওয়ার্ক অ্যাক্টিভিটি ব্রডকাস্ট পাওয়ার উপর বিধিনিষেধ
অ্যাপ যদি তার ম্যানিফেস্টে CONNECTIVITY_ACTION ব্রডকাস্ট পাওয়ার জন্য রেজিস্টার করে, তাহলে সেটি ব্রডকাস্ট পাবে না এবং এই ব্রডকাস্টের উপর নির্ভর করে যেসব প্রসেস চলে সেগুলি শুরু হবে না। এর ফলে, নেটওয়ার্ক পরিবর্তন সম্পর্কে জানতে চায় বা ডিভাইস আনমিটার্ড নেটওয়ার্কের সাথে কানেক্ট করলে,
বাল্ক নেটওয়ার্ক অ্যাক্টিভিটি পারফর্ম করতে চায় এমন অ্যাপের ক্ষেত্রে সমস্যা হতে
পারে। এই বিধিনিষেধ এড়িয়ে যাওয়ার জন্য Android ফ্রেমওয়ার্কে আগে থেকেই
অনেক সমাধান রয়েছে, তবে সঠিক সমাধান বেছে নেওয়া নির্ভর করে আপনার অ্যাপের মাধ্যমে আপনি
কী করতে চান তার উপর।
আনমিটার্ড কানেকশনে কাজ শিডিউল করুন
WorkRequest তৈরি করার সময়, NetworkType.UNMETERED Constraint যোগ করুন।
fun scheduleWork(context: Context) { val workManager = WorkManager.getInstance(context) val workRequest = OneTimeWorkRequestBuilder<MyWorker>() .setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .build() ) .build() workManager.enqueue(workRequest) }
আপনার কাজের শর্ত পূরণ হলে, নির্দিষ্ট Worker ক্লাসে doWork() পদ্ধতি রান করার জন্য
আপনার অ্যাপ একটি কলব্যাক পায়।
অ্যাপ চলাকালীন নেটওয়ার্ক কানেক্টিভিটি মনিটর করা
যেসব অ্যাপ চলছে সেগুলি এখনও রেজিস্টার করা BroadcastReceiver-এর মাধ্যমে CONNECTIVITY_CHANGE-এর জন্য শুনতে পারে। তবে, ConnectivityManager API
শুধুমাত্র নির্দিষ্ট নেটওয়ার্কের শর্ত পূরণ হলে কলব্যাক করার অনুরোধ করার জন্য আরও শক্তিশালী পদ্ধতি
প্রদান করে।
NetworkRequest অবজেক্ট NetworkCapabilities-এর
পরিভাষায় নেটওয়ার্ক কলব্যাকের প্যারামিটার নির্ধারণ করে। আপনি NetworkRequest.Builder ক্লাস ব্যবহার করে
NetworkRequest অবজেক্ট তৈরি করেন। registerNetworkCallback
তারপর সিস্টেমে NetworkRequest অবজেক্ট পাস করে। নেটওয়ার্কের শর্ত পূরণ হলে, অ্যাপটি তার
ConnectivityManager.NetworkCallback ক্লাসে সংজ্ঞায়িত
onAvailable() পদ্ধতিটি কার্যকর করার জন্য একটি কলব্যাক পায়।
অ্যাপটি বন্ধ না হওয়া পর্যন্ত বা unregisterNetworkCallback() কল না করা পর্যন্ত অ্যাপটি কলব্যাক পেতে থাকে।
ছবি ও ভিডিও ব্রডকাস্ট পাওয়ার ক্ষেত্রে বিধিনিষেধ
অ্যাপ ACTION_NEW_PICTURE বা ACTION_NEW_VIDEO ব্রডকাস্ট পাঠাতে বা গ্রহণ করতে পারছে না। নতুন ছবি বা ভিডিও প্রসেস করার জন্য একাধিক অ্যাপকে চালু করতে হলে, এই বিধিনিষেধ পারফর্ম্যান্স ও ব্যবহারকারীর অভিজ্ঞতার উপর প্রভাব হ্রাস করতে সাহায্য করে।
কোন কন্টেন্ট কর্তৃপক্ষ কাজ ট্রিগার করেছে তা নির্ধারণ করুন
WorkerParameters আপনার অ্যাপকে কোন কন্টেন্ট অথরিটি এবং URI কাজ ট্রিগার করেছে সেই সম্পর্কে
প্রয়োজনীয় তথ্য পাওয়ার অনুমতি দেয়:
List<Uri> getTriggeredContentUris()
কাজ ট্রিগার করেছে এমন URI-এর তালিকা দেখায়। এটি খালি থাকে যদি কোনও URI কাজ ট্রিগার না করে (যেমন, কোনও সময়সীমা বা অন্য কোনও কারণে কাজ ট্রিগার করা হয়েছে) অথবা পরিবর্তিত URI-এর সংখ্যা ৫০-এর বেশি হয়।
List<String> getTriggeredContentAuthorities()
কাজটি ট্রিগার করেছে এমন কন্টেন্ট অথরিটির স্ট্রিং তালিকা দেখায়। ফেরত আসা
তালিকা খালি না থাকলে, কোন URI পরিবর্তন হয়েছে তার বিবরণ
জানতে getTriggeredContentUris() ব্যবহার করুন।
নিম্নলিখিত স্যাম্পেল কোড CoroutineWorker.doWork() পদ্ধতি ওভাররাইড করে
এবং কন্টেন্ট অথরিটি ও URI রেকর্ড করে যা জব ট্রিগার করেছে:
class MyWorker( appContext: Context, private val params: WorkerParameters ) : CoroutineWorker(appContext, params) { override suspend fun doWork(): Result { StringBuilder().apply { append("Media content has changed:\n") params.triggeredContentAuthorities .takeIf { it.isNotEmpty() } ?.let { authorities -> append("Authorities: ${authorities.joinToString(", ")}\n") append(params.triggeredContentUris.joinToString("\n")) } ?: append("(No content)") Log.i(TAG, toString()) } return Result.success() } }
সিস্টেমের বিধিনিষেধের অধীনে অ্যাপ পরীক্ষা করুন
কম মেমরি আছে এমন ডিভাইসে বা কম মেমরির পরিস্থিতিতে আপনার অ্যাপ অপ্টিমাইজ করলে, পারফর্ম্যান্স ও ব্যবহারকারীর অভিজ্ঞতা উন্নত হতে পারে। ব্যাকগ্রাউন্ড পরিষেবা এবং ম্যানিফেস্ট-রেজিস্টার করা ইমপ্লিসিট ব্রডকাস্ট রিসিভারের উপর নির্ভরতা সরিয়ে দিলে, এই ধরনের ডিভাইসে আপনার অ্যাপ আরও ভালোভাবে রান করতে পারে। এইসব ব্যাকগ্রাউন্ড প্রসেস সম্পূর্ণভাবে ব্যবহার না করে আপনার অ্যাপ যাতে চলে তার জন্য অপ্টিমাইজ করার সাজেশন দেওয়া হয়।
কিছু অতিরিক্ত Android ডিবাগ ব্রিজ (ADB) কমান্ড আপনাকে ব্যাকগ্রাউন্ড প্রসেস বন্ধ করে অ্যাপের আচরণ পরীক্ষা করতে সাহায্য করতে পারে:
ইমপ্লিসিট ব্রডকাস্ট এবং ব্যাকগ্রাউন্ড পরিষেবা উপলভ্য নয় এমন পরিস্থিতি সিমুলেট করতে, নিম্নলিখিত কমান্ড লিখুন:
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignoreইমপ্লিসিট ব্রডকাস্ট ও ব্যাকগ্রাউন্ড পরিষেবা আবার চালু করতে, নিম্নলিখিত কমান্ড লিখুন:
$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow
আপনার অ্যাপ আরও অপ্টিমাইজ করুন
আপনার ব্যাকগ্রাউন্ড টাস্কের আচরণ অপ্টিমাইজ করার অন্যান্য ভালো উপায়ের জন্য, টাস্ক শিডিউলিং API-এর জন্য ব্যাটারির ব্যবহার অপ্টিমাইজ করুন ডকুমেন্টেশন দেখুন।