অ্যাপ চালু করার সময়

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

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

অ্যাপ স্টার্টআপের বিভিন্ন স্ট্যাটাস সম্পর্কে বোঝা

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

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

দ্রুত স্টার্টআপের জন্য আপনার অ্যাপ অপ্টিমাইজ করতে, সিস্টেম এবং অ্যাপ লেভেলে কী ঘটছে এবং এই প্রতিটি স্টেটে তারা কীভাবে ইন্টার‍্যাক্ট করছে তা বোঝা দরকার।

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

কোল্ড স্টার্ট

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

এই ধরনের স্টার্টআপের ক্ষেত্রে স্টার্টআপের সময় কমানো সবচেয়ে কঠিন, কারণ অন্যান্য লঞ্চ স্টেটের তুলনায় সিস্টেম ও অ্যাপকে অনেক বেশি কাজ করতে হয়।

কোল্ড স্টার্টের শুরুতে, সিস্টেমের নিম্নলিখিত তিনটি কাজ থাকে:

1. অ্যাপ লোড ও লঞ্চ করুন।
2. অ্যাপ লঞ্চ করার সাথে সাথেই একটি ফাঁকা উইন্ডো দেখান।
3. অ্যাপ প্রসেস তৈরি করুন।

সিস্টেম অ্যাপ প্রসেস তৈরি করার সাথে সাথেই, পরবর্তী ধাপের জন্য অ্যাপ প্রসেস দায়িত্ব নেয়:

1. অ্যাপ অবজেক্ট তৈরি করুন।
2. মূল থ্রেড লঞ্চ করুন।
3. মূল অ্যাক্টিভিটি তৈরি করুন।
4. UI শুরু করুন।
5. স্ক্রিনে UI আঁকুন।

অ্যাপ প্রসেস প্রথম ড্র সম্পূর্ণ করলে, সিস্টেম প্রসেস ডিসপ্লে করা ব্যাকগ্রাউন্ড উইন্ডো সোয়াপ করে এবং মূল অ্যাক্টিভিটি দিয়ে এটি রিপ্লেস করে। এই সময়, ব্যবহারকারী অ্যাপ ব্যবহার করা শুরু করতে পারবেন।

Compose-এ লেআউট ফেজ সম্পর্কে আরও জানতে, Jetpack Compose ফেজ দেখুন।

অ্যাপ ও হোস্ট অ্যাক্টিভিটি তৈরি করার সময় পারফর্ম্যান্স সংক্রান্ত সমস্যা দেখা দিতে পারে।

অ্যাপ ক্রিয়েশন

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

আপনি নিজের অ্যাপে Application.onCreate ওভাররাইড করলে, সিস্টেম আপনার অ্যাপ অবজেক্টে onCreate পদ্ধতি চালু করে। এরপরে, অ্যাপটি মূল থ্রেড তৈরি করে, যা UI থ্রেড নামেও পরিচিত এবং আপনার অ্যাপের হোস্ট অ্যাক্টিভিটি তৈরি করার জন্য এটিকে টাস্ক দেয়।

এই পয়েন্ট থেকে, সিস্টেম- ও অ্যাপ-লেভেল প্রসেস অ্যাপ লাইফসাইকেল স্টেজ অনুযায়ী চলতে থাকে।

অ্যাক্টিভিটি তৈরি করা

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

1. ভ্যালু ইনিশিয়ালাইজ করে।
2. কনস্ট্রাক্টরকে কল করে।
3. অ্যাক্টিভিটির বর্তমান লাইফসাইকেল স্ট্যাটাসের জন্য উপযুক্ত Activity.onCreate-এর মতো কলব্যাক পদ্ধতি কল করে।

সাধারণত, onCreate পদ্ধতি লোড টাইমের উপর সবচেয়ে বেশি প্রভাব ফেলে। Jetpack Compose অ্যাপে, onCreate পদ্ধতির ওভারহেড প্রায়ই প্রাথমিক কম্পোজিশন থেকে আসে। আপনার অ্যাপ setContent কল করলে এবং আপনার টপ-লেভেল কম্পোজেবল ইনভোক করলে এটি হয়। একটি গভীর বা জটিল UI হায়ারার্কি, বা কম্পোজেবল যা প্রধান থ্রেডে ভারী গণনা করে, তা এই কম্পোজিশনের সময় বাড়িয়ে দিতে পারে।

ওয়ার্ম স্টার্ট

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

• ব্যবহারকারী আপনার অ্যাপ থেকে বেরিয়ে গিয়ে আবার সেটি চালু করেন। প্রসেসটি চলতে থাকতে পারে, তবে অ্যাপটিকে অবশ্যই onCreate-এ কল ব্যবহার করে স্ক্র্যাচ থেকে অ্যাক্টিভিটি আবার তৈরি করতে হবে।

• সিস্টেম আপনার অ্যাপকে মেমরি থেকে সরিয়ে দেয় এবং তারপর ব্যবহারকারী এটি আবার চালু করেন। প্রসেস ও অ্যাক্টিভিটি রিস্টার্ট করতে হবে, তবে onCreate-এ পাস করা সেভ করা ইনস্ট্যান্স স্টেট বান্ডেল থেকে টাস্কটি কিছুটা উপকৃত হতে পারে।

হট স্টার্ট

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

তবে, মেমরি ট্রিমিং ইভেন্টের কারণে কিছু মেমরি মুছে গেলে, যেমন onTrimMemory, তাহলে হট স্টার্ট ইভেন্টের কারণে এইসব অবজেক্ট আবার তৈরি করতে হবে।

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

Perfetto-তে অ্যাপ স্টার্টআপ কীভাবে শনাক্ত করবেন

অ্যাপ স্টার্টআপ সংক্রান্ত সমস্যা ডিবাগ করতে, অ্যাপ স্টার্টআপ ফেজে ঠিক কী কী অন্তর্ভুক্ত আছে তা নির্ধারণ করা সহায়ক হয়। Perfetto-তে সম্পূর্ণ অ্যাপ স্টার্টআপ ফেজ শনাক্ত করতে, এইসব ধাপ অনুসরণ করুন:

1. Perfetto-তে, Android অ্যাপ স্টার্টআপ থেকে পাওয়া মেট্রিক সহ সারিটি খুঁজুন। আপনি এটি দেখতে না পেলে, অন-ডিভাইস সিস্টেম ট্রেসিং অ্যাপ ব্যবহার করে ট্রেস ক্যাপচার করার চেষ্টা করুন।

   

2. সংশ্লিষ্ট স্লাইসে ক্লিক করুন এবং স্লাইসটি বেছে নিতে m প্রেস করুন। স্লাইসের চারপাশে ব্র্যাকেট দেখা যায় এবং এটি কতক্ষণ ধরে চলে তা দেখায়। এছাড়াও, বর্তমানে বেছে নেওয়া ট্যাবে সময়সীমা দেখানো হয়।

3. পিন আইকনে ক্লিক করে Android অ্যাপ স্টার্টআপ সারি পিন করুন, যা সারির উপরে পয়েন্টার ধরে রাখলে দেখা যায়।

4. যে অ্যাপ নিয়ে প্রশ্ন আছে সেই সারিতে স্ক্রল করে যান এবং সারিটি বড় করতে প্রথম সেলে ক্লিক করুন।

5. w প্রেস করে প্রধান থ্রেড জুম করুন, সাধারণত এটি উপরে থাকে (জুম আউট করতে, বাঁদিকে সরাতে এবং ডানদিকে সরাতে যথাক্রমে s, a, d প্রেস করুন)।

   

6. অ্যাপ স্টার্টআপে ঠিক কী অন্তর্ভুক্ত আছে তা দেখতে, প্রাপ্ত মেট্রিক স্লাইস সাহায্য করে, যাতে আপনি আরও বিস্তারিতভাবে ডিবাগ করা চালিয়ে যেতে পারেন।

Jetpack Compose অ্যাপ্লিকেশন বিশ্লেষণ করার সময়, আপনার UI-এর পারফর্ম্যান্স সম্পর্কে গ্র্যানুলার বিবরণ দেখতে আপনি কম্পোজিশন ট্রেসিং ব্যবহার করতে পারবেন। মূল থ্রেডের মধ্যে থাকা ট্রেস বিভাগের দিকে বিশেষ মনোযোগ দিন যা Choreographer#doFrame দিয়ে শুরু হয়। Compose:recompose, Compose:layout ও Compose:draw-এর মতো স্লাইস খুঁজুন। এগুলি আপনাকে দেখায় যে আপনার অ্যাপ নির্দিষ্ট কম্পোনেন্ট কম্পোজ, পরিমাপ, প্লেস এবং ড্র করতে কতটা সময় ব্যয় করে।

স্টার্ট-আপের অবস্থা খতিয়ে দেখতে ও উন্নত করতে মেট্রিক্স ব্যবহার করা

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

স্টার্টআপ মেট্রিক ব্যবহার করার সুবিধা

Android, কোল্ড ও ওয়ার্ম অ্যাপ স্টার্ট-আপ অপ্টিমাইজ করতে টাইম টু ইনিশিয়াল ডিসপ্লে (TTID) এবং টাইম টু ফুল ডিসপ্লে (TTFD) মেট্রিক ব্যবহার করে। Android Runtime (ART) ভবিষ্যতে স্টার্ট-আপ অপ্টিমাইজ করার জন্য দক্ষতার সাথে কোড প্রি-কম্পাইল করতে এইসব মেট্রিক থেকে ডেটা ব্যবহার করে।

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

প্রাথমিক ডিসপ্লেতে সময়

টাইম টু ইনিশিয়াল ডিসপ্লে (TTID) হল অ্যাপের UI-এর প্রথম ফ্রেম দেখাতে যতটা সময় লাগে। এই মেট্রিক কোনও অ্যাপের প্রথম ফ্রেম তৈরি করতে কত সময় লাগে তা পরিমাপ করে, যার মধ্যে কোল্ড স্টার্টের সময় প্রসেস শুরু করা, কোল্ড বা ওয়ার্ম স্টার্টের সময় অ্যাক্টিভিটি তৈরি করা এবং প্রথম ফ্রেম দেখানো অন্তর্ভুক্ত। আপনার অ্যাপের TTID কম রাখলে, ব্যবহারকারীরা আপনার অ্যাপ দ্রুত চালু হতে দেখতে পান, যা ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে সাহায্য করে। Android ফ্রেমওয়ার্কের মাধ্যমে প্রতিটি অ্যাপের জন্য TTID অটোমেটিক রিপোর্ট করা হয়। অ্যাপ স্টার্টআপের জন্য অপ্টিমাইজ করার সময়, TTFD পর্যন্ত তথ্য পেতে আমরা reportFullyDrawn প্রয়োগ করার সাজেশন দিই।

TTID-কে একটি সময় মান হিসেবে পরিমাপ করা হয় যা মোট অতিবাহিত সময়কে দেখায়, যার মধ্যে নিম্নলিখিত ইভেন্টের ক্রম অন্তর্ভুক্ত থাকে:

• প্রসেস চালু করা হচ্ছে।
• অবজেক্ট চালু করা হচ্ছে।
• হোস্ট অ্যাক্টিভিটি তৈরি ও শুরু করা হচ্ছে।
• UI চালু করা হচ্ছে।
• প্রথমবার অ্যাপটি ড্র করা হচ্ছে।

TTID রিট্রিভ করুন

TTID খুঁজতে, Logcat কমান্ড-লাইন টুলে আউটপুট লাইনের জন্য সার্চ করুন যেখানে Displayed নামের ভ্যালু আছে। এই ভ্যালু হল TTID এবং এটি নিম্নলিখিত উদাহরণের মতো দেখতে হয়, যেখানে TTID হল 3s534ms:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Android Studio-তে TTID খুঁজে পেতে, ড্রপ-ডাউন ফিল্টার মেনু থেকে আপনার Logcat ভিউতে ফিল্টার বন্ধ করুন এবং তারপরে Displayed সময় খুঁজে নিন, যেমনটি চিত্র ৪-এ দেখানো হয়েছে। ফিল্টার বন্ধ করা প্রয়োজন কারণ অ্যাপ নয়, সিস্টেম সার্ভার এই লগ পরিষেবা দেয়।

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

কখনও কখনও Logcat আউটপুটের Displayed লাইনে মোট সময়ের জন্য একটি অতিরিক্ত ফিল্ড থাকে, যেমন নিম্নলিখিত উদাহরণে:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

এই ক্ষেত্রে, প্রথমবার পরিমাপ শুধুমাত্র সেই অ্যাক্টিভিটির জন্য যা প্রথমে আঁকা হয়, সাধারণত হোস্ট অ্যাক্টিভিটি। total সময় পরিমাপ করা শুরু হয় অ্যাপ প্রসেস শুরু হওয়ার সময় থেকে এবং এর মধ্যে অন্য অ্যাক্টিভিটি অন্তর্ভুক্ত থাকতে পারে যা প্রথমে শুরু হয় কিন্তু স্ক্রিনে কিছু দেখায় না। total সময় পরিমাপ শুধুমাত্র তখনই দেখানো হয় যখন একটি অ্যাক্টিভিটি এবং মোট স্টার্টআপ সময়ের মধ্যে পার্থক্য থাকে।

আমরা Android Studio-তে Logcat ব্যবহার করার সাজেশন দিই, তবে আপনি Android Studio ব্যবহার না করলে, adb শেল অ্যাক্টিভিটি ম্যানেজার কমান্ড দিয়ে আপনার অ্যাপ রান করিয়েও TTID পরিমাপ করতে পারবেন। এখানে একটি উদাহরণ দেওয়া হল:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

Displayed মেট্রিকটি আগের মতোই Logcat আউটপুটে দেখা যায়। আপনার টার্মিনাল উইন্ডোতে নিম্নলিখিত তথ্য দেখানো হয়:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

-c এবং -a আর্গুমেন্টগুলি ঐচ্ছিক এবং আপনাকে <category> এবং <action> নির্দিষ্ট করতে দেয়।

ফুল ডিসপ্লেতে দেখার সময়

অ্যাপ সম্পূর্ণভাবে ডিসপ্লে হতে যে সময় লাগে (TTFD) তা হল ব্যবহারকারীর জন্য অ্যাপটি ইন্টার‍্যাক্টিভ হতে যে সময় লাগে। অ্যাপের UI-এর প্রথম ফ্রেম এবং প্রাথমিক ফ্রেম দেখানোর পরে অ্যাসিঙ্ক্রোনাসভাবে লোড হওয়া কন্টেন্ট দেখাতে যে সময় লাগে, সেই সময়টি রিপোর্ট করা হয়। সাধারণত, এটি নেটওয়ার্ক বা ডিস্ক থেকে লোড করা প্রাথমিক কন্টেন্ট, যেমনটি অ্যাপের মাধ্যমে রিপোর্ট করা হয়েছে। অন্য কথায়, TTFD-তে TTID-এর পাশাপাশি অ্যাপটি ব্যবহারযোগ্য হতে যে সময় লাগে তাও অন্তর্ভুক্ত থাকে। আপনার অ্যাপের TTFD কম রাখলে ব্যবহারকারীরা আপনার অ্যাপের সাথে দ্রুত ইন্টার‍্যাক্ট করতে পারেন, যা ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে সাহায্য করে।

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

TTFD রিট্রিভ করুন

TTFD খুঁজে পেতে, ComponentActivity-এর reportFullyDrawn মেথড কল করে সম্পূর্ণ ড্র করা স্টেট সিগন্যাল করুন। অ্যাপটি সম্পূর্ণভাবে আঁকা হলে এবং ব্যবহারযোগ্য অবস্থায় থাকলে reportFullyDrawn পদ্ধতি রিপোর্ট করে। সিস্টেম অ্যাপ লঞ্চ করার ইনটেন্ট পাওয়ার পর থেকে reportFullyDrawn কল করা পর্যন্ত যে সময় অতিবাহিত হয়, তাকে TTFD বলা হয়। আপনি reportFullyDrawn কল না করলে, কোনও TTFD ভ্যালু রিপোর্ট করা হয় না।

TTFD পরিমাপ করতে, UI এবং সব ডেটা সম্পূর্ণভাবে ড্র করার পরে reportFullyDrawn কল করুন। প্রথম অ্যাক্টিভিটির উইন্ডো প্রথমবার ড্র করা এবং সিস্টেমের পরিমাপ অনুযায়ী ডিসপ্লে করার আগে reportFullyDrawn কল করবেন না, কারণ সেক্ষেত্রে সিস্টেম, সিস্টেমের পরিমাপ করা সময় রিপোর্ট করে। অন্যভাবে বলতে গেলে, সিস্টেম TTID শনাক্ত করার আগে আপনি reportFullyDrawn কল করলে, সিস্টেম TTID এবং TTFD উভয়কেই একই ভ্যালু হিসেবে রিপোর্ট করে এবং এই ভ্যালুটি হল TTID ভ্যালু।

আপনি reportFullyDrawn ব্যবহার করলে, Logcat নিম্নলিখিত উদাহরণের মতো আউটপুট দেখায়, যেখানে TTFD হল ১সে৫৪মিসে:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

Logcat আউটপুটে কখনও কখনও total সময় অন্তর্ভুক্ত থাকে, যেমন প্রাথমিক ডিসপ্লে দেখানোর সময়-এ আলোচনা করা হয়েছে।

আপনার ডিসপ্লে টাইম যদি আপনার প্রত্যাশার চেয়ে ধীর হয়, তাহলে আপনি স্টার্টআপ প্রসেসে বাধা শনাক্ত করার চেষ্টা করতে পারেন।

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

স্টার্টআপ টাইমিং অ্যাকুরেসি উন্নত করুন

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

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

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

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

আপনার অ্যাপ Jetpack Compose ব্যবহার করলে, সম্পূর্ণ আঁকা অবস্থা নির্দেশ করতে আপনি নিম্নলিখিত API ব্যবহার করতে পারেন:

• ReportDrawn: এটি দেখায় যে আপনার কম্পোজেবল ইন্টার‍্যাকশনের জন্য অবিলম্বে প্রস্তুত।
• ReportDrawnWhen: আপনার কম্পোজেবল ইন্টার‍্যাকশনের জন্য কখন রেডি তা নির্দেশ করতে list.count > 0-এর মতো প্রেডিকেট নেয়।
• ReportDrawnAfter: একটি সাসপেন্ডিং পদ্ধতি গ্রহণ করে যা সম্পূর্ণ হলে, ইঙ্গিত করে যে আপনার কম্পোজেবল ইন্টারঅ্যাকশনের জন্য প্রস্তুত।

নিচের উদাহরণ থেকে আপনি জানতে পারবেন যে কীভাবে একাধিক ব্যাকগ্রাউন্ড টাস্ক একসাথে রান করতে পারবেন, যেখানে প্রতিটি টাস্কের নিজস্ব রিপোর্টার রেজিস্টার করা থাকবে:

class MainActivity : ComponentActivity() {

    sealed interface ActivityState {
        data object LOADING : ActivityState
        data object LOADED : ActivityState
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            var activityState by remember {
                mutableStateOf(ActivityState.LOADING as ActivityState)
            }
            fullyDrawnReporter.addOnReportDrawnListener {
                activityState = ActivityState.LOADED
            }
            ReportFullyDrawnTheme {
                when(activityState) {
                    is ActivityState.LOADING -> {
                        // Display the loading UI.
                    }
                    is ActivityState.LOADED -> {
                        // Display the full UI.
                    }
                }
            }
            SideEffect {
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

সমস্যা শনাক্ত করা

বটলনেক খুঁজতে, আপনি Android Studio CPU Profiler ব্যবহার করতে পারেন। আরও তথ্যের জন্য, CPU Profiler-এর মাধ্যমে CPU অ্যাক্টিভিটি পরীক্ষা করা দেখুন।

এছাড়াও, আপনার অ্যাপ ও অ্যাক্টিভিটির onCreate পদ্ধতির মধ্যে ইনলাইন ট্রেসিংয়ের মাধ্যমে সম্ভাব্য বাধা সম্পর্কে ইনসাইট পেতে পারেন। ইনলাইন ট্রেসিং সম্পর্কে জানতে, Trace ফাংশনের ডকুমেন্টেশন এবং সিস্টেম ট্রেসিংয়ের ওভারভিউ দেখুন।

সাধারণ সমস্যার সমাধান করা

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

অ্যাপ শুরু হতে অনেক সময় লাগে

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

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

অ্যাপ ইনিশিয়ালাইজেশনের সময় অন্যান্য সমস্যার মধ্যে রয়েছে গার্বেজ কালেকশন ইভেন্ট যা প্রভাবশালী বা অসংখ্য, অথবা ইনিশিয়ালাইজেশনের সাথে একই সাথে ডিস্ক I/O ঘটছে, যা ইনিশিয়ালাইজেশন প্রসেসকে আরও ব্লক করে। Dalvik রানটাইমের ক্ষেত্রে গার্বেজ কালেকশন বিশেষভাবে বিবেচনা করা হয়; Android রানটাইম (ART) একই সাথে গার্বেজ কালেকশন করে, যার ফলে সেই অপারেশনের প্রভাব কমে যায়।

সমস্যাটি ডায়াগনসিস করুন

সমস্যাটি ডায়াগনসিস করার জন্য আপনি মেথড ট্রেসিং বা ইনলাইন ট্রেসিং ব্যবহার করতে পারেন।

মেথড ট্রেসিং

CPU Profiler রান করলে দেখা যায় যে callApplicationOnCreate মেথড শেষ পর্যন্ত আপনার com.example.customApplication.onCreate মেথডকে কল করে। যদি টুলটি দেখায় যে এই পদ্ধতিগুলি কার্যকর হতে দীর্ঘ সময় নিচ্ছে, সেখানে কী কাজ হচ্ছে তা দেখতে আরও এক্সপ্লোর করুন।

ইনলাইন ট্রেসিং

সম্ভাব্য অপরাধীদের তদন্ত করতে ইনলাইন ট্রেসিং ব্যবহার করুন, যার মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:

• আপনার অ্যাপের প্রাথমিক onCreate ফাংশন।
• আপনার অ্যাপের মাধ্যমে শুরু করা যেকোনও গ্লোবাল সিঙ্গলটন অবজেক্ট।
• বটলনেক চলাকালীন ঘটতে পারে এমন কোনও ডিস্ক I/O, ডিসিরিয়ালাইজেশন বা টাইট লুপ।

সমস্যার সমাধান

সমস্যাটি অপ্রয়োজনীয় ইনিশিয়ালাইজেশন বা ডিস্ক I/O-এর সাথে সম্পর্কিত কিনা, সমাধান হল লেজি ইনিশিয়ালাইজেশন। অন্যভাবে বলতে গেলে, শুধুমাত্র সেইসব অবজেক্ট ইনিশিয়ালাইজ করুন যেগুলি অবিলম্বে প্রয়োজন। গ্লোবাল স্ট্যাটিক অবজেক্ট তৈরি করার পরিবর্তে, সিঙ্গলটন প্যাটার্নে পরিবর্তন করুন যেখানে অ্যাপটি প্রথমবার প্রয়োজন হলেই অবজেক্ট ইনিশিয়ালাইজ করে।

এছাড়াও, Hilt-এর মতো ডিপেন্ডেন্সি ইনজেকশন ফ্রেমওয়ার্ক ব্যবহার করার কথা বিবেচনা করুন যা প্রথমবার ইনজেক্ট করার সময় অবজেক্ট ও ডিপেন্ডেন্সি তৈরি করে।

আপনার অ্যাপ যদি স্টার্টআপে অ্যাপ কম্পোনেন্ট শুরু করার জন্য কন্টেন্ট প্রোভাইডার ব্যবহার করে, তাহলে পরিবর্তে অ্যাপ স্টার্টআপ লাইব্রেরি ব্যবহার করার কথা বিবেচনা করুন।

ভারী অ্যাক্টিভিটি শুরু করা

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

• বড় বা জটিল UI শুরু করা হচ্ছে।
• কম্পোজেবলে ভারী ইনিশিয়ালাইজেশন।
• ডিস্ক বা নেটওয়ার্ক I/O-তে স্ক্রিন ড্রয়িং ব্লক করা হচ্ছে।
• বিটম্যাপ লোড ও ডিকোড করা হচ্ছে।
• VectorDrawableটি অবজেক্ট রাস্টারাইজ করা হচ্ছে।
• অ্যাপের হোস্ট অ্যাক্টিভিটির অন্যান্য সাবসিস্টেমের ইনিশিয়ালাইজেশন।

সমস্যাটি ডায়াগনসিস করুন

এই ক্ষেত্রেও, মেথড ট্রেসিং ও ইনলাইন ট্রেসিং, দুটিই উপযোগী হতে পারে।

মেথড ট্রেসিং

CPU Profiler ব্যবহার করার সময়, আপনার অ্যাপের Application সাবক্লাস কনস্ট্রাক্টর এবং com.example.customApplication.onCreate পদ্ধতির দিকে মনোযোগ দিন।

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

ইনলাইন ট্রেসিং

সম্ভাব্য অপরাধীদের তদন্ত করতে ইনলাইন ট্রেসিং ব্যবহার করুন, যার মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:

• আপনার অ্যাপের প্রাথমিক onCreate ফাংশন।
• এটি শুরু করে এমন যেকোনও গ্লোবাল সিঙ্গলটন অবজেক্ট।
• বটলনেক চলাকালীন ঘটতে পারে এমন কোনও ডিস্ক I/O, ডিসিরিয়ালাইজেশন বা টাইট লুপ।

সমস্যার সমাধান

অনেক সম্ভাব্য বাধা আছে, তবে দুটি সাধারণ সমস্যা এবং তার প্রতিকার নিম্নরূপ:

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

রিকম্পোজিশন সম্পর্কে আরও তথ্যের জন্য, রিকম্পোজিশন এবং রিকম্পোজিশন কাউন্ট পান দেখুন।

কাস্টম স্প্ল্যাশ স্ক্রিন

Android 11 (API লেভেল 30) বা তার আগের ভার্সনে কাস্টম স্প্ল্যাশ স্ক্রিন প্রয়োগ করার জন্য আপনি আগে নিম্নলিখিত পদ্ধতিগুলির মধ্যে কোনও একটি ব্যবহার করে থাকলে, স্টার্টআপের সময় অতিরিক্ত সময় যোগ করা হয়েছে বলে দেখতে পেতে পারেন:

• লঞ্চ করার সময় সিস্টেমের মাধ্যমে আঁকা প্রাথমিক ফাঁকা স্ক্রিন বন্ধ করতে windowDisablePreview থিম অ্যাট্রিবিউট ব্যবহার করা।
• একটি ডেডিকেটেড Activity ব্যবহার করা।

Android 12 থেকে শুরু করে, SplashScreen API-তে মাইগ্রেট করা প্রয়োজন। এই API-এর সাহায্যে আরও দ্রুত স্টার্টআপ করা যায় এবং নিম্নলিখিত উপায়ে স্প্ল্যাশ স্ক্রিন ট্যুইক করা যায়:

• স্প্ল্যাশ স্ক্রিনের চেহারা পরিবর্তন করতে একটি থিম সেট করুন।
• windowSplashScreenAnimationDuration-এর মাধ্যমে স্প্ল্যাশ স্ক্রিন কতক্ষণ দেখানো হবে তা নিয়ন্ত্রণ করুন।
• স্প্ল্যাশ স্ক্রিন অ্যানিমেশন কাস্টমাইজ করুন এবং স্প্ল্যাশ স্ক্রিন বাতিল করার জন্য অ্যানিমেশনটি সুন্দরভাবে ম্যানেজ করুন।

এছাড়াও, কম্প্যাট লাইব্রেরি SplashScreen API ব্যাকপোর্ট করে যাতে ব্যাকওয়ার্ড-কম্প্যাটিবিলিটি চালু করা যায় এবং সব Android ভার্সন জুড়ে স্প্ল্যাশ স্ক্রিন ডিসপ্লের জন্য একই ধরনের লুক ও ফিল তৈরি করা যায়।

আরও তথ্যের জন্য স্প্ল্যাশ স্ক্রিন মাইগ্রেশন গাইড দেখুন।