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

এই দস্তাবেজটি আপনাকে আপনার অ্যাপের মূল কর্মক্ষমতা সমস্যাগুলি সনাক্ত করতে এবং ঠিক করতে সাহায্য করে৷

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

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

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

স্টার্টআপ লেটেন্সি হল অ্যাপ আইকনে ট্যাপ করা, বিজ্ঞপ্তি বা অন্যান্য এন্ট্রি পয়েন্ট এবং স্ক্রিনে ব্যবহারকারীর ডেটা দেখানোর মধ্যে যে পরিমাণ সময় লাগে।

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

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

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

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

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

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

অ্যাপগুলিকে অবশ্যই 90Hz রিফ্রেশ রেট লক্ষ্য করতে হবে। প্রচলিত রেন্ডারিং রেট 60Hz, কিন্তু অনেক নতুন ডিভাইস ব্যবহারকারীর ইন্টারঅ্যাকশনের সময় 90Hz মোডে কাজ করে, যেমন স্ক্রোলিং। কিছু ডিভাইস 120Hz পর্যন্ত উচ্চ হার সমর্থন করে।

একটি নির্দিষ্ট সময়ে একটি ডিভাইস কী রিফ্রেশ রেট ব্যবহার করছে তা দেখতে, বিকাশকারী বিকল্পগুলি ব্যবহার করে একটি ওভারলে সক্ষম করুন > ডিবাগিং বিভাগে রিফ্রেশ হার দেখান৷

রূপান্তর যা মসৃণ নয়

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

শক্তির অদক্ষতা

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

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

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

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

পারফরম্যান্সের সমস্যা চিহ্নিত করতে এবং প্রতিকার করতে আমরা নিম্নলিখিত ওয়ার্কফ্লো সুপারিশ করেছি:

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

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

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

অ্যাপ লিঙ্কগুলি হল আপনার ওয়েবসাইটের URL এর উপর ভিত্তি করে গভীর লিঙ্ক যা আপনার ওয়েবসাইটের অন্তর্গত বলে যাচাই করা হয়েছে। নিম্নলিখিত কারণগুলি অ্যাপ লিঙ্ক যাচাইকরণ ব্যর্থ হতে পারে৷

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

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

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

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

অ্যাপগুলি কাস্টম ট্রেস ইভেন্টগুলির সাথে তাদের কোডকে উপকরণ করতে পারে৷

ট্রেস ক্যাপচার করার সময়, ট্রেসিং প্রতি বিভাগে মোটামুটি 5μs এর একটি ছোট ওভারহেড বহন করে, তাই প্রতিটি পদ্ধতিতে এটি রাখবেন না। 0.1ms>র কাজের বৃহত্তর অংশগুলিকে ট্রেস করা বাধাগুলির মধ্যে উল্লেখযোগ্য অন্তর্দৃষ্টি দিতে পারে।

APK বিবেচনা

ডিবাগ ভেরিয়েন্টগুলি সমস্যা সমাধান এবং স্ট্যাকের নমুনার প্রতীকীকরণের জন্য সহায়ক হতে পারে, তবে তাদের কার্যকারিতার উপর গুরুতর প্রভাব রয়েছে। Android 10 (API লেভেল 29) এবং উচ্চতর ডিভাইসগুলি রিলিজ বিল্ডগুলিতে প্রোফাইলিং সক্ষম করতে তাদের ম্যানিফেস্টে 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 স্ক্রিপ্ট ব্যবহার করার কথা বিবেচনা করুন। অন্যান্য জিনিসগুলির মধ্যে, এই স্ক্রিপ্টগুলি নিম্নলিখিতগুলি করে:

  • একটি নির্দিষ্ট ফ্রিকোয়েন্সিতে CPU গুলি রাখুন।
  • ছোট কোর অক্ষম করুন এবং GPU কনফিগার করুন।
  • থার্মাল থ্রটলিং অক্ষম করুন।

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

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

স্লো অ্যাপ স্টার্টআপ: অপ্রয়োজনীয় ট্রামপোলিন কার্যকলাপ

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

alt_text চিত্র 1. ট্রামপোলিন কার্যকলাপ দেখানো একটি ট্রেস।

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

অপ্রয়োজনীয় বরাদ্দ ঘন ঘন GC ট্রিগার

আপনি দেখতে পারেন যে আবর্জনা সংগ্রহ (GCs) আপনি একটি Systrace এ প্রত্যাশার চেয়ে বেশি ঘন ঘন ঘটছে।

নিম্নলিখিত উদাহরণে, একটি দীর্ঘ-চলমান অপারেশন চলাকালীন প্রতি 10 সেকেন্ডে একটি সূচক যে অ্যাপটি অপ্রয়োজনীয়ভাবে কিন্তু ধারাবাহিকভাবে সময়ের সাথে বরাদ্দ করতে পারে:

alt_text চিত্র 2. GC ইভেন্টগুলির মধ্যে স্থান দেখানো একটি ট্রেস।

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

জাঙ্কি ফ্রেম

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

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

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

আপনি যদি জুম আউট করেন এবং ট্রেসের মাধ্যমে নেভিগেট করেন, আপনি কখনও কখনও দেখেন ফ্রেমগুলি সম্পূর্ণ হতে একটু বেশি সময় নেয়, তবে এটি এখনও ঠিক আছে কারণ তারা তাদের বরাদ্দকৃত 16.7ms সময়ের চেয়ে বেশি সময় নিচ্ছে না:

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

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

alt_text চিত্র 5. একটি জাঙ্কি ফ্রেম দেখানো একটি ট্রেস।

আপনি তাদের চিহ্নিত করার অনুশীলন করতে পারেন।

alt_text চিত্র 6. একটি ট্রেস আরও জ্যাঙ্কি ফ্রেম দেখাচ্ছে।

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

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

সাধারণ RecyclerView ভুল

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

ব্যয়বহুল notifyDatasetChanged() কলগুলি এড়ানোর উপায়গুলির জন্য বর্তমান গতিশীল ডেটা দেখুন, যার ফলে বিষয়বস্তু সম্পূর্ণরূপে প্রতিস্থাপনের পরিবর্তে আপডেট হয়৷

আপনি যদি প্রতিটি নেস্টেড RecyclerView সঠিকভাবে সমর্থন না করেন তবে এটি প্রতিবার অভ্যন্তরীণ RecyclerView সম্পূর্ণরূপে পুনরায় তৈরি করতে পারে। প্রতিটি নেস্টেড, অভ্যন্তরীণ RecyclerView অবশ্যই একটি RecycledViewPool সেট থাকতে হবে যাতে প্রতিটি অভ্যন্তরীণ RecyclerView মধ্যে ভিউ পুনর্ব্যবহার করা যায়।

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

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

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

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

অ্যাপ স্টার্টআপ প্রক্রিয়ার একটি সংক্ষিপ্ত বিবরণের জন্য অ্যাপ স্টার্টআপ সময় দেখুন এবং সিস্টেম ট্রেসিংয়ের ওভারভিউয়ের জন্য নিম্নলিখিত ভিডিওটি দেখুন।

আপনি নিম্নলিখিত পর্যায়ে স্টার্টআপ প্রকারগুলিকে দ্ব্যর্থহীন করতে পারেন:

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

আমরা ডিভাইসে সিস্টেম ট্রেসিং অ্যাপের মাধ্যমে সিস্ট্রেস ক্যাপচার করার পরামর্শ দিই। Android 10 এবং উচ্চতর সংস্করণের জন্য, Perfetto ব্যবহার করুন। অ্যান্ড্রয়েড 9 এবং তার নিচের জন্য, সিস্ট্রেস ব্যবহার করুন। আমরা ওয়েব-ভিত্তিক পারফেটো ট্রেস ভিউয়ারের সাথে ট্রেস ফাইলগুলি দেখারও সুপারিশ করি৷ আরও তথ্যের জন্য, সিস্টেম ট্রেসিংয়ের ওভারভিউ দেখুন।

কিছু জিনিস যা খুঁজতে হবে তার মধ্যে রয়েছে:

  • মনিটর বিতর্ক: মনিটর-সুরক্ষিত সংস্থানগুলির জন্য প্রতিযোগিতা অ্যাপ স্টার্টআপে উল্লেখযোগ্য বিলম্ব করতে পারে।

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

  • সমসাময়িক GC: এটি সাধারণ এবং তুলনামূলকভাবে কম প্রভাব, কিন্তু আপনি যদি প্রায়শই এটির সম্মুখীন হন, তাহলে Android Studio মেমরি প্রোফাইলার দিয়ে এটি দেখার কথা বিবেচনা করুন।

  • I/O: স্টার্টআপের সময় সম্পাদিত I/O পরীক্ষা করুন এবং দীর্ঘ স্টলগুলি দেখুন।

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

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

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

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

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

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

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

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

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

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

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

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

    মেমরির চাপ যোগ করা ব্যবহারকারীর যাত্রা শনাক্ত করার পরে, মেমরির চাপের মূল কারণগুলি বিশ্লেষণ করুন।

  2. মেমরি চাপ হট স্পট নির্ণয়.

    বরাদ্দ এবং অগভীর আকার উভয়ই কল্পনা করতে টাইমলাইনে একটি পরিসর নির্বাচন করুন, যেমন চিত্র 9 এ দেখানো হয়েছে।

    alt_text চিত্র 9. বরাদ্দ এবং অগভীর আকারের জন্য মান।

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

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

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

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

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

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

      alt_text চিত্র 10. সম্পূর্ণ মেমরি ডাম্প।

      রাখা মাপ কলাম.
      চিত্র 11. ধরে রাখা মাপ কলাম।

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

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

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

    মেমরির উন্নতির চূড়ান্ত প্রভাবগুলি নিম্নরূপ:

    • মেমরির বাইরে থাকা শাটডাউনগুলি সম্ভবত হ্রাস পাবে যদি অ্যাপটি ক্রমাগত মেমরির চাপে আঘাত না করে।
    • কম GC থাকা জ্যাঙ্ক মেট্রিক্সকে উন্নত করে, বিশেষ করে P99-এ। এর কারণ হল GC গুলি CPU বিরোধের কারণ হয়ে দাঁড়ায়, যা GC চলাকালীন রেন্ডারিং কাজগুলিকে পিছিয়ে দিতে পারে।
{% শব্দার্থে %} {% endverbatim %} {% শব্দার্থে %} {% endverbatim %} ,

এই দস্তাবেজটি আপনাকে আপনার অ্যাপের মূল কর্মক্ষমতা সমস্যাগুলি সনাক্ত করতে এবং ঠিক করতে সাহায্য করে৷

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

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

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

স্টার্টআপ লেটেন্সি হল অ্যাপ আইকনে ট্যাপ করা, বিজ্ঞপ্তি বা অন্যান্য এন্ট্রি পয়েন্ট এবং স্ক্রিনে ব্যবহারকারীর ডেটা দেখানোর মধ্যে যে পরিমাণ সময় লাগে।

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

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

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

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

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

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

অ্যাপগুলিকে অবশ্যই 90Hz রিফ্রেশ রেট লক্ষ্য করতে হবে। প্রচলিত রেন্ডারিং রেট 60Hz, কিন্তু অনেক নতুন ডিভাইস ব্যবহারকারীর ইন্টারঅ্যাকশনের সময় 90Hz মোডে কাজ করে, যেমন স্ক্রোলিং। কিছু ডিভাইস 120Hz পর্যন্ত উচ্চ হার সমর্থন করে।

একটি নির্দিষ্ট সময়ে একটি ডিভাইস কী রিফ্রেশ রেট ব্যবহার করছে তা দেখতে, বিকাশকারী বিকল্পগুলি ব্যবহার করে একটি ওভারলে সক্ষম করুন > ডিবাগিং বিভাগে রিফ্রেশ হার দেখান৷

রূপান্তর যা মসৃণ নয়

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

শক্তির অদক্ষতা

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

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

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

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

পারফরম্যান্সের সমস্যা চিহ্নিত করতে এবং প্রতিকার করতে আমরা নিম্নলিখিত ওয়ার্কফ্লো সুপারিশ করেছি:

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

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

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

অ্যাপ লিঙ্কগুলি হল আপনার ওয়েবসাইটের URL এর উপর ভিত্তি করে গভীর লিঙ্ক যা আপনার ওয়েবসাইটের অন্তর্গত বলে যাচাই করা হয়েছে। নিম্নলিখিত কারণগুলি অ্যাপ লিঙ্ক যাচাইকরণ ব্যর্থ হতে পারে৷

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

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

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

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

অ্যাপগুলি কাস্টম ট্রেস ইভেন্টগুলির সাথে তাদের কোডকে উপকরণ করতে পারে৷

ট্রেস ক্যাপচার করার সময়, ট্রেসিং প্রতি বিভাগে মোটামুটি 5μs এর একটি ছোট ওভারহেড বহন করে, তাই প্রতিটি পদ্ধতিতে এটি রাখবেন না। 0.1ms>র কাজের বৃহত্তর অংশগুলিকে ট্রেস করা বাধাগুলির মধ্যে উল্লেখযোগ্য অন্তর্দৃষ্টি দিতে পারে।

APK বিবেচনা

ডিবাগ ভেরিয়েন্টগুলি সমস্যা সমাধান এবং স্ট্যাকের নমুনার প্রতীকীকরণের জন্য সহায়ক হতে পারে, তবে তাদের কার্যকারিতার উপর গুরুতর প্রভাব রয়েছে। Android 10 (API লেভেল 29) এবং উচ্চতর ডিভাইসগুলি রিলিজ বিল্ডগুলিতে প্রোফাইলিং সক্ষম করতে তাদের ম্যানিফেস্টে 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 স্ক্রিপ্ট ব্যবহার করার কথা বিবেচনা করুন। অন্যান্য জিনিসগুলির মধ্যে, এই স্ক্রিপ্টগুলি নিম্নলিখিতগুলি করে:

  • একটি নির্দিষ্ট ফ্রিকোয়েন্সিতে CPU গুলি রাখুন।
  • ছোট কোর অক্ষম করুন এবং GPU কনফিগার করুন।
  • থার্মাল থ্রটলিং অক্ষম করুন।

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

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

স্লো অ্যাপ স্টার্টআপ: অপ্রয়োজনীয় ট্রামপোলিন কার্যকলাপ

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

alt_text চিত্র 1. ট্রামপোলিন কার্যকলাপ দেখানো একটি ট্রেস।

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

অপ্রয়োজনীয় বরাদ্দ ঘন ঘন GC ট্রিগার

আপনি দেখতে পারেন যে আবর্জনা সংগ্রহ (GCs) আপনি একটি Systrace এ প্রত্যাশার চেয়ে বেশি ঘন ঘন ঘটছে।

নিম্নলিখিত উদাহরণে, একটি দীর্ঘ-চলমান অপারেশন চলাকালীন প্রতি 10 সেকেন্ডে একটি সূচক যে অ্যাপটি অপ্রয়োজনীয়ভাবে কিন্তু ধারাবাহিকভাবে সময়ের সাথে বরাদ্দ করতে পারে:

alt_text চিত্র 2. GC ইভেন্টগুলির মধ্যে স্থান দেখানো একটি ট্রেস।

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

জাঙ্কি ফ্রেম

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

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

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

আপনি যদি জুম আউট করেন এবং ট্রেসের মাধ্যমে নেভিগেট করেন, আপনি কখনও কখনও দেখেন ফ্রেমগুলি সম্পূর্ণ হতে একটু বেশি সময় নেয়, তবে এটি এখনও ঠিক আছে কারণ তারা তাদের বরাদ্দকৃত 16.7ms সময়ের চেয়ে বেশি সময় নিচ্ছে না:

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

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

alt_text চিত্র 5. একটি জাঙ্কি ফ্রেম দেখানো একটি ট্রেস।

আপনি তাদের চিহ্নিত করার অনুশীলন করতে পারেন।

alt_text চিত্র 6. একটি ট্রেস আরও জ্যাঙ্কি ফ্রেম দেখাচ্ছে।

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

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

সাধারণ RecyclerView ভুল

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

ব্যয়বহুল notifyDatasetChanged() কলগুলি এড়ানোর উপায়গুলির জন্য বর্তমান গতিশীল ডেটা দেখুন, যার ফলে বিষয়বস্তু সম্পূর্ণরূপে প্রতিস্থাপনের পরিবর্তে আপডেট হয়৷

আপনি যদি প্রতিটি নেস্টেড RecyclerView সঠিকভাবে সমর্থন না করেন তবে এটি প্রতিবার অভ্যন্তরীণ RecyclerView সম্পূর্ণরূপে পুনরায় তৈরি করতে পারে। প্রতিটি নেস্টেড, অভ্যন্তরীণ RecyclerView অবশ্যই একটি RecycledViewPool সেট থাকতে হবে যাতে প্রতিটি অভ্যন্তরীণ RecyclerView মধ্যে ভিউ পুনর্ব্যবহার করা যায়।

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

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

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

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

অ্যাপ স্টার্টআপ প্রক্রিয়ার একটি সংক্ষিপ্ত বিবরণের জন্য অ্যাপ স্টার্টআপ সময় দেখুন এবং সিস্টেম ট্রেসিংয়ের ওভারভিউয়ের জন্য নিম্নলিখিত ভিডিওটি দেখুন।

আপনি নিম্নলিখিত পর্যায়ে স্টার্টআপ প্রকারগুলিকে দ্ব্যর্থহীন করতে পারেন:

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

আমরা ডিভাইসে সিস্টেম ট্রেসিং অ্যাপের মাধ্যমে সিস্ট্রেস ক্যাপচার করার পরামর্শ দিই। Android 10 এবং উচ্চতর সংস্করণের জন্য, Perfetto ব্যবহার করুন। অ্যান্ড্রয়েড 9 এবং তার নিচের জন্য, সিস্ট্রেস ব্যবহার করুন। আমরা ওয়েব-ভিত্তিক পারফেটো ট্রেস ভিউয়ারের সাথে ট্রেস ফাইলগুলি দেখারও সুপারিশ করি৷ আরও তথ্যের জন্য, সিস্টেম ট্রেসিংয়ের ওভারভিউ দেখুন।

কিছু জিনিস যা খুঁজতে হবে তার মধ্যে রয়েছে:

  • মনিটর বিতর্ক: মনিটর-সুরক্ষিত সংস্থানগুলির জন্য প্রতিযোগিতা অ্যাপ স্টার্টআপে উল্লেখযোগ্য বিলম্ব করতে পারে।

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

  • সমসাময়িক GC: এটি সাধারণ এবং তুলনামূলকভাবে কম প্রভাব, কিন্তু আপনি যদি প্রায়শই এটির সম্মুখীন হন, তাহলে Android Studio মেমরি প্রোফাইলার দিয়ে এটি দেখার কথা বিবেচনা করুন।

  • I/O: স্টার্টআপের সময় সম্পাদিত I/O পরীক্ষা করুন এবং দীর্ঘ স্টলগুলি দেখুন।

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

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

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

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

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

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

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

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

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

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

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

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

    মেমরির চাপ যোগ করা ব্যবহারকারীর যাত্রা শনাক্ত করার পরে, মেমরির চাপের মূল কারণগুলি বিশ্লেষণ করুন।

  2. মেমরি চাপ হট স্পট নির্ণয়.

    বরাদ্দ এবং অগভীর আকার উভয়ই কল্পনা করতে টাইমলাইনে একটি পরিসর নির্বাচন করুন, যেমন চিত্র 9 এ দেখানো হয়েছে।

    alt_text চিত্র 9. বরাদ্দ এবং অগভীর আকারের জন্য মান।

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

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

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

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

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

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

      alt_text চিত্র 10. সম্পূর্ণ মেমরি ডাম্প।

      রাখা মাপ কলাম.
      চিত্র 11. ধরে রাখা মাপ কলাম।

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

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

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

    মেমরির উন্নতির চূড়ান্ত প্রভাবগুলি নিম্নরূপ:

    • মেমরির বাইরে থাকা শাটডাউনগুলি সম্ভবত হ্রাস পাবে যদি অ্যাপটি ক্রমাগত মেমরির চাপে আঘাত না করে।
    • কম GC থাকা জ্যাঙ্ক মেট্রিক্সকে উন্নত করে, বিশেষ করে P99-এ। এর কারণ হল GC গুলি CPU বিরোধের কারণ হয়ে দাঁড়ায়, যা GC চলাকালীন রেন্ডারিং কাজগুলিকে পিছিয়ে দিতে পারে।
{% শব্দার্থে %} {% endverbatim %} {% শব্দার্থে %} {% endverbatim %}