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

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

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

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

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

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

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

• ৫০০ মিলিসেকেন্ডেরও কম সময়ে কোল্ড স্টার্ট। যখন চালু করা অ্যাপটি সিস্টেমের মেমরিতে উপস্থিত থাকে না, তখন একটি কোল্ড স্টার্ট হয়। রিবুট করার পর অথবা ব্যবহারকারী বা সিস্টেম দ্বারা অ্যাপ প্রসেসটি বন্ধ করার পর অ্যাপটি প্রথমবার চালু করার ক্ষেত্রে এটি ঘটে। একটি কোল্ড স্টার্টের জন্য সিস্টেমকে সবচেয়ে বেশি কাজ করতে হয়, কারণ এটিকে স্টোরেজ থেকে সবকিছু লোড করতে এবং অ্যাপটি ইনিশিয়ালাইজ করতে হয়। কোল্ড স্টার্ট যেন ৫০০ মিলিসেকেন্ড বা তার কম সময়ে সম্পন্ন হয়, তা নিশ্চিত করার চেষ্টা করুন।
• ২০০ মিলিসেকেন্ডের কম সময়ে ওয়ার্ম স্টার্ট এবং ১৫০ মিলিসেকেন্ডের কম সময়ে হট স্টার্ট। একটি ওয়ার্ম স্টার্ট ঘটে যখন অ্যাপ্লিকেশনটির প্রসেস আগে থেকেই ব্যাকগ্রাউন্ডে চলতে থাকে, কিন্তু সিস্টেমকে UI পুনরায় চালু করতে বা অ্যাক্টিভিটিটিকে ফোরগ্রাউন্ডে ফিরিয়ে আনতে হয়, যেমন যখন কোনো ব্যবহারকারী অ্যাপ থেকে বেরিয়ে যান এবং কিছুক্ষণ পরেই আবার খোলেন। একটি হট স্টার্ট আরও দ্রুত হয়, কারণ অ্যাপের অ্যাক্টিভিটি আগে থেকেই মেমরিতে ক্যাশ করা থাকে এবং ভিউ হায়ারার্কি পুনরায় তৈরি করার প্রয়োজন ছাড়াই এটিকে শুধুমাত্র ফোরগ্রাউন্ডে নিয়ে আসতে হয়। ওয়ার্ম স্টার্ট ২০০ মিলিসেকেন্ডের নিচে এবং হট স্টার্ট ১৫০ মিলিসেকেন্ডের নিচে রাখার লক্ষ্য রাখুন।
• P95 and P99 latencies very close to the median latency. P95 and P99 represent the 95th and 99th percentiles of startup times, while the median is the 50th percentile. When the app takes a long time to start, it makes a poor user experience. Interprocess communications (IPCs) and unnecessary I/O during the critical path of app startup can experience lock contention and introduce inconsistencies.

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

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

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

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

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

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

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

কাজ করলে ব্যাটারির চার্জ কমে যায় এবং ফলস্বরূপ এর আয়ুও হ্রাস পায়।

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

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

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

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

পারফরম্যান্স সংক্রান্ত সমস্যা সমাধানের জন্য, নিম্নলিখিত গুরুত্বপূর্ণ ইউজার জার্নিগুলো শনাক্ত ও পরিদর্শন করুন:

• লঞ্চার এবং নোটিফিকেশন সহ সাধারণ স্টার্টআপ ফ্লো।
• যেসব স্ক্রিনে ব্যবহারকারী ডেটা স্ক্রল করে দেখতে পারেন।
• স্ক্রিনগুলোর মধ্যে পরিবর্তন।
• দীর্ঘক্ষণ ধরে চলা কাজ, যেমন নেভিগেশন বা গান শোনা।

এই প্রতিটি ফ্লো-এর ক্ষেত্রে, নিম্নলিখিত ডিবাগিং টুলগুলো ব্যবহার করে কী ঘটছে তা খতিয়ে দেখুন:

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

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

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

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

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

• ইনটেন্ট ফিল্টারের স্কোপ ভুল: শুধুমাত্র সেইসব 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

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

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

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

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

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

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

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

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

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

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

দ্রষ্টব্য: অ্যাপের পারফরম্যান্স এবং ইউএক্স (UX) উন্নত করার জন্য, অ্যান্ড্রয়েড ১২ বা তার উচ্চতর সংস্করণকে লক্ষ্য করে তৈরি অ্যাপগুলো সার্ভিস বা ব্রডকাস্ট রিসিভার থেকে অ্যাক্টিভিটি শুরু করতে পারবে না, যেগুলো কোনো অ্যাক্টিভিটিতে প্রবেশের জন্য ট্রাম্পোলিন হিসেবে ব্যবহৃত হয়।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

কিছু ক্ষেত্রে, Compose দ্বারা কোন UI কম্পোনেন্টগুলো আপডেট করা হচ্ছে অথবা, চিত্র ৬-এর মতো, একটি LazyColumn কী করছে, সে সম্পর্কে আরও তথ্যের জন্য আপনাকে একটি ট্রেসপয়েন্ট জুম করতে হতে পারে। এই UI বাধাগুলো নির্ণয় করার সময়, সাধারণ সিস্টেম ট্রেসিং হয়তো দেখাতে পারে না যে কোন কম্পোজেবলগুলো এর মূল কারণ। এই পরিস্থিতিতে, Jetpack Compose কম্পোজিশন ট্রেসিং ব্যবহার করুন, যা সরাসরি ট্রেসের মধ্যেই সুনির্দিষ্ট কম্পোজেবল ফাংশনগুলো তুলে ধরে, ফলে অপ্রত্যাশিত পুনর্গঠনগুলো চিহ্নিত করা সহজ হয়। চিত্র ৫ এবং ৬ কম্পোজিশন ট্রেসিং-এর ফলাফল দেখাচ্ছে।

Compose-এর পারফরম্যান্স অপ্টিমাইজ করার বিষয়ে আরও তথ্যের জন্য, Jetpack Compose Performance দেখুন। জ্যাঙ্কি ফ্রেম শনাক্ত করা এবং সেগুলোর কারণ ডিবাগ করার বিষয়ে আরও তথ্যের জন্য, Slow rendering দেখুন।

অলস লেআউটের সাধারণ ভুলগুলো

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

ব্যয়বহুল পূর্ণ-তালিকা পুনঃবন্টন এড়ানোর উপায় জানতে ‘Use lazy layout keys’ দেখুন, যার ফলে কন্টেন্ট সম্পূর্ণরূপে প্রতিস্থাপন না করে কেবল আপডেট হয়।

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

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

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

আপনার অ্যাপের পারফরম্যান্স ডিবাগ করার পদ্ধতিগুলো নিচে দেওয়া হলো।

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

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

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

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

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

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

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

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

  পরামর্শ: এই কলগুলো সম্পর্কে আরও তথ্য পেতে আপনি am trace-ipc start ব্যবহার করতে পারেন। বেঞ্চমার্কিং পুনরায় শুরু করার আগে এটি নিষ্ক্রিয় করুন, কারণ এর উল্লেখযোগ্য ওভারহেড রয়েছে এবং অন্যথায় এটি ডিভাইস পুনরায় চালু না হওয়া পর্যন্ত চলতে থাকে।

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

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

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

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

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

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

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

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

আপনার অ্যাপের মেমোরি প্রোফাইলার ব্যবহার করে কেন এবং কত ঘন ঘন গারবেজ কালেকশন (GC) হচ্ছে তা ট্র্যাক করার মাধ্যমে আপনি মেমোরি সমস্যার সমাধান করতে পারেন।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

     চিত্র ১১। সংরক্ষিত আকারের কলাম।

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

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

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

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

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

{% হুবহু %} {% endverbatim %}