Android 11 (API লেভেল 30) বা এর পরের যেকোনও ভার্সনে ক্যাশে করা অ্যাপ ফ্রিজার কাজ করে। এই ফিচারটি ক্যাশে করা প্রসেসের জন্য এক্সিকিউশন বন্ধ করে এবং ক্যাশে করা অবস্থায় কাজ করার চেষ্টা করতে পারে এমন খারাপ আচরণকারী অ্যাপের রিসোর্স ব্যবহার কমায়।
ক্যাশে করা অ্যাপ ফ্রিজার, অ্যাপগুলিকে CPU থেকে বন্ধ রেখে RAM-এ রাখে। Android যদি নির্ধারণ করে যে কোনও অ্যাপের কাজ করা উচিত নয়, তবে ভবিষ্যতে প্রয়োজন হতে পারে, তাহলে এটি অ্যাপ প্রসেস বন্ধ করার পরিবর্তে ফ্রিজ করে দেয়। এর ফলে অ্যাপের প্রয়োজন হলে কোল্ড স্টার্ট করতে হয় না।
Android, ক্যাশে করা অ্যাপের প্রসেসকে একটি ফ্রিজ করা cgroup-এ মাইগ্রেট করার মাধ্যমে সেগুলিকে ফ্রিজ করে। এর ফলে অ্যাক্টিভ ক্যাশে করা অ্যাপ থাকলে অ্যাক্টিভ ও আইডল সিপিইউ ব্যবহার কমে যায়। আপনি সিস্টেম কনফিগারেশন ফ্ল্যাগ বা ডেভেলপার বিকল্প ব্যবহার করে অ্যাপ ফ্রিজার চালু করতে পারবেন।
Android 14 (API লেভেল 34) ও তার পরের যেকোনও ভার্সনে, ক্যাশে করা অ্যাপ ফ্রিজার নিম্নলিখিত শক্তিশালী আচরণ অন্তর্ভুক্ত করে:
- ক্যাশেড স্টেটে প্রবেশ করার ১০ সেকেন্ড পরে ক্যাশেড স্টেটে থাকা অ্যাপ প্রসেস ফ্রিজ হয়ে যায়।
- লাইফসাইকেল ইভেন্ট চলাকালীন সিস্টেম সঙ্গে সঙ্গে কোনও ফ্রিজ করা অ্যাপ প্রসেস আনফ্রিজ করে দেয়। এইসব ইভেন্টের মধ্যে ইনটেন্ট পাওয়া, কোনও জব পরিষেবা শুরু করা অথবা ব্যবহারকারীর অ্যাক্টিভিটি আবার শুরু করা অন্তর্ভুক্ত।
ActivityManagerService সব অ্যাপ প্রসেস ম্যানেজ করে এবং অ্যাপ লাইফসাইকেল
সম্পর্কিত সিদ্ধান্ত নেয়। অ্যাপ প্রসেস ফ্রিজ করার জন্য CachedAppOptimizer দায়বদ্ধ।
কোনও অ্যাপ প্রসেস ফ্রিজ হয়ে গেলে, এর সব থ্রেড সাসপেন্ড হয়ে যায় এবং আনফ্রিজ না হওয়া পর্যন্ত
CPU-এর কাজ করতে পারে না। এর ফলে, অ্যাপটি গার্বেজ কালেকশন (GC) করতে পারে না এবং মেমরি ট্রিম ইভেন্টে সাড়া দিতে পারে না। আরও তথ্যের জন্য,
ComponentCallbacks2.onTrimMemory(int) দেখুন। এটি
অ্যাকোমোডেট করতে, Android 14 থেকে শুরু করে:
Activityইনস্ট্যান্স দেখা যায় এমন অ্যাপকেTRIM_MEMORY_UI_HIDDENসম্পর্কে বিজ্ঞপ্তি পাঠানো হয়, যখনই সেগুলি ব্যাকগ্রাউন্ডে চলে যায়। UI ছাড়া লাইফসাইকেলে থাকা অ্যাপ, যেমন ফোরগ্রাউন্ড সার্ভিস সহ অ্যাপTRIM_MEMORY_BACKGROUNDপেতে পারে। অন্যান্য ট্রিম ইভেন্ট ডেলিভার করা হয় না, কারণ অ্যাপগুলি সেইসব ইভেন্টের জন্য উপযুক্ত হলে, সেগুলি ফ্রিজ করা হবে বলে আশা করা হয়।- ক্যাশে করা অবস্থায় প্রবেশ করার কিছুক্ষণ পরে, সিস্টেম অ্যাপ রানটাইমকে সম্ভাব্য ফ্রিজ হওয়ার প্রস্তুতিতে GC পারফর্ম করার অনুরোধ করতে পারে।
- কোনও অ্যাপ প্রসেস ফ্রিজ করা হলে, অতিরিক্ত মেমরি কম্প্যাকশন ধাপ হতে পারে, যেমন ব্যাক-আপ স্টোরেজে ডার্টি পৃষ্ঠা লেখা এবং ZRAM-এ বেনামী পৃষ্ঠা অদল-বদল করা।
- কোনও নির্দিষ্ট অ্যাপের সব প্রসেস ফ্রিজ করা হলে, অ্যাপের দ্বারা রক্ষণাবেক্ষণ করা যেকোনও অ্যাক্টিভ TCP সকেট সিস্টেম বন্ধ করে দেয়। এটি সকেটের সার্ভার সাইডকে TCP কিপঅ্যালাইভ পিং পাঠানো থেকে আটকায় যা ডিভাইস মডেমকে জাগিয়ে তুলত।
ক্যাশে করা অ্যাপ প্রসেস আনফ্রিজ করা হয় যখন তাদের প্রসেস স্টেট ক্যাশে থেকে
আরও গুরুত্বপূর্ণ স্টেটে উন্নীত হয়। Android 14 ও এর পরের ভার্সনে আনফ্রিজ ইভেন্ট কমাতে, অ্যাপ ক্যাশে
স্টেটে থাকাকালীন সিস্টেম, কন্টেক্সট-রেজিস্টার্ড ব্রডকাস্টকে
কিউ করে। Context.registerReceiver কল করে কোনও অ্যাপ ডায়নামিক রেজিস্টার করলে,
কনটেক্সট-রেজিস্টার্ড ব্রডকাস্ট হল সেই রিসিভার। অ্যাপটি
আনফ্রোজেন হওয়ার পরেই সিস্টেম এই সারিবদ্ধ ব্রডকাস্ট ডেলিভার করে। এর
বিপরীতে, সিস্টেম ম্যানিফেস্টে-ঘোষিত ব্রডকাস্টকে সারিবদ্ধ করে না।
ম্যানিফেস্ট-ঘোষিত ব্রডকাস্ট হল রিসিভার যা <receiver> এলিমেন্ট ব্যবহার করে
AndroidManifest.xml-এ স্ট্যাটিক্যালি ঘোষণা করা হয়। ম্যানিফেস্টে ঘোষণা করা ব্রডকাস্ট ডেলিভার করার জন্য সিস্টেম অবিলম্বে
ক্যাশে করা অ্যাপ আনফ্রিজ করে।
সিস্টেমের স্বাস্থ্যের উপর প্রভাব
ক্যাশে করা অ্যাপ প্রসেসের সংখ্যা বেশি হলে Android সবচেয়ে কম সম্প্রতি ব্যবহৃত ক্যাশে করা অ্যাপ প্রসেস বন্ধ করে দেয়।MAX_CACHED_PROCESSES Android 14 বা তার পরবর্তী যেকোনও ভার্সন
চালানো যায় এমন ডিভাইসে, MAX_CACHED_PROCESSES উল্লেখযোগ্যভাবে বাড়ানো হয়েছে,
এর ফলে ডিভাইস RAM-এ অনেক বেশি ক্যাশে করা অ্যাপ প্রসেস বজায় রাখতে পারে।
RAM-এ আরও অ্যাপ ক্যাশে করে রাখলে কোল্ড স্টার্টের সংখ্যা ৩০% পর্যন্ত কমে যায়, ডিভাইসের মোট RAM-এর উপর ভিত্তি করে এই সংখ্যা আরও কমে। একই সাথে, ক্যাশে করা অ্যাপের CPU ব্যবহার কমানো হয়, যার ফলে ব্যাটারির চার্জ উল্লেখযোগ্যভাবে সাশ্রয় হয়।
ফ্রিজার সংক্রান্ত ছাড়
নির্দিষ্ট কিছু শর্তে, কোনও অ্যাপ প্রসেস ক্যাশেড স্টেটে প্রবেশ করতে পারে, কিন্তু আনফ্রিজেন অবস্থায় থাকতে পারে। এইসব ছাড় হল প্রয়োগ সংক্রান্ত বিবরণ এবং ভবিষ্যতে Android ভার্সনে পরিবর্তিত হতে পারে:
- ফাইল লক: কোনও ক্যাশে করা প্রসেস যদি এমন ফাইল লক হোল্ড করে যা অন্য নন-ক্যাশে করা প্রসেসকে ব্লক করে, তাহলে যে প্রসেস লক হোল্ড করে সেটি ফ্রিজ করা হয় না।
BIND_WAIVE_PRIORITYবাইন্ডিং:Context.BIND_WAIVE_PRIORITYব্যবহার করে তৈরি করা ইনকামিং বাইন্ডিং সহ অ্যাপ প্রসেস ক্যাশেড স্টেটে প্রবেশ করতে পারে, কিন্তু কানেক্ট করা সব ক্লায়েন্ট প্রসেস ক্যাশে না হওয়া পর্যন্ত আনফ্রিজ করা থাকে। এই ছাড় মাল্টি-প্রসেস অ্যাপকে সমর্থন করে, যেমন কাস্টম ট্যাব ব্যবহার করে এমন ওয়েব ব্রাউজার।
অ্যাপ ফ্রিজার প্রয়োগ করা
ক্যাশে করা অ্যাপ ফ্রিজার, কার্নেল cgroup v2 ফ্রিজার ব্যবহার করে। মানানসই কার্নেল সহ
শিপিং করা ডিভাইস এটি চালু করতে পারবে। ডেভেলপার বিকল্প ক্যাশে করা অ্যাপের জন্য
এক্সিকিউশন সাসপেন্ড করুন চালু করুন অথবা ডিভাইস কনফিগারেশন ফ্ল্যাগ
activity_manager_native_boot use_freezer থেকে true-এ সেট করুন। যেমন:
adb shell device_config put activity_manager_native_boot use_freezer true && adb rebootআপনি ফ্ল্যাগ use_freezer থেকে false সেট করলে বা ডেভেলপার বিকল্প বন্ধ করলে
ফ্রিজার বন্ধ হয়ে যায়। যেমন:
adb shell device_config put activity_manager_native_boot use_freezer false && adb rebootসফ্টওয়্যার রিলিজ বা আপডেটে ডিভাইস কনফিগারেশন পরিবর্তন করে আপনি এই সেটিং টগল করতে পারবেন।
MAX_CACHED_PROCESSES ওভাররাইড করতে, যেমন, পরীক্ষার জন্য ভ্যালু ১০২৪ হিসেবে সেট করতে:
adb shell device_config put activity_manager max_cached_processes 1024adb shell device_config set_sync_disabled_for_tests persistent
MAX_CACHED_PROCESSES ওভাররাইড আগের অবস্থায় ফিরিয়ে আনতে:
adb shell device_config delete activity_manager max_cached_processesadb shell device_config set_sync_disabled_for_tests none
Android 16 (API লেভেল 36) ও তার পরের যেকোনও ভার্সন থেকে শুরু করে, রিমোট প্রসেস কখন ফ্রিজ বা আনফ্রিজ করা হয় তা পর্যবেক্ষণ করার জন্য Android অফিসিয়াল
পাবলিক API প্রদান করে, যেমন
IBinder.FrozenStateChangeCallback ও
IBinder.addFrozenStateChangeCallback,
। যেসব অ্যাপের সাথে ইন্টার্যাক্ট করা কম্পোনেন্ট ক্যাশে হয়ে যেতে পারে, সেগুলি রিমোট প্রসেসের
ফ্রিজ হয়ে যাওয়া স্টেট ট্র্যাক করতে এইসব API ব্যবহার করতে পারে।
ডিভাইস ও কার্নেল সংক্রান্ত প্রয়োজনীয়তা
ক্যাশ করা অ্যাপ ফ্রিজারের জন্য কার্নেল cgroup v2 সহায়তা প্রয়োজন। এছাড়াও,
IBinder.FrozenStateChangeCallback
ফ্রিজ স্টেট পরিবর্তন সংক্রান্ত বিজ্ঞপ্তি পেতে হলে কার্নেল বাইন্ডার ড্রাইভার সাপোর্ট থাকতে হবে।
Android 14 (API লেভেল 34) ও তার পরবর্তী যেকোনও ভার্সন থেকে শুরু করে
Android কমন কার্নেল (ACK) ও জেনেরিক কার্নেল ইমেজে (GKI) এটি স্ট্যান্ডার্ড হিসেবে থাকে।
কোনও ডিভাইস এইসব ক্ষমতা সাপোর্ট করে কিনা তা আপনি স্ট্যান্ডার্ড
adb কমান্ড ব্যবহার করে যাচাই করতে পারবেন, যেমন:
ডিভাইসে ফ্রিজার চালু করা আছে কিনা তা চেক করুন (ব্যবহারকারী বা ডিবাগ বিল্ডের জন্য):
adb shell device_config get activity_manager_native_boot use_freezerঅথবা যাচাই করুন যে সিস্টেমের মাধ্যমে প্রসেস অ্যাক্টিভভাবে ফ্রিজ করা হচ্ছে:
adb shell dumpsys activity | grep -A 20 "Apps frozen:"cgroup v2 ফ্রিজার কন্ট্রোলার সাপোর্ট (যেকোনও ডিভাইসের জন্য) চেক করুন:
উপলভ্য cgroup v2 কন্ট্রোলারের মধ্যে
freezerতালিকাভুক্ত আছে কিনা তা যাচাই করুন:adb shell cat /sys/fs/cgroup/cgroup.controllersবিকল্প হিসেবে, রুটেড ডিভাইস বা userdebug বিল্ডে, cgroup v2 ফ্রিজার নোড চাইল্ড cgroup-এ মাউন্ট করা আছে কিনা তা যাচাই করুন:
adb root && adb shell ls /sys/fs/cgroup/uid_0/cgroup.freezeএই ফাইল থাকলে, কার্নেল cgroup v2 ফ্রিজার সাপোর্ট করে।
ফ্রিজ স্টেট পরিবর্তন সংক্রান্ত বিজ্ঞপ্তি (যেকোনও ডিভাইসের জন্য) কাজ করে কিনা তা চেক করুন:
Android 14 ও তার পরবর্তী যেকোনও ভার্সনে চলে এমন ডিভাইসে মানানসই Generic Kernel Image (GKI) বাইন্ডার ড্রাইভারের সাথে,
IBinder.addFrozenStateChangeCallbackকলব্যাক সঠিকভাবে রেজিস্টার করে। যদি আন্ডারলায়িং কার্নেল বাইন্ডার ড্রাইভার ফ্রিজ নোটিফিকেশন সাপোর্ট না করে, তাহলে মেথডটিUnsupportedOperationExceptionথ্রো করে।
কাস্টম ফিচার ম্যানেজ করা
ক্যাশে করা থাকলে অ্যাপ প্রসেস কোনও কাজ করবে বলে আশা করা হয় না, তবে কিছু অ্যাপে কাস্টম ফিচার থাকতে পারে যা ক্যাশে করা থাকাকালীন রান করবে বলে আশা করা হয় এমন প্রসেস দ্বারা সমর্থিত। এই ধরনের অ্যাপ চলছে এমন ডিভাইসে অ্যাপ ফ্রিজার চালু করা হলে, ক্যাশে করা প্রসেস ফ্রিজ হয়ে যায় এবং কাস্টম ফিচার কাজ করা বন্ধ করে দিতে পারে।
এর বিকল্প হিসেবে, প্রসেসকে কোনও কাজ করার আগে আপনি প্রসেস স্ট্যাটাসকে নন-ক্যাশড হিসেবে পরিবর্তন করতে পারেন। এই পরিবর্তনের ফলে অ্যাপ অ্যাক্টিভ থাকতে পারে। অ্যাক্টিভ স্ট্যাটাসের উদাহরণ এর মধ্যে রয়েছে কোনও বাউন্ড ফোরগ্রাউন্ড পরিষেবা বা ফোরগ্রাউন্ড স্ট্যাটাস।
সাধারণ ব্যর্থতার মোড
অ্যাপ প্রসেস ফ্রিজ হয়ে গেলে, অনুপযুক্ত ইন্টার-প্রসেস কমিউনিকেশন (IPC) বা টাস্ক শিডিউলিংয়ের কারণে অ্যাপ বন্ধ হয়ে যেতে পারে বা অপ্রত্যাশিত আচরণ করতে পারে।
ফ্রিজ করা প্রসেসে সিঙ্ক্রোনাস বাইন্ডার ট্রানজ্যাকশন
কোনও ক্লায়েন্ট অ্যাপ প্রসেস, ফ্রোজেন থাকা কোনও সার্ভার অ্যাপ
প্রসেসে সিঙ্ক্রোনাস বাইন্ডার ট্রানজ্যাকশন পাঠালে, সিস্টেম সঙ্গে সঙ্গে সার্ভার অ্যাপ
প্রসেস বন্ধ করে দেয়। এর ফলে, ফ্রোজেন সার্ভার থেকে উত্তর পাওয়ার জন্য অপেক্ষা করার সময় ক্লায়েন্ট থ্রেড
অনির্দিষ্টকালের জন্য ব্লক হয়ে যায় না। ক্লায়েন্ট থ্রেড তারপর
RemoteException পায় এবং যেকোনও রেজিস্টার করা লিসেনার
ট্রিগার হয়। আরও তথ্যের জন্য, IBinder.linkToDeath দেখুন।
মূল কারণ: এই সমস্যাটি সাধারণত ক্লায়েন্ট অ্যাপে কোনও বাগ থাকার কারণে ঘটে।
কোনও ক্লায়েন্ট কোনও পরিষেবার সাথে কানেক্ট করলে, সার্ভার প্রসেস ক্লায়েন্টের সাথে কানেক্ট হয়ে যায় এবং
ক্লায়েন্ট কানেক্ট হওয়ার আগে ক্যাশেড স্টেটে প্রবেশ করতে পারে না। আরও
তথ্যের জন্য, Context.bindService দেখুন। তবে, ক্লায়েন্ট কল করলে Context.unbindService, সার্ভার প্রসেস
ক্যাশে ও ফ্রিজ হয়ে যেতে পারে। আনবাইন্ড করার পরেও ক্লায়েন্ট যদি ক্যাশে করা
IBinder রেফারেন্স ব্যবহার করা চালিয়ে যায়, তাহলে এটি ফ্রোজেন প্রসেসের
সাথে কমিউনিকেট করার ঝুঁকি নেয়।
এই সমস্যা এড়াতে, নিশ্চিত করুন যে ক্লায়েন্ট অ্যাপ IBinder
কল করার সাথে সাথেই রেফারেন্স
Context.unbindService বাতিল করে দেয়।
ক্লায়েন্ট প্রসেসে রিমোট কলব্যাক ম্যানেজ করা
যেসব পরিষেবা ও সিস্টেম কম্পোনেন্ট ক্লায়েন্ট প্রসেসে দীর্ঘমেয়াদী বাইন্ডার কলব্যাক বজায় রাখে, সেগুলি ক্লায়েন্ট ফ্রিজ হয়ে যাওয়া অবস্থা ট্র্যাক করার মাধ্যমে সিঙ্ক্রোনাস ব্যর্থতা ও অ্যাসিঙ্ক্রোনাস বাফার ওভারফ্লো আটকাতে পারে:
- স্টেট পরিবর্তন লিসেনার রেজিস্টার করুন: ক্লায়েন্ট প্রসেস ফ্রিজারে প্রবেশ করলে বা সেখান থেকে বেরিয়ে এলে বিজ্ঞপ্তি পেতে, ইনকামিং ক্লায়েন্ট বাইন্ডার টোকেনে
IBinder.addFrozenStateChangeCallbackব্যবহার করুন। - ফ্রিজ করা অবস্থায় ডিসপ্যাচ পজ করা: কোনও ক্লায়েন্ট
STATE_FROZENপ্রবেশ করলে, সেই ক্লায়েন্টকে কলব্যাক বা স্টেট আপডেট ডিসপ্যাচ করা পজ করুন। - আনফ্রিজ করার পরে আবার শুরু ও ডেলিভার করা: ক্লায়েন্ট
STATE_UNFROZEN-এ ট্রানজিশন করলে, কলব্যাক ডিসপ্যাচ করা আবার শুরু করুন এবং প্রয়োজনীয় ব্যাচ বা কনসোলিডেটেড আপডেট ডেলিভার করুন। - RemoteCallbackList ব্যবহার করুন:
RemoteCallbackListব্যবহার করা সিস্টেম পরিষেবাগুলি ম্যানুয়াল ট্র্যাকিং লজিক বজায় না রেখেই কলব্যাক ডিসপ্যাচিং অটোমেটিক পজ ও আবার চালু করতে ফ্রোজেন কলি নীতি কনফিগার করতে পারে। আরও তথ্যের জন্য, সিস্টেম পরিষেবার জন্য বাইন্ডার ফ্রিজার সংক্রান্ত সাজেশনদেখুন।
অ্যাসিঙ্ক্রোনাস বাইন্ডার ট্রানজ্যাকশন বাফার ওভারফ্লো
সার্ভার অ্যাপ প্রসেস ফ্রিজ থাকাকালীন অ্যাসিঙ্ক্রোনাস (oneway) বাইন্ডার ট্রানজ্যাকশন পেলে, ট্রানজ্যাকশনগুলি প্রসেস-প্রতি বাফারে বাফার করা হয়। ফ্রিজ করা অবস্থায় সার্ভার
অ্যাসিঙ্ক্রোনাস ট্রানজ্যাকশন খুব বেশি পেলে, বাফার
ওভারফ্লো হয়ে যায় এবং সিস্টেম সার্ভার অ্যাপ প্রসেস বন্ধ করে দেয়।
এই বাফার ওভারফ্লো প্রতিরোধ করতে, ক্যাশে করা বা ফ্রিজ করা হতে পারে এমন প্রসেসে অতিরিক্ত অ্যাসিঙ্ক্রোনাস বাইন্ডার ট্রানজ্যাকশন পাঠানো এড়িয়ে চলুন।
আনফ্রিজ করার পরে শিডিউল করা টাস্ক বারবার এক্সিকিউট করা
কোনও অ্যাপ যদি বার বার একই টাস্ক এক্সিকিউট করে, তাহলে প্রসেস
ফ্রিজ করা অবস্থায় সেটি সাসপেন্ড করা হয়। আরও তথ্যের জন্য, দেখুন
ScheduledThreadPoolExecutor.scheduleAtFixedRate
অথবা Timer.scheduleAtFixedRate. প্রসেস আনফ্রিজ হলে, জমে থাকা মিসড এক্সিকিউশনগুলি
একটির পরে একটি খুব দ্রুত
রান করতে পারে।
অ্যাপ আনফ্রিজ হওয়ার সময় এক্সিকিউশনের সংখ্যা যাতে হঠাৎ করে বেড়ে না যায়, তার জন্য ব্যাকগ্রাউন্ড টাস্কের ক্ষেত্রে
scheduleAtFixedRate-এর পরিবর্তে
scheduleWithFixedDelay ব্যবহার করুন। এছাড়াও, আপনি WorkManager ব্যবহার করতে পারেন।
অ্যাপ ফ্রিজার পরীক্ষা করা ও সমস্যার সমাধান করা
অ্যাপ ফ্রিজার সঠিকভাবে কাজ করছে কিনা তা যাচাই করতে অথবা ফ্রিজার সম্পর্কিত সমস্যার সমাধান করতে, নিচের ডায়াগনস্টিক টুল ও কমান্ড ব্যবহার করুন:
অ্যাক্টিভিটি ম্যানেজার কমান্ড
আপনি adb shell am কমান্ড ব্যবহার করে কোনও নির্দিষ্ট প্রসেসের জন্য ম্যানুয়ালি ফ্রিজ করা ও কম্প্যাক্ট করা
কন্ট্রোল করতে পারবেন:
কোনও প্রসেসকে ফ্রিজ করতে বাধ্য করা:
adb shell am freeze <process>কোনও প্রসেসকে আনফ্রিজ করতে বাধ্য করা:
adb shell am unfreeze <process>কোনও প্রসেসে সম্পূর্ণ মেমরি কম্প্যাকশন প্রয়োগ করা:
adb shell am compact full <process>
Logcat পরীক্ষা
কোনও প্রসেস ফ্রিজারে ঢোকা বা বেরোনোর সময়, ফ্রিজ করা ও ফ্রিজ না করা এন্ট্রিগুলি দেখতে logcat দেখুন:
adb logcat | grep -i "\(freezing\|froze\)"আনফ্রিজ করার কারণের লগ আউটপুট UnfreezeReason প্রোটোকল
বাফার এনুম থেকে গণনা করা ভ্যালু।
Dumpsys পরিদর্শন
dumpsys activity ব্যবহার করে ফ্রিজ করা প্রসেসের তালিকা চেক করুন:
adb shell dumpsys activity | grep -A 20 "Apps frozen:"/sys/fs/cgroup/uid_0/cgroup.freeze ফাইল আছে কিনা চেক করুন।
ApplicationExitInfo
আগের প্রসেস বন্ধ করে দেওয়ার কারণ সম্পর্কে কোয়েরি করতে, ActivityManager.getHistoricalProcessExitReasons দেখুন।
ফ্রিজার সংক্রান্ত সমস্যার কারণে কোনও অ্যাপ প্রসেস বন্ধ হয়ে গেলে, যেমন
ফ্রিজ হয়ে থাকা অবস্থায় সিঙ্ক্রোনাস বাইন্ডার ট্রানজ্যাকশন পেলে, বেরিয়ে আসার কারণ
ApplicationExitInfo.REASON_FREEZER হিসেবে সেট করা হয়।
Perfetto ট্রেসিং
Perfetto ট্রেসে system_server প্রসেসের অধীনে Freezer নামের ট্র্যাকে ফ্রিজার-সম্পর্কিত ইভেন্টগুলি নির্গত হয়:
FreezeওUnfreezeস্লাইস থেকে বোঝা যায় যে কোনও প্রসেস কখন স্ট্যাটাস পরিবর্তন করে।- ফ্রিজ বা আনফ্রিজ করার সিদ্ধান্ত নেওয়ার জন্য সিস্টেম সার্ভার
প্রসেস অ্যাট্রিবিউট আবার পরীক্ষা করলে
updateAppFreezeStateLSPইভেন্ট দেখা যায়।
আপনি সরাসরি Perfetto UI-তে এইসব ইভেন্ট পরিদর্শন করতে পারেন অথবা PerfettoSQL ব্যবহার করে সেগুলি বিশ্লেষণ করতে পারেন:
INCLUDE PERFETTO MODULE slices.with_context;
SELECT *
FROM process_slice
WHERE process_name = "system_server"
AND track_name = "Freezer"
AND (name LIKE "Freeze %" OR name LIKE "Unfreeze %");
PerfettoSQL স্ট্যান্ডার্ড লাইব্রেরিতে, ফ্রিজার ইভেন্টগুলিও
android_freezer_events টেবিলে সংক্ষিপ্তসার করা হয়।