অ্যাপের কর্মক্ষমতা পরিমাপের ওভারভিউ

এই ডকুমেন্টটি আপনাকে আপনার অ্যাপের প্রধান পারফরম্যান্স সমস্যাগুলো শনাক্ত করতে ও সমাধান করতে সাহায্য করে।

মূল কর্মক্ষমতা সমস্যা

একটি অ্যাপের খারাপ পারফরম্যান্সের পেছনে অনেক সমস্যাই দায়ী হতে পারে, তবে আপনার অ্যাপে সাধারণত যে সমস্যাগুলো খুঁজে দেখা উচিত, তার কয়েকটি নিচে দেওয়া হলো:

স্টার্টআপ লেটেন্সি

স্টার্টআপ ল্যাটেন্সি হলো অ্যাপ আইকন, নোটিফিকেশন বা অন্য কোনো এন্ট্রি পয়েন্টে ট্যাপ করার পর থেকে স্ক্রিনে ব্যবহারকারীর ডেটা প্রদর্শিত হওয়া পর্যন্ত সময়।

আপনার অ্যাপগুলিতে নিম্নলিখিত স্টার্টআপ লক্ষ্যগুলি অর্জনের চেষ্টা করুন:

• ৫০০ মিলিসেকেন্ডেরও কম সময়ে কোল্ড স্টার্ট। যখন চালু করা অ্যাপটি সিস্টেমের মেমরিতে উপস্থিত থাকে না, তখন কোল্ড স্টার্ট হয়। রিবুটের পর অথবা ব্যবহারকারী বা সিস্টেম দ্বারা অ্যাপ প্রসেসটি বন্ধ করার পর অ্যাপটির প্রথমবার চালুর ক্ষেত্রে এটি ঘটে।

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

• P95 এবং P99 ল্যাটেন্সি মিডিয়ান ল্যাটেন্সির খুব কাছাকাছি থাকে। যখন অ্যাপটি চালু হতে দীর্ঘ সময় নেয়, তখন এটি ব্যবহারকারীর জন্য একটি খারাপ অভিজ্ঞতা তৈরি করে। অ্যাপ চালুর ক্রিটিক্যাল পাথে ইন্টারপ্রসেস কমিউনিকেশন (IPC) এবং অপ্রয়োজনীয় I/O-এর কারণে লক কনটেনশন হতে পারে এবং অসঙ্গতি দেখা দিতে পারে।

স্ক্রোল জ্যাঙ্ক

জ্যাঙ্ক হলো সেই দৃশ্যমান বাধা যা তখন ঘটে যখন সিস্টেম প্রতি সেকেন্ডে ৬০ হার্টজ বা তার বেশি হারে অনুরোধ করা গতিতে স্ক্রিনে ফ্রেম তৈরি ও সরবরাহ করতে পারে না। স্ক্রোল করার সময় জ্যাঙ্ক সবচেয়ে বেশি স্পষ্ট হয়, যখন মসৃণভাবে অ্যানিমেটেড প্রবাহের পরিবর্তে বাধা দেখা যায়। যখন অ্যাপের কন্টেন্ট রেন্ডার করতে সিস্টেমের একটি ফ্রেমের সময়কালের চেয়ে বেশি সময় লাগে, তখন এক বা একাধিক ফ্রেমের জন্য গতি থেমে গেলে জ্যাঙ্ক দেখা দেয়।

অ্যাপগুলোকে অবশ্যই ৯০ হার্টজ রিফ্রেশ রেট টার্গেট করতে হবে। প্রচলিত রেন্ডারিং রেট হলো ৬০ হার্টজ, কিন্তু অনেক নতুন ডিভাইস ব্যবহারকারীর কার্যকলাপের সময়, যেমন স্ক্রোল করার সময়, ৯০ হার্টজ মোডে কাজ করে। কিছু ডিভাইস ১২০ হার্টজ পর্যন্ত আরও উচ্চ রেটও সাপোর্ট করে।

কোনো নির্দিষ্ট সময়ে ডিভাইসটি কী রিফ্রেশ রেট ব্যবহার করছে তা দেখতে, ডেভেলপার অপশন-এর ডিবাগিং সেকশনে থাকা ‘শো রিফ্রেশ রেট’ বিকল্পটি ব্যবহার করে একটি ওভারলে চালু করুন।

যে পরিবর্তনগুলো মসৃণ নয়

ট্যাব পরিবর্তন করা বা নতুন কোনো অ্যাক্টিভিটি লোড করার মতো ইন্টারঅ্যাকশনের সময় এটি স্পষ্ট বোঝা যায়। এই ধরনের ট্রানজিশনগুলো অবশ্যই মসৃণ অ্যানিমেশন হতে হবে এবং এতে কোনো বিলম্ব বা ভিজ্যুয়াল ফ্লিকার থাকা চলবে না।

বিদ্যুৎ অদক্ষতা

কাজ করলে ব্যাটারির চার্জ কমে যায়, এবং অপ্রয়োজনীয় কাজ করলে ব্যাটারির আয়ু কমে যায়।

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

তবে, এর জন্য শ্রমসাধ্য, তাই মনে রাখবেন যে আপনার ভেতরের লুপে অনেকগুলো অবজেক্ট বরাদ্দ করলে এটি পারফরম্যান্সের সমস্যা তৈরি করতে পারে।

সমস্যা চিহ্নিত করুন

পারফরম্যান্স সমস্যা শনাক্ত ও প্রতিকারের জন্য আমরা নিম্নলিখিত কার্যপ্রবাহের সুপারিশ করছি:

1. নিম্নলিখিত গুরুত্বপূর্ণ ব্যবহারকারী যাত্রাগুলি সনাক্ত করুন এবং পরিদর্শন করুন:
   • লঞ্চার এবং নোটিফিকেশন সহ সাধারণ স্টার্টআপ ফ্লো।
   • যেসব স্ক্রিনে ব্যবহারকারী ডেটা স্ক্রল করে দেখতে পারেন।
   • স্ক্রিনগুলোর মধ্যে পরিবর্তন।
   • দীর্ঘক্ষণ ধরে চলা কাজ, যেমন নেভিগেশন বা গান শোনা।
2. নিম্নলিখিত ডিবাগিং টুলগুলি ব্যবহার করে পূর্ববর্তী ফ্লো চলাকালীন কী ঘটছে তা পরীক্ষা করুন:
   • পারফেটটো : এর মাধ্যমে আপনি নির্ভুল টাইমিং ডেটার সাহায্যে পুরো ডিভাইস জুড়ে কী ঘটছে তা দেখতে পারবেন।
   • মেমরি প্রোফাইলার : এর মাধ্যমে আপনি দেখতে পারবেন হিপ-এ কী ধরনের মেমরি অ্যালোকেশন হচ্ছে।
   • সিম্পলপার্ফ (Simpleperf ): একটি নির্দিষ্ট সময়কালে কোন ফাংশন কলগুলো সবচেয়ে বেশি সিপিইউ ব্যবহার করছে, তার একটি ফ্লেমগ্রাফ দেখায়। যখন আপনি সিস্ট্রেস (Systrace)-এ এমন কিছু শনাক্ত করেন যা দীর্ঘ সময় নিচ্ছে, কিন্তু তার কারণ জানেন না, তখন সিম্পলপার্ফ অতিরিক্ত তথ্য সরবরাহ করতে পারে।

এই পারফরম্যান্স সমস্যাগুলো বুঝতে ও ডিবাগ করতে, প্রতিটি টেস্ট রান ম্যানুয়ালি ডিবাগ করা অত্যন্ত জরুরি। সমষ্টিগত ডেটা বিশ্লেষণ করে পূর্ববর্তী ধাপগুলোকে প্রতিস্থাপন করা যায় না। তবে, ব্যবহারকারীরা আসলে কী দেখছেন তা বুঝতে এবং কখন রিগ্রেশন ঘটতে পারে তা শনাক্ত করতে, অটোমেটেড টেস্টিং এবং ফিল্ডে মেট্রিক্স সংগ্রহের ব্যবস্থা করা গুরুত্বপূর্ণ।

• স্টার্টআপ প্রবাহ
  • ফিল্ড মেট্রিক্স: প্লে কনসোল চালু হওয়ার সময়
  • ল্যাব পরীক্ষা: ম্যাক্রোবেঞ্চমার্ক দিয়ে স্টার্টআপ পরীক্ষা করুন
• জ্যাঙ্ক
  • ফিল্ড মেট্রিক্স
    • প্লে কনসোল ফ্রেম ভাইটালস: প্লে কনসোলের মধ্যে, আপনি কোনো নির্দিষ্ট ইউজার জার্নির মেট্রিক্সকে সংকুচিত করতে পারবেন না। এটি কেবল পুরো অ্যাপ জুড়ে সামগ্রিক জ্যাঙ্কের রিপোর্ট করে।
    • FrameMetricsAggregator মাধ্যমে কাস্টম পরিমাপ: আপনি একটি নির্দিষ্ট ওয়ার্কফ্লো চলাকালীন জ্যাঙ্ক মেট্রিক্স রেকর্ড করতে FrameMetricsAggregator ব্যবহার করতে পারেন।
  • ল্যাব পরীক্ষা
    • ম্যাক্রোবেঞ্চমার্ক দিয়ে স্ক্রোল করা হচ্ছে ।
    • ম্যাক্রোবেঞ্চমার্ক ` dumpsys gfxinfo কমান্ড ব্যবহার করে একটি নির্দিষ্ট ইউজার জার্নির মধ্যে ফ্রেম টাইমিং সংগ্রহ করে। এটি একটি নির্দিষ্ট ইউজার জার্নি জুড়ে জ্যাঙ্কের তারতম্য বোঝার একটি উপায়। রিগ্রেশন বা উন্নতি শনাক্ত করার জন্য, ফ্রেম আঁকতে কতক্ষণ সময় লাগছে তা তুলে ধরে এমন RenderTime মেট্রিকগুলো জ্যাঙ্কি ফ্রেমের সংখ্যার চেয়ে বেশি গুরুত্বপূর্ণ।

অ্যাপ লিঙ্ক যাচাইকরণ সমস্যা

অ্যাপ লিঙ্ক হলো আপনার ওয়েবসাইটের ইউআরএল-এর উপর ভিত্তি করে তৈরি ডিপ লিঙ্ক, যা যাচাই করে নিশ্চিত করা হয় যে এগুলো আপনার ওয়েবসাইটেরই অংশ। নিচে এমন কিছু কারণ উল্লেখ করা হলো, যার ফলে অ্যাপ লিঙ্ক যাচাইকরণ ব্যর্থ হতে পারে।

• ইনটেন্ট ফিল্টার স্কোপ: শুধুমাত্র সেইসব URL-এর ইনটেন্ট ফিল্টারে autoVerify যোগ করুন, যেগুলোতে আপনার অ্যাপ সাড়া দিতে পারে।
• যাচাইবিহীন প্রোটোকল সুইচ: যাচাইবিহীন সার্ভার-সাইড এবং সাবডোমেইন রিডাইরেক্টগুলোকে নিরাপত্তা ঝুঁকি হিসেবে বিবেচনা করা হয় এবং এগুলো ভেরিফিকেশনে ব্যর্থ হয়। এগুলোর কারণে সমস্ত autoVerify লিঙ্ক ব্যর্থ হয়ে যায়। উদাহরণস্বরূপ, HTTPS লিঙ্কগুলো যাচাই না করে HTTP থেকে HTTPS-এ (যেমন example.com থেকে www.example.com) লিঙ্ক রিডাইরেক্ট করলে ভেরিফিকেশন ব্যর্থ হতে পারে। ইন্টেন্ট ফিল্টার যোগ করে অ্যাপ লিঙ্কগুলো যাচাই করে নেওয়া নিশ্চিত করুন।
• যাচাই-অযোগ্য লিঙ্ক: পরীক্ষার উদ্দেশ্যে যাচাই-অযোগ্য লিঙ্ক যোগ করলে সিস্টেম আপনার অ্যাপের জন্য অ্যাপ লিঙ্কগুলো যাচাই নাও করতে পারে।
• অনির্ভরযোগ্য সার্ভার: নিশ্চিত করুন যে আপনার সার্ভারগুলো আপনার ক্লায়েন্ট অ্যাপগুলোর সাথে সংযোগ স্থাপন করতে পারে।

পারফরম্যান্স বিশ্লেষণের জন্য আপনার অ্যাপ সেট আপ করুন।

একটি অ্যাপ থেকে নির্ভুল, পুনরাবৃত্তিযোগ্য এবং কার্যকর বেঞ্চমার্ক পেতে সঠিকভাবে সেটআপ করা অপরিহার্য। যতটা সম্ভব প্রোডাকশন সিস্টেমের কাছাকাছি একটি সিস্টেমে পরীক্ষা করুন এবং নয়েজের উৎসগুলো দমন করুন। নিম্নলিখিত বিভাগগুলিতে একটি টেস্ট সেটআপ প্রস্তুত করার জন্য আপনি নিতে পারেন এমন বেশ কিছু APK- এবং সিস্টেম-নির্দিষ্ট পদক্ষেপ দেখানো হয়েছে, যার মধ্যে কিছু ব্যবহার-ক্ষেত্র-ভিত্তিক।

ট্রেসপয়েন্ট

অ্যাপগুলো তাদের কোডে কাস্টম ট্রেস ইভেন্ট যুক্ত করতে পারে।

ট্রেস ক্যাপচার করার সময়, প্রতিটি সেকশনের জন্য প্রায় ৫ মাইক্রোসেকেন্ডের একটি সামান্য ওভারহেড তৈরি হয়, তাই প্রতিটি মেথডের চারপাশে এটি ব্যবহার করবেন না। ০.১ মিলিসেকেন্ডের বেশি দৈর্ঘ্যের কাজের বড় অংশ ট্রেস করলে বাধা বা বটলনেক সম্পর্কে গুরুত্বপূর্ণ ধারণা পাওয়া যেতে পারে।

APK বিবেচ্য বিষয়

ডিবাগ ভ্যারিয়েন্টগুলো সমস্যা সমাধান এবং স্ট্যাক স্যাম্পল সিম্বোলাইজ করার জন্য সহায়ক হতে পারে, কিন্তু এগুলোর পারফরম্যান্সের উপর মারাত্মক প্রভাব রয়েছে। অ্যান্ড্রয়েড ১০ (এপিআই লেভেল ২৯) এবং এর চেয়ে উন্নত সংস্করণে চালিত ডিভাইসগুলো রিলিজ বিল্ডে প্রোফাইলিং চালু করার জন্য তাদের ম্যানিফেস্টে profileable android:shell="true" ব্যবহার করতে পারে।

আপনার প্রোডাকশন-গ্রেড কোড সঙ্কুচিত করার কনফিগারেশন ব্যবহার করুন। আপনার অ্যাপ যে রিসোর্সগুলো ব্যবহার করে, তার উপর নির্ভর করে এটি পারফরম্যান্সের উপর একটি উল্লেখযোগ্য প্রভাব ফেলতে পারে। কিছু ProGuard কনফিগারেশন ট্রেসপয়েন্ট মুছে ফেলে, তাই যে কনফিগারেশনে আপনি পরীক্ষা চালাচ্ছেন, তার জন্য সেই নিয়মগুলো সরিয়ে ফেলার কথা বিবেচনা করুন।

সংকলন

আপনার অ্যাপটিকে ডিভাইসেই একটি পরিচিত অবস্থায় কম্পাইল করুন —সাধারণত সহজতার জন্য speed , অথবা প্রোডাকশন পারফরম্যান্সের সাথে আরও ঘনিষ্ঠভাবে মেলানোর জন্য speed-profile (যদিও এর জন্য অ্যাপ্লিকেশনটি ওয়ার্ম আপ করা এবং প্রোফাইল ডাম্প করা, অথবা অ্যাপটির বেসলাইন প্রোফাইল কম্পাইল করার প্রয়োজন হয়)।

speed এবং speed-profile উভয়ই ডেক্স থেকে ইন্টারপ্রেট করা কোডের চলমান পরিমাণ হ্রাস করে, এবং ফলস্বরূপ ব্যাকগ্রাউন্ড জাস্ট-ইন-টাইম (JIT) কম্পাইলেশনের পরিমাণও কমায়, যা উল্লেখযোগ্য হস্তক্ষেপের কারণ হতে পারে। শুধুমাত্র speed-profile ডেক্স থেকে রানটাইম ক্লাস লোডিংয়ের প্রভাব কমায়।

নিম্নলিখিত কমান্ডটি speed মোড ব্যবহার করে অ্যাপ্লিকেশনটি কম্পাইল করে:

adb shell cmd package compile -m speed -f com.example.packagename

speed কম্পাইলেশন মোড অ্যাপের মেথডগুলোকে সম্পূর্ণরূপে কম্পাইল করে। speed-profile মোড অ্যাপ ব্যবহারের সময় সংগৃহীত ব্যবহৃত কোড পাথের একটি প্রোফাইল অনুসারে অ্যাপের মেথড এবং ক্লাসগুলোকে কম্পাইল করে। ধারাবাহিকভাবে এবং সঠিকভাবে প্রোফাইল সংগ্রহ করা কঠিন হতে পারে, তাই আপনি যদি এগুলো ব্যবহার করার সিদ্ধান্ত নেন, তবে নিশ্চিত হয়ে নিন যে এগুলো আপনার প্রত্যাশা অনুযায়ীই তথ্য সংগ্রহ করছে। প্রোফাইলগুলো নিম্নলিখিত স্থানে অবস্থিত:

/data/misc/profiles/ref/[package-name]/primary.prof

সিস্টেম বিবেচনা

নিম্ন-স্তরের এবং উচ্চ নির্ভুল পরিমাপের জন্য, আপনার ডিভাইসগুলো ক্যালিব্রেট করুন। একই ডিভাইস এবং একই ওএস সংস্করণের মধ্যে এ/বি তুলনা চালান। এমনকি একই ধরনের ডিভাইসের মধ্যেও পারফরম্যান্সে উল্লেখযোগ্য পার্থক্য থাকতে পারে।

রুটেড ডিভাইসে মাইক্রোবেঞ্চমার্কের জন্য একটি lockClocks স্ক্রিপ্ট ব্যবহার করার কথা বিবেচনা করতে পারেন। অন্যান্য কাজের পাশাপাশি, এই স্ক্রিপ্টগুলো নিম্নলিখিত কাজগুলো করে থাকে:

• সিপিইউগুলোকে একটি নির্দিষ্ট ফ্রিকোয়েন্সিতে রাখুন।
• স্মল কোরগুলো নিষ্ক্রিয় করুন এবং জিপিইউ কনফিগার করুন।
• থার্মাল থ্রটলিং নিষ্ক্রিয় করুন।

আমরা অ্যাপ লঞ্চ, DoU টেস্টিং এবং জ্যাঙ্ক টেস্টিং-এর মতো ইউজার-এক্সপেরিয়েন্স কেন্দ্রিক টেস্টের জন্য lockClocks স্ক্রিপ্ট ব্যবহার করার পরামর্শ দিই না, কিন্তু মাইক্রোবেঞ্চমার্ক টেস্টে নয়েজ কমানোর জন্য এটি অপরিহার্য হতে পারে।

সম্ভব হলে, ম্যাক্রোবেঞ্চমার্কের মতো একটি টেস্টিং ফ্রেমওয়ার্ক ব্যবহার করার কথা বিবেচনা করুন, যা আপনার পরিমাপে থাকা নয়েজ কমাতে এবং পরিমাপের ভুলত্রুটি প্রতিরোধ করতে পারে।

অ্যাপ চালু হতে দেরি: অপ্রয়োজনীয় ট্রাম্পোলিন কার্যকলাপ

একটি ট্রাম্পোলিন অ্যাক্টিভিটি অপ্রয়োজনীয়ভাবে অ্যাপ চালু হওয়ার সময় বাড়িয়ে দিতে পারে, এবং আপনার অ্যাপ এমনটা করছে কিনা সে বিষয়ে সচেতন থাকা জরুরি। নিচের উদাহরণ ট্রেসটিতে যেমন দেখানো হয়েছে, প্রথম অ্যাক্টিভিটিটি কোনো ফ্রেম ড্র না করেই একটি activityStart এর ঠিক পরেই আরেকটি activityStart চালু হয়ে যায়।

চিত্র ১. ট্রাম্পোলিনের কার্যকলাপের একটি রেখাচিত্র।

এটি একটি নোটিফিকেশন এন্ট্রি পয়েন্ট এবং একটি সাধারণ অ্যাপ স্টার্টআপ এন্ট্রি পয়েন্ট, উভয় ক্ষেত্রেই ঘটতে পারে এবং প্রায়শই রিফ্যাক্টরিংয়ের মাধ্যমে এর সমাধান করা যায়। উদাহরণস্বরূপ, যদি আপনি অন্য কোনো অ্যাক্টিভিটি চলার আগে সেটআপ করার জন্য এই অ্যাক্টিভিটিটি ব্যবহার করেন, তবে এই কোডটিকে একটি পুনঃব্যবহারযোগ্য কম্পোনেন্ট বা লাইব্রেরিতে আলাদা করে নিন।

অপ্রয়োজনীয় বরাদ্দের কারণে ঘন ঘন জিসি (গার্বেজ কালেকশন) হচ্ছে

সিস্ট্রেইসে আপনি দেখতে পারেন যে গার্বেজ কালেকশন (GC) আপনার প্রত্যাশার চেয়ে বেশি ঘন ঘন হচ্ছে।

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

চিত্র ২. জিসি ঘটনাগুলোর মধ্যবর্তী স্থান দেখানো একটি রেখাচিত্র।

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

জ্যাঙ্কি ফ্রেম

গ্রাফিক্স পাইপলাইন তুলনামূলকভাবে জটিল, এবং একজন ব্যবহারকারী শেষ পর্যন্ত কোনো ফ্রেম ড্রপ হতে দেখবেন কিনা, তা নির্ধারণ করার ক্ষেত্রে কিছু সূক্ষ্ম পার্থক্য থাকতে পারে। কিছু ক্ষেত্রে, প্ল্যাটফর্মটি বাফারিং ব্যবহার করে একটি ফ্রেমকে "উদ্ধার" করতে পারে। তবে, আপনার অ্যাপের দৃষ্টিকোণ থেকে সমস্যাযুক্ত ফ্রেমগুলো শনাক্ত করার জন্য আপনি এই সূক্ষ্ম পার্থক্যের বেশিরভাগই উপেক্ষা করতে পারেন।

যখন অ্যাপের খুব কম পরিশ্রমে ফ্রেমগুলো আঁকা হয়, তখন একটি 60 FPS ডিভাইসে Choreographer.doFrame() ট্রেসপয়েন্টগুলো 16.7ms ব্যবধানে ঘটে:

চিত্র ৩. ঘন ঘন দ্রুত ফ্রেম দেখানো একটি ট্রেস।

আপনি যদি জুম আউট করে ট্রেসটির মধ্যে দিয়ে যান, তাহলে মাঝে মাঝে দেখবেন ফ্রেমগুলো সম্পূর্ণ হতে একটু বেশি সময় নিচ্ছে, কিন্তু তাতেও কোনো সমস্যা নেই, কারণ সেগুলো তাদের জন্য বরাদ্দকৃত ১৬.৭ মিলিসেকেন্ড সময়ের বেশি নিচ্ছে না।

চিত্র ৪। একটি ট্রেস, যেখানে পর্যায়ক্রমিক কাজের বিস্ফোরণসহ ঘন ঘন দ্রুত ফ্রেম দেখানো হয়েছে।

যখন আপনি এই নিয়মিত ছন্দে কোনো ব্যাঘাত দেখতে পান, তখন তাকে জ্যাঙ্কি ফ্রেম বলা হয়, যেমনটি চিত্র ৫-এ দেখানো হয়েছে:

চিত্র ৫. একটি ত্রুটিপূর্ণ ফ্রেম প্রদর্শনকারী ট্রেস।

আপনি এগুলো শনাক্ত করার অনুশীলন করতে পারেন।

চিত্র ৬। একটি ট্রেস যেখানে আরও বেশি জ্যাঙ্কি ফ্রেম দেখা যাচ্ছে।

কিছু ক্ষেত্রে, কোন ভিউগুলো ইনফ্লেট করা হচ্ছে বা RecyclerView কী করছে সে সম্পর্কে আরও তথ্যের জন্য আপনাকে একটি ট্রেসপয়েন্টে জুম করতে হতে পারে। অন্য ক্ষেত্রে, আপনাকে আরও গভীরভাবে পর্যবেক্ষণ করতে হতে পারে।

জ্যাঙ্কি ফ্রেম শনাক্ত করা এবং এর কারণ ডিবাগ করার বিষয়ে আরও তথ্যের জন্য, স্লো রেন্ডারিং দেখুন।

RecyclerView-এর সাধারণ ভুলগুলো

অপ্রয়োজনীয়ভাবে RecyclerView এর সম্পূর্ণ ব্যাকএন্ড ডেটা বাতিল করলে ফ্রেম রেন্ডারিং-এ দীর্ঘ সময় লাগতে পারে এবং জ্যাঙ্ক দেখা দিতে পারে। এর পরিবর্তে, আপডেট করার প্রয়োজন এমন ভিউ-এর সংখ্যা কমানোর জন্য, শুধুমাত্র পরিবর্তনশীল ডেটা বাতিল করুন।

ব্যয়বহুল notifyDatasetChanged() কল এড়ানোর উপায় জানতে 'Present dynamic data' দেখুন, কারণ এই কলগুলো কন্টেন্টকে সম্পূর্ণরূপে প্রতিস্থাপন না করে কেবল আপডেট করে।

আপনি যদি প্রতিটি নেস্টেড RecyclerView সঠিকভাবে সাপোর্ট না করেন, তাহলে ভেতরের RecyclerView প্রতিবার সম্পূর্ণ নতুন করে তৈরি হতে পারে। প্রতিটি নেস্টেড, ভেতরের RecyclerView জন্য একটি RecycledViewPool সেট করা আবশ্যক, যা প্রতিটি ভেতরের RecyclerView মধ্যে ভিউগুলোর পুনর্ব্যবহার নিশ্চিত করতে সাহায্য করে।

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

আপনার অ্যাপ ডিবাগ করুন

আপনার অ্যাপের পারফরম্যান্স ডিবাগ করার জন্য নিম্নলিখিত বিভিন্ন পদ্ধতি রয়েছে। সিস্টেম ট্রেসিং এবং অ্যান্ড্রয়েড স্টুডিও প্রোফাইলার ব্যবহারের একটি সার্বিক ধারণা পেতে নিম্নলিখিত ভিডিওটি দেখুন।

Systrace ব্যবহার করে অ্যাপ স্টার্টআপ ডিবাগ করুন

অ্যাপ চালু হওয়ার প্রক্রিয়া সম্পর্কে একটি সার্বিক ধারণা পেতে 'অ্যাপ চালু হওয়ার সময়' দেখুন, এবং সিস্টেম ট্রেসিং সম্পর্কে একটি সার্বিক ধারণা পেতে নিম্নলিখিত ভিডিওটি দেখুন।

আপনি নিম্নলিখিত পর্যায়গুলিতে স্টার্টআপের ধরণগুলি স্পষ্ট করতে পারেন:

• কোল্ড স্টার্টআপ: কোনো সংরক্ষিত অবস্থা ছাড়াই একটি নতুন প্রসেস তৈরি করার মাধ্যমে শুরু হয়।
• ওয়ার্ম স্টার্টআপ: হয় প্রসেসটি পুনরায় ব্যবহার করার সময় অ্যাক্টিভিটিটি পুনরায় তৈরি করে, অথবা সংরক্ষিত অবস্থা সহ প্রসেসটি পুনরায় তৈরি করে।
• হট স্টার্টআপ: কার্যক্রমটি পুনরায় শুরু করে এবং মুদ্রাস্ফীতির সাথে সাথে চালু হয়।

আমরা ডিভাইসে সিস্টেম ট্রেসিং অ্যাপ ব্যবহার করে সিস্ট্রেস ক্যাপচার করার পরামর্শ দিই। অ্যান্ড্রয়েড ১০ এবং তার উপরের সংস্করণের জন্য, পারফেটটো (Perfetto ) ব্যবহার করুন। অ্যান্ড্রয়েড ৯ এবং তার নিচের সংস্করণের জন্য, সিস্ট্রেস (Systrace ) ব্যবহার করুন। আমরা ওয়েব-ভিত্তিক পারফেটটো ট্রেস ভিউয়ার দিয়ে ট্রেস ফাইলগুলো দেখারও পরামর্শ দিই। আরও তথ্যের জন্য, সিস্টেম ট্রেসিং-এর ওভারভিউ দেখুন।

লক্ষ্য করার মতো কিছু বিষয় নিচে উল্লেখ করা হলো:

• মনিটর নিয়ে দ্বন্দ্ব: মনিটর-সুরক্ষিত রিসোর্সের জন্য প্রতিযোগিতা অ্যাপ চালু হতে উল্লেখযোগ্য বিলম্ব ঘটাতে পারে।

• সিঙ্ক্রোনাস বাইন্ডার ট্রানজ্যাকশন: আপনার অ্যাপের ক্রিটিক্যাল পাথে অপ্রয়োজনীয় ট্রানজ্যাকশনগুলো খুঁজে বের করুন। যদি কোনো প্রয়োজনীয় ট্রানজ্যাকশন ব্যয়বহুল হয়, তবে সেটির উন্নতি সাধনের জন্য সংশ্লিষ্ট প্ল্যাটফর্ম টিমের সাথে কাজ করার কথা বিবেচনা করুন।

• কনকারেন্ট জিসি: এটি একটি সাধারণ বিষয় এবং এর প্রভাব তুলনামূলকভাবে কম, কিন্তু আপনি যদি প্রায়শই এর সম্মুখীন হন, তবে অ্যান্ড্রয়েড স্টুডিও মেমোরি প্রোফাইলার দিয়ে বিষয়টি খতিয়ে দেখতে পারেন।

• ইনপুট/আউটপুট (I/O): স্টার্টআপের সময় সম্পাদিত ইনপুট/আউটপুট পরীক্ষা করুন এবং দীর্ঘ স্টল (stall) সন্ধান করুন।

• অন্যান্য থ্রেডে উল্লেখযোগ্য কার্যকলাপ: এগুলি UI থ্রেডের কাজে হস্তক্ষেপ করতে পারে, তাই স্টার্টআপের সময় ব্যাকগ্রাউন্ডের কাজের দিকে নজর রাখুন।

অ্যাপের স্টার্টআপ মেট্রিক রিপোর্টিং উন্নত করার জন্য, অ্যাপের দৃষ্টিকোণ থেকে স্টার্টআপ সম্পন্ন হলে reportFullyDrawn কল করার পরামর্শ দেওয়া হয়। reportFullyDrawn ব্যবহারের বিষয়ে আরও তথ্যের জন্য 'Time to full display' বিভাগটি দেখুন। আপনি Perfetto ট্রেস প্রসেসরের মাধ্যমে RFD-দ্বারা সংজ্ঞায়িত শুরুর সময়গুলো বের করতে পারেন এবং একটি ব্যবহারকারী-দৃশ্যমান ট্রেস ইভেন্ট নির্গত হয়।

ডিভাইসে সিস্টেম ট্রেসিং ব্যবহার করুন

আপনি কোনো ডিভাইসে সিস্টেম ট্রেস ক্যাপচার করতে সিস্টেম ট্রেসিং নামক সিস্টেম-লেভেল অ্যাপটি ব্যবহার করতে পারেন। এই অ্যাপটি আপনাকে ডিভাইসটি প্লাগ ইন না করেই বা adb এর সাথে সংযুক্ত না করেই ট্রেস রেকর্ড করতে দেয়।

অ্যান্ড্রয়েড স্টুডিও মেমরি প্রোফাইলার ব্যবহার করুন

মেমরি লিক বা ত্রুটিপূর্ণ ব্যবহারের ধরনের কারণে সৃষ্ট মেমরির চাপ পরীক্ষা করার জন্য আপনি অ্যান্ড্রয়েড স্টুডিও মেমরি প্রোফাইলার ব্যবহার করতে পারেন। এটি অবজেক্ট অ্যালোকেশনের একটি লাইভ চিত্র প্রদান করে।

মেমরি প্রোফাইলার ব্যবহার করে কেন এবং কত ঘন ঘন গারবেজ কালেকশন (GC) হয়, সেই তথ্য অনুসরণ করে আপনি আপনার অ্যাপের মেমরি সমস্যা সমাধান করতে পারেন।

অ্যাপ মেমরির প্রোফাইল তৈরি করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. স্মৃতিশক্তির সমস্যা শনাক্ত করুন।

   আপনি যে ইউজার জার্নির উপর মনোযোগ দিতে চান, তার একটি মেমোরি প্রোফাইলিং সেশন রেকর্ড করুন। চিত্র ৭-এ দেখানো ক্রমবর্ধমান অবজেক্ট সংখ্যার সন্ধান করুন, যা অবশেষে চিত্র ৮-এ দেখানো অনুযায়ী GC-এর দিকে পরিচালিত করে।

   চিত্র ৭. বস্তুর সংখ্যা বৃদ্ধি।

   চিত্র ৮. আবর্জনা সংগ্রহ।

   যে ইউজার জার্নিটি মেমোরির উপর চাপ সৃষ্টি করছে, তা শনাক্ত করার পর সেই চাপের মূল কারণগুলো বিশ্লেষণ করুন।

2. স্মৃতিশক্তির উপর চাপের হট স্পটগুলো নির্ণয় করুন।

   চিত্র ৯-এ দেখানো অনুযায়ী, অ্যালোকেশন এবং শ্যালো সাইজ উভয়ই দেখার জন্য টাইমলাইনে একটি পরিসর নির্বাচন করুন।

   চিত্র ৯। বরাদ্দ এবং অগভীর আকারের মানসমূহ।

   এই ডেটা সাজানোর একাধিক উপায় আছে। প্রতিটি ভিউ কীভাবে আপনাকে সমস্যা বিশ্লেষণে সাহায্য করতে পারে, তার কিছু উদাহরণ নিচে দেওয়া হলো।

   • ক্লাস অনুযায়ী সাজান : এটি তখন কাজে লাগে যখন আপনি এমন ক্লাসগুলি খুঁজে বের করতে চান যেগুলি এমন অবজেক্ট তৈরি করছে যা অন্যথায় ক্যাশ করা থাকে বা মেমরি পুল থেকে পুনরায় ব্যবহার করা হয়।

     উদাহরণস্বরূপ, যদি আপনি দেখেন যে একটি অ্যাপ প্রতি সেকেন্ডে "Vertex" নামক ক্লাসের ২,০০০টি অবজেক্ট তৈরি করছে, তাহলে এটি প্রতি সেকেন্ডে অ্যালোকেশন সংখ্যা ২,০০০ করে বাড়িয়ে দেয় এবং ক্লাস অনুযায়ী সাজানোর সময় আপনি এটি দেখতে পান। গার্বেজ তৈরি হওয়া এড়াতে আপনি যদি এই অবজেক্টগুলো পুনরায় ব্যবহার করতে চান, তাহলে একটি মেমরি পুল প্রয়োগ করুন।

   • কলস্ট্যাক অনুসারে সাজান : এটি তখন কাজে লাগে যখন আপনি এমন কোনো হট পাথ খুঁজে বের করতে চান যেখানে মেমরি বরাদ্দ করা হচ্ছে, যেমন কোনো লুপের ভিতরে বা কোনো নির্দিষ্ট ফাংশনের ভিতরে যা প্রচুর পরিমাণে মেমরি বরাদ্দের কাজ করে।

   • শ্যালো সাইজ : শুধুমাত্র অবজেক্টটির নিজস্ব মেমরি ট্র্যাক করে। এটি মূলত প্রিমিটিভ ভ্যালু দ্বারা গঠিত সাধারণ ক্লাস ট্র্যাক করার জন্য উপযোগী।

   • রিটেইনড সাইজ : এটি অবজেক্ট এবং শুধুমাত্র সেই অবজেক্ট দ্বারা ব্যবহৃত রেফারেন্সগুলোর জন্য মোট মেমরি দেখায়। জটিল অবজেক্টের কারণে মেমরির উপর চাপ ট্র্যাক করার জন্য এটি কার্যকর। এই মানটি পেতে, চিত্র ১০-এ দেখানো অনুযায়ী একটি সম্পূর্ণ মেমরি ডাম্প নিন এবং চিত্র ১১-এ দেখানো অনুযায়ী রিটেইনড সাইজ একটি কলাম হিসাবে যুক্ত হবে।

     চিত্র ১০। সম্পূর্ণ মেমরি ডাম্প।

     

3. অপ্টিমাইজেশনের প্রভাব পরিমাপ করুন।

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

   অপ্টিমাইজেশনের প্রভাব পরিমাপ করতে, প্রোফাইলার টাইমলাইনে GC-গুলোর মধ্যবর্তী সময় পরিমাপ করুন। তাহলেই আপনি দেখতে পাবেন যে GC-গুলোর মধ্যে আগের চেয়ে বেশি সময় লাগছে।

   স্মৃতিশক্তির উন্নতির চূড়ান্ত প্রভাবগুলো হলো নিম্নরূপ:

   • অ্যাপটি যদি ক্রমাগত মেমোরির চাপে না পড়ে, তাহলে মেমোরি শেষ হয়ে যাওয়ার কারণে বন্ধ হয়ে যাওয়ার সম্ভাবনা কমে যায়।
   • কম GC হলে জ্যাঙ্ক মেট্রিক্সের উন্নতি হয়, বিশেষ করে P99-এর ক্ষেত্রে। এর কারণ হলো, GC-এর ফলে CPU-তে প্রতিযোগিতা সৃষ্টি হয়, যার কারণে GC চলাকালীন রেন্ডারিং টাস্কগুলো স্থগিত হয়ে যেতে পারে।