বাগ রিপোর্ট পড়া

বাগগুলি যে কোনও ধরণের বিকাশের একটি বাস্তবতা - এবং বাগ রিপোর্টগুলি সমস্যাগুলি সনাক্তকরণ এবং সমাধান করার জন্য গুরুত্বপূর্ণ৷ অ্যান্ড্রয়েডের সমস্ত সংস্করণ অ্যান্ড্রয়েড ডিবাগ ব্রিজ (এডিবি) দিয়ে বাগ রিপোর্ট ক্যাপচার করতে সহায়তা করে; অ্যান্ড্রয়েড সংস্করণ 4.2 এবং উচ্চতর বাগ রিপোর্ট নেওয়া এবং ইমেল, ড্রাইভ, ইত্যাদির মাধ্যমে ভাগ করার জন্য একটি বিকাশকারী বিকল্পকে সমর্থন করে।

অ্যান্ড্রয়েড বাগ রিপোর্টগুলিতে পাঠ্য (.txt) বিন্যাসে logcat dumpstate dumpsys , যা আপনাকে নির্দিষ্ট সামগ্রীর জন্য সহজেই অনুসন্ধান করতে সক্ষম করে৷ নিম্নলিখিত বিভাগগুলি বাগ রিপোর্টের উপাদানগুলির বিশদ বিবরণ দেয়, সাধারণ সমস্যাগুলি বর্ণনা করে এবং সেই বাগগুলির সাথে যুক্ত লগগুলি খুঁজে বের করার জন্য সহায়ক টিপস এবং grep কমান্ড দেয়৷ বেশিরভাগ বিভাগে grep এবং আউটপুট এবং/অথবা dumpsys আউটপুটের উদাহরণ রয়েছে।

লগক্যাট

logcat লগ হল সমস্ত logcat তথ্যের একটি স্ট্রিং-ভিত্তিক ডাম্প। সিস্টেমের অংশটি ফ্রেমওয়ার্কের জন্য সংরক্ষিত এবং মূলের চেয়ে দীর্ঘ ইতিহাস রয়েছে যা অন্য সবকিছু ধারণ করে। প্রতিটি লাইন সাধারণত timestamp UID PID TID log-level দিয়ে শুরু হয়, যদিও UID Android এর পুরানো সংস্করণে তালিকাভুক্ত নাও হতে পারে।

ইভেন্ট লগ দেখা

এই লগটিতে বাইনারি-ফরম্যাট করা লগ বার্তাগুলির স্ট্রিং উপস্থাপনা রয়েছে। এটি logcat লগের চেয়ে কম শোরগোল কিন্তু পড়তে একটু কঠিন। ইভেন্ট লগ দেখার সময়, একটি প্রক্রিয়া কী করছে তা দেখতে আপনি নির্দিষ্ট প্রক্রিয়া আইডি (পিআইডি) এর জন্য এই বিভাগে অনুসন্ধান করতে পারেন। মৌলিক বিন্যাস হল: timestamp PID TID log-level log-tag tag-values

লগ স্তর নিম্নলিখিত অন্তর্ভুক্ত:

  • V: verbose
  • ডি: ডিবাগ
  • আমি: তথ্য
  • W: সতর্কতা
  • ই: ত্রুটি

অন্যান্য দরকারী ইভেন্ট লগ ট্যাগের জন্য, /services/core/java/com/android/server/EventLogTags.logtags দেখুন

ANR এবং অচলাবস্থা

অ্যাপ্লিকেশন নট রেসপন্ডিং (ANR) ত্রুটি এবং অচলাবস্থার ঘটনাগুলি কী ঘটছে তা শনাক্ত করতে Bugreports আপনাকে সাহায্য করতে পারে৷

প্রতিক্রিয়াহীন অ্যাপগুলি সনাক্ত করা

যখন একটি অ্যাপ্লিকেশন নির্দিষ্ট সময়ের মধ্যে সাড়া না দেয়, সাধারণত একটি ব্লক বা ব্যস্ত প্রধান থ্রেডের কারণে, সিস্টেমটি প্রক্রিয়াটিকে মেরে ফেলে এবং স্ট্যাকটিকে /data/anr এ ডাম্প করে। একটি ANR-এর পিছনে অপরাধীকে খুঁজে বের করতে, বাইনারি ইভেন্ট লগে am_anr এর জন্য grep।

এছাড়াও আপনি logcat লগ-এ ANR in জন্য গ্রেপ করতে পারেন, যাতে ANR-এর সময় CPU কী ব্যবহার করা হয়েছিল সে সম্পর্কে আরও তথ্য রয়েছে।

স্ট্যাক ট্রেস খোঁজা

আপনি প্রায়ই ANR-এর সাথে সঙ্গতিপূর্ণ স্ট্যাক ট্রেস খুঁজে পেতে পারেন। নিশ্চিত করুন যে VM ট্রেসে টাইমস্ট্যাম্প এবং পিআইডি আপনার তদন্ত করা ANR-এর সাথে মেলে, তারপর প্রক্রিয়াটির মূল থ্রেড পরীক্ষা করুন। মনে রেখ:

  • মূল থ্রেডটি আপনাকে বলে যে ANR-এর সময় থ্রেডটি কী করছিল, যা ANR-এর প্রকৃত কারণের সাথে মিল থাকতে পারে বা নাও হতে পারে। (বাগ রিপোর্টের স্ট্যাকটি নির্দোষ হতে পারে; অন্য কিছু দীর্ঘ সময়ের জন্য আটকে থাকতে পারে-কিন্তু ANR-এর জন্য যথেষ্ট দীর্ঘ নয়-আনস্ট্যাক হওয়ার আগে।)
  • স্ট্যাক ট্রেসগুলির একাধিক সেট ( VM TRACES JUST NOW এবং VM TRACES AT LAST ANR ) থাকতে পারে৷ আপনি সঠিক বিভাগটি দেখছেন তা নিশ্চিত করুন।

অচলাবস্থা খোঁজা

ডেডলকগুলি প্রায়শই প্রথমে ANR হিসাবে প্রদর্শিত হয় কারণ থ্রেডগুলি আটকে যাচ্ছে। যদি অচলাবস্থা সিস্টেম সার্ভারে আঘাত করে, তাহলে ওয়াচডগ শেষ পর্যন্ত এটিকে মেরে ফেলবে, যার ফলে লগে একটি এন্ট্রি হবে এর মতো: WATCHDOG KILLING SYSTEM PROCESS । ব্যবহারকারীর দৃষ্টিকোণ থেকে, ডিভাইসটি রিবুট হয়, যদিও প্রযুক্তিগতভাবে এটি একটি সত্যিকারের রিবুটের পরিবর্তে একটি রানটাইম রিস্টার্ট।

  • একটি রানটাইম রিস্টার্টে, সিস্টেম সার্ভারটি মারা যায় এবং পুনরায় চালু হয়; ব্যবহারকারী ডিভাইসটিকে বুট অ্যানিমেশনে ফিরে যেতে দেখেন।
  • একটি রিবুটে , কার্নেল ক্র্যাশ হয়েছে; ব্যবহারকারী ডিভাইসটিকে Google বুট লোগোতে ফিরে যেতে দেখেন।

অচলাবস্থা খুঁজে পেতে, থ্রেড A এর একটি প্যাটার্নের জন্য VM ট্রেস বিভাগগুলি পরীক্ষা করুন B থ্রেড দ্বারা ধারণ করা কিছুর জন্য অপেক্ষা করছে, যা থ্রেড A দ্বারা ধারণ করা কিছুর জন্য অপেক্ষা করছে।

কার্যক্রম

একটি ক্রিয়াকলাপ হল একটি অ্যাপ্লিকেশন উপাদান যা একটি স্ক্রীন ব্যবহারকারীদের সাথে কিছু করার জন্য যোগাযোগ করে যেমন একটি নম্বর ডায়াল করা, একটি ফটো তোলা, একটি ইমেল পাঠানো ইত্যাদি। , যা ক্র্যাশের সময় ফোকাসে থাকা ক্রিয়াকলাপটি সনাক্ত করা অত্যন্ত গুরুত্বপূর্ণ করে তোলে। ক্রিয়াকলাপগুলি (অ্যাক্টিভিটি ম্যানেজারের মাধ্যমে) প্রক্রিয়াগুলি চালায়, তাই প্রদত্ত ক্রিয়াকলাপের জন্য সমস্ত প্রক্রিয়া স্টপ এবং শুরু হওয়ার সনাক্তকরণ সমস্যা সমাধানে সহায়তা করতে পারে।

দৃষ্টি নিবদ্ধ কার্যকলাপ দেখা

ফোকাসড কার্যকলাপের ইতিহাস দেখতে, am_focused_activity অনুসন্ধান করুন।

দেখার প্রক্রিয়া শুরু হয়

প্রক্রিয়া শুরু হওয়ার ইতিহাস দেখতে, Start proc অনুসন্ধান করুন।

ডিভাইস থ্র্যাশিং হয়?

ডিভাইসটি am_proc_died এবং am_proc_start এর কাছাকাছি কার্যকলাপে অস্বাভাবিক বৃদ্ধি পরীক্ষা করুন৷

স্মৃতি

যেহেতু অ্যান্ড্রয়েড ডিভাইসগুলিতে প্রায়ই শারীরিক মেমরি সীমাবদ্ধ থাকে, র্যান্ডম-অ্যাক্সেস মেমরি (RAM) পরিচালনা করা গুরুত্বপূর্ণ। বাগ রিপোর্টে কম মেমরির বিভিন্ন সূচকের পাশাপাশি একটি ডাম্পস্টেট রয়েছে যা একটি মেমরি স্ন্যাপশট প্রদান করে।

কম স্মৃতি শনাক্ত করা

কম মেমরি সিস্টেমকে থ্রাশ করতে পারে কারণ এটি মেমরি মুক্ত করার জন্য কিছু প্রসেসকে মেরে ফেলে কিন্তু অন্যান্য প্রসেস শুরু করতে থাকে। কম মেমরির প্রমাণের প্রমাণ দেখতে, বাইনারি ইভেন্ট লগে am_proc_died এবং am_proc_start এন্ট্রিগুলির ঘনত্ব পরীক্ষা করুন।

কম মেমরি টাস্ক স্যুইচিংকেও ধীর করে দিতে পারে এবং রিটার্নের প্রচেষ্টাকে ব্যর্থ করে দিতে পারে (কারণ ব্যবহারকারী যে টাস্কে ফিরে যাওয়ার চেষ্টা করছিল সেটিকে হত্যা করা হয়েছিল)। লঞ্চারটি মারা গেলে, ব্যবহারকারী হোম বোতাম স্পর্শ করলে এটি পুনরায় চালু হয় এবং লগগুলি লঞ্চারটি তার সামগ্রী পুনরায় লোড দেখায়।

ঐতিহাসিক সূচক দেখা

বাইনারি ইভেন্ট লগে am_low_memory এন্ট্রি নির্দেশ করে যে শেষ ক্যাশে করা প্রক্রিয়াটি মারা গেছে। এর পরে, সিস্টেম হত্যা পরিষেবা শুরু করে।

থ্র্যাশিং সূচক দেখা হচ্ছে

সিস্টেম থ্র্যাশিং (পেজিং, সরাসরি পুনরুদ্ধার, ইত্যাদি) এর অন্যান্য সূচকগুলির মধ্যে রয়েছে kswapd , kworker , এবং mmcqd চক্র। (মনে রাখবেন যে বাগ রিপোর্ট সংগ্রহ করা হচ্ছে তা থ্র্যাশিং সূচককে প্রভাবিত করতে পারে।)

ANR লগগুলি একটি অনুরূপ মেমরি স্ন্যাপশট প্রদান করতে পারে।

একটি মেমরি স্ন্যাপশট হচ্ছে

মেমরি স্ন্যাপশট হল একটি ডাম্পস্টেট যা চলমান জাভা এবং নেটিভ প্রসেসগুলিকে তালিকাভুক্ত করে (বিশদ বিবরণের জন্য, সামগ্রিক মেমরি বরাদ্দ দেখুন )। মনে রাখবেন স্ন্যাপশট সময় নির্দিষ্ট মুহূর্তে শুধুমাত্র রাষ্ট্র দেয়; স্ন্যাপশটের আগে সিস্টেমটি আরও ভাল (বা খারাপ) আকারে থাকতে পারে।

সম্প্রচার

অ্যাপ্লিকেশনগুলি বর্তমান অ্যাপ্লিকেশনের মধ্যে বা অন্য অ্যাপ্লিকেশনে ইভেন্ট পাঠাতে সম্প্রচার তৈরি করে। ব্রডকাস্ট রিসিভাররা নির্দিষ্ট বার্তাগুলিতে (ফিল্টারের মাধ্যমে) সাবস্ক্রাইব করে, তাদের সম্প্রচার শুনতে এবং প্রতিক্রিয়া উভয়ই করতে সক্ষম করে। বাগ রিপোর্টে প্রেরিত সম্প্রচার এবং অপ্রেরিত সম্প্রচার সম্পর্কে তথ্য রয়েছে, সেইসাথে একটি নির্দিষ্ট সম্প্রচার শোনার সমস্ত রিসিভারের ডাম্পসি।

ঐতিহাসিক সম্প্রচার দেখা

ঐতিহাসিক সম্প্রচার হল সেইগুলি যা ইতিমধ্যেই পাঠানো হয়েছে, বিপরীত কালানুক্রমিক ক্রমে তালিকাভুক্ত।

সারাংশ বিভাগটি শেষ 300টি ফোরগ্রাউন্ড সম্প্রচার এবং শেষ 300টি পটভূমি সম্প্রচারের একটি ওভারভিউ।

বিস্তারিত বিভাগে শেষ 50টি ফোরগ্রাউন্ড সম্প্রচার এবং শেষ 50টি পটভূমি সম্প্রচারের জন্য সম্পূর্ণ তথ্য রয়েছে, সেইসাথে প্রতিটি সম্প্রচারের জন্য রিসিভার রয়েছে৷ রিসিভার যাদের একটি আছে:

  • BroadcastFilter এন্ট্রি রানটাইমে নিবন্ধিত হয় এবং শুধুমাত্র ইতিমধ্যে চলমান প্রক্রিয়াগুলিতে পাঠানো হয়।
  • ResolveInfo এন্ট্রি ম্যানিফেস্ট এন্ট্রির মাধ্যমে নিবন্ধিত হয়। ActivityManager প্রতিটি ResolveInfo এর জন্য প্রক্রিয়া শুরু করে যদি এটি ইতিমধ্যে চালু না হয়।

সক্রিয় সম্প্রচার দেখা হচ্ছে

সক্রিয় সম্প্রচার হল সেগুলি যেগুলি এখনও পাঠানো হয়নি৷ সারিতে একটি বড় সংখ্যা মানে সিস্টেমটি সম্প্রচার চালিয়ে যাওয়ার জন্য যথেষ্ট দ্রুত প্রেরণ করতে পারে না।

সম্প্রচার শ্রোতাদের দেখা

সম্প্রচারের জন্য শোনা রিসিভারের একটি তালিকা দেখতে, dumpsys activity broadcasts রিসিভার রিজলভার টেবিলটি দেখুন। নিম্নলিখিত উদাহরণটি USER_PRESENT জন্য শোনা সমস্ত রিসিভার প্রদর্শন করে।

বিরোধ মনিটর

মনিটর বিবাদ লগিং কখনও কখনও প্রকৃত মনিটরের বিরোধ নির্দেশ করতে পারে, তবে বেশিরভাগ ক্ষেত্রে সিস্টেমটি এত লোড হয়েছে যে সবকিছু ধীর হয়ে গেছে। আপনি সিস্টেম বা ইভেন্ট লগে ART দ্বারা লগ করা দীর্ঘ মনিটর ইভেন্টগুলি দেখতে পারেন।

সিস্টেম লগে:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

ইভেন্ট লগে:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

পটভূমি সংকলন

সংকলন ব্যয়বহুল হতে পারে এবং ডিভাইসটি লোড করতে পারে।

Google Play Store আপডেটগুলি ডাউনলোড করার সময় পটভূমিতে সংকলন ঘটতে পারে। এই ক্ষেত্রে, dex2oat বার্তার আগে Google Play store অ্যাপ ( finsky ) এবং installd থেকে বার্তাগুলি উপস্থিত হয়৷

কম্পাইলেশন ব্যাকগ্রাউন্ডেও ঘটতে পারে যখন একটি অ্যাপ্লিকেশন একটি ডেক্স ফাইল লোড করছে যা এখনও কম্পাইল করা হয়নি। এই ক্ষেত্রে, আপনি finsky বা installd লগিং দেখতে পাবেন না।

বর্ণনামূলক

একটি সমস্যার আখ্যান স্থাপন করার জন্য (এটি কীভাবে শুরু হয়েছিল, কী হয়েছিল, সিস্টেমটি কীভাবে প্রতিক্রিয়া করেছিল) ইভেন্টগুলির একটি কঠিন সময়রেখা প্রয়োজন। আপনি একাধিক লগ জুড়ে টাইমলাইন সিঙ্ক করতে এবং বাগ রিপোর্টের সঠিক টাইমস্ট্যাম্প নির্ধারণ করতে বাগ রিপোর্টের তথ্য ব্যবহার করতে পারেন।

টাইমলাইন সিঙ্ক করা হচ্ছে

একটি বাগ রিপোর্ট একাধিক সমান্তরাল টাইমলাইন প্রতিফলিত করে: সিস্টেম লগ, ইভেন্ট লগ, কার্নেল লগ, এবং সম্প্রচারের জন্য একাধিক বিশেষ টাইমলাইন, ব্যাটারি পরিসংখ্যান, ইত্যাদি৷ দুর্ভাগ্যবশত, টাইমলাইনগুলি প্রায়শই বিভিন্ন সময় বেস ব্যবহার করে রিপোর্ট করা হয়৷

সিস্টেম এবং ইভেন্ট লগ টাইমস্ট্যাম্পগুলি ব্যবহারকারীর মতো একই টাইমজোনে রয়েছে (অন্যান্য টাইমস্ট্যাম্পগুলির মতো)৷ উদাহরণস্বরূপ, যখন ব্যবহারকারী হোম বোতামে ট্যাপ করে, সিস্টেম লগ রিপোর্ট করে:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

একই কর্মের জন্য, ইভেন্ট লগ রিপোর্ট করে:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

বুটলোডার সম্পূর্ণ হওয়ার পর থেকে কার্নেল ( dmesg ) লগগুলি একটি ভিন্ন টাইম বেস ব্যবহার করে, লগ আইটেমগুলিকে সেকেন্ডের সাথে ট্যাগ করে। এই টাইমস্কেলটিকে অন্যান্য টাইমস্কেলে নিবন্ধন করতে, সাসপেন্ড এক্সিট এবং সাসপেন্ড এন্ট্রি বার্তাগুলি অনুসন্ধান করুন:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

যেহেতু কার্নেল লগগুলি সাসপেন্ডে থাকাকালীন সময় অন্তর্ভুক্ত নাও করতে পারে, আপনার সাসপেন্ড এন্ট্রি এবং প্রস্থান বার্তাগুলির মধ্যে লগটিকে টুকরো টুকরো করে নিবন্ধন করা উচিত। অতিরিক্তভাবে, কার্নেল লগগুলি UTC টাইমজোন ব্যবহার করে এবং ব্যবহারকারীর টাইমজোনের সাথে সামঞ্জস্য করা আবশ্যক।

বাগ রিপোর্টের সময় শনাক্ত করা হচ্ছে

কখন একটি বাগ রিপোর্ট নেওয়া হয়েছিল তা নির্ধারণ করতে, প্রথমে ডাম্পস্টেটের জন্য সিস্টেম লগ (লগক্যাট) পরীক্ষা করুন dumpstate: begin :

10-03 17:19:54.322 19398 19398 I dumpstate: begin

এরপরে, Starting service 'bugreport' বার্তার জন্য কার্নেল লগ ( dmesg ) টাইমস্ট্যাম্পগুলি পরীক্ষা করুন:

<5>[207064.285315] init: Starting service 'bugreport'...

সিঙ্কিং টাইমলাইনে উল্লিখিত সতর্কতাগুলিকে মাথায় রেখে দুটি ইভেন্টের সাথে সম্পর্ক স্থাপনের জন্য পিছনের দিকে কাজ করুন। যদিও বাগ রিপোর্ট শুরু হওয়ার পরে অনেক কিছু ঘটছে, বেশিরভাগ ক্রিয়াকলাপ খুব কার্যকর নয় কারণ বাগ রিপোর্ট নেওয়ার কাজটি সিস্টেমকে যথেষ্ট পরিমাণে লোড করে।

শক্তি

ইভেন্ট লগে স্ক্রীন পাওয়ার স্ট্যাটাস রয়েছে, যেখানে 0 স্ক্রীন অফ, 1 স্ক্রীন চালু এবং 2টি কীগার্ড সম্পন্ন করার জন্য।

বাগ রিপোর্টগুলিতে ওয়েক লকগুলির পরিসংখ্যানও রয়েছে, একটি পদ্ধতি যা অ্যাপ্লিকেশন বিকাশকারীরা তাদের অ্যাপ্লিকেশনটিকে ডিভাইসটি চালু রাখার প্রয়োজন নির্দেশ করতে ব্যবহার করে। (ওয়েক লক সম্পর্কে বিস্তারিত জানার জন্য, পাওয়ার ম্যানেজার দেখুন। ওয়েকলক এবং সিপিইউ চালু রাখুন ।)

একত্রিত ওয়েক লক সময়কালের পরিসংখ্যান শুধুমাত্র সেই সময় ট্র্যাক করে যখন একটি ওয়েক লক আসলে ডিভাইসটিকে জাগ্রত রাখার জন্য দায়ী এবং স্ক্রীন চালু থাকার সময় অন্তর্ভুক্ত করে না । উপরন্তু, যদি একাধিক ওয়েক লক একই সাথে রাখা হয়, তাহলে ওয়েক লকের সময়কাল ঐ ওয়েক লকগুলিতে বিতরণ করা হয়।

পাওয়ার স্ট্যাটাস ভিজ্যুয়ালাইজ করতে আরও সাহায্যের জন্য, ব্যাটারি হিস্টোরিয়ান ব্যবহার করুন, একটি Google ওপেন সোর্স টুল অ্যান্ড্রয়েড বাগ রিপোর্ট ফাইল ব্যবহার করে ব্যাটারি গ্রাহকদের বিশ্লেষণ করতে।

প্যাকেজ

DUMP OF SERVICE package বিভাগে অ্যাপ্লিকেশন সংস্করণ (এবং অন্যান্য দরকারী তথ্য) রয়েছে।

প্রসেস

বাগ রিপোর্টে প্রসেসগুলির জন্য প্রচুর পরিমাণে ডেটা থাকে, যার মধ্যে রয়েছে শুরু এবং থামার সময়, রানটাইম দৈর্ঘ্য, সংশ্লিষ্ট পরিষেবা, oom_adj স্কোর, ইত্যাদি৷ Android কীভাবে প্রক্রিয়াগুলি পরিচালনা করে তার বিশদ বিবরণের জন্য, প্রসেস এবং থ্রেডগুলি পড়ুন৷

প্রক্রিয়া রানটাইম নির্ধারণ

procstats বিভাগে কতদিন ধরে প্রক্রিয়া এবং সংশ্লিষ্ট পরিষেবাগুলি চলছে তার সম্পূর্ণ পরিসংখ্যান রয়েছে৷ একটি দ্রুত, মানব-পাঠযোগ্য সারাংশের জন্য, গত তিন বা 24 ঘন্টার ডেটা দেখতে AGGREGATED OVER অনুসন্ধান করুন, তারপর Summary: প্রক্রিয়াগুলির তালিকা দেখতে, সেই প্রক্রিয়াগুলি কতক্ষণ ধরে বিভিন্ন অগ্রাধিকারে চলছে এবং তাদের RAM ব্যবহার ন্যূনতম-গড়-সর্বোচ্চ PSS/মিন-গড়-সর্বোচ্চ USS হিসাবে বিন্যাসিত।

কেন একটি প্রক্রিয়া চলমান?

ডাম্পসিস অ্যাক্টিভিটি dumpsys activity processes বিভাগটি oom_adj স্কোর দ্বারা আদেশকৃত বর্তমানে চলমান সমস্ত প্রক্রিয়ার তালিকা করে (Android প্রক্রিয়াটিকে একটি oom_adj মান নির্ধারণ করে প্রক্রিয়ার গুরুত্ব নির্দেশ করে, যা ActivityManager দ্বারা গতিশীলভাবে আপডেট করা যেতে পারে)। আউটপুটটি একটি মেমরি স্ন্যাপশটের অনুরূপ তবে প্রক্রিয়াটি চালানোর কারণ সম্পর্কে অতিরিক্ত তথ্য অন্তর্ভুক্ত করে। নীচের উদাহরণে, বোল্ড করা এন্ট্রিগুলি নির্দেশ করে যে gms.persistent প্রক্রিয়াটি vis (দৃশ্যমান) অগ্রাধিকারে চলছে কারণ সিস্টেম প্রক্রিয়াটি তার NetworkLocationService এর সাথে আবদ্ধ।

স্ক্যান

অত্যধিক ব্লুটুথ লো এনার্জি (BLE) স্ক্যান করা অ্যাপ্লিকেশনগুলি সনাক্ত করতে নিম্নলিখিত পদক্ষেপগুলি ব্যবহার করুন:

  • BluetoothLeScanner এর জন্য লগ বার্তা খুঁজুন :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • লগ বার্তাগুলিতে PID সনাক্ত করুন৷ এই উদাহরণে, "24840" এবং "24851" হল PID (প্রসেস আইডি) এবং TID (থ্রেড আইডি)।
  • PID-এর সাথে যুক্ত অ্যাপ্লিকেশনটি সনাক্ত করুন:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    এই উদাহরণে, প্যাকেজের নাম com.badapp

  • দায়ী অ্যাপ্লিকেশন শনাক্ত করতে Google Play-তে প্যাকেজের নামটি দেখুন: https://play.google.com/store/apps/details?id=com.badapp

দ্রষ্টব্য : Android 7.0 চালিত ডিভাইসগুলির জন্য, সিস্টেম BLE স্ক্যানের জন্য ডেটা সংগ্রহ করে এবং এই ক্রিয়াকলাপগুলিকে সূচনাকারী অ্যাপ্লিকেশনের সাথে সংযুক্ত করে। বিশদ বিবরণের জন্য, নিম্ন শক্তি (LE) এবং ব্লুটুথ স্ক্যানগুলি দেখুন।