systrace হল অ্যান্ড্রয়েড ডিভাইসের কর্মক্ষমতা বিশ্লেষণের প্রাথমিক টুল। যাইহোক, এটি সত্যিই অন্যান্য সরঞ্জামগুলির চারপাশে একটি মোড়ক। এটি atrace এর চারপাশে হোস্ট-সাইড র্যাপার, ডিভাইস-সাইড এক্সিকিউটেবল যা ইউজারস্পেস ট্রেসিং নিয়ন্ত্রণ করে এবং ftrace সেট আপ করে এবং লিনাক্স কার্নেলে প্রাথমিক ট্রেসিং মেকানিজম। systrace ট্রেসিং সক্ষম করতে atrace ব্যবহার করে, তারপর ftrace বাফার পড়ে এবং এটি একটি স্বয়ংসম্পূর্ণ HTML ভিউয়ারে মোড়ানো হয়। (যদিও নতুন কার্নেলগুলিতে লিনাক্স এনহ্যান্সড বার্কলে প্যাকেট ফিল্টার (eBPF) এর জন্য সমর্থন রয়েছে, এই পৃষ্ঠাটি 3.18 কার্নেলের সাথে সম্পর্কিত (কোনও ইএফপিএফ নেই) কারণ এটিই পিক্সেল বা পিক্সেল এক্সএল-এ ব্যবহৃত হয়েছিল।)
systrace গুগল অ্যান্ড্রয়েড এবং গুগল ক্রোম টিমের মালিকানাধীন এবং এটি ক্যাটাপল্ট প্রকল্পের অংশ হিসাবে ওপেন সোর্স। সিস্ট্রেস ছাড়াও, ক্যাটাপল্ট অন্যান্য দরকারী ইউটিলিটিগুলি অন্তর্ভুক্ত করে। উদাহরণস্বরূপ, ftrace-এ সিস্ট্রেস বা অ্যাট্রেস দ্বারা সরাসরি সক্ষম করার চেয়ে আরও বেশি বৈশিষ্ট্য রয়েছে এবং এতে কিছু উন্নত কার্যকারিতা রয়েছে যা কর্মক্ষমতা সমস্যা ডিবাগ করার জন্য গুরুত্বপূর্ণ। (এই বৈশিষ্ট্যগুলির জন্য রুট অ্যাক্সেস এবং প্রায়শই একটি নতুন কার্নেল প্রয়োজন।)
সিস্ট্রেস চালান
Pixel বা Pixel XL-এ জিটার ডিবাগ করার সময়, নিম্নলিখিত কমান্ড দিয়ে শুরু করুন:
./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000
GPU এবং ডিসপ্লে পাইপলাইন কার্যকলাপের জন্য প্রয়োজনীয় অতিরিক্ত ট্রেসপয়েন্টগুলির সাথে একত্রিত হলে, এটি আপনাকে ব্যবহারকারীর ইনপুট থেকে স্ক্রিনে প্রদর্শিত ফ্রেমে ট্রেস করতে দেয়। ইভেন্ট হারানো এড়াতে বাফারের আকার বড় কিছুতে সেট করুন (কারণ একটি বড় বাফার ছাড়া কিছু CPU-তে ট্রেসের কিছু পরে কোনো ইভেন্ট থাকে না)।
সিস্ট্রেসের মধ্য দিয়ে যাওয়ার সময়, মনে রাখবেন যে প্রতিটি ইভেন্ট CPU-তে কিছু দ্বারা ট্রিগার হয় ।
যেহেতু systrace ftrace-এর উপরে তৈরি করা হয় এবং ftrace CPU-তে চলে, তাই CPU-তে কিছু ftrace বাফার লিখতে হবে যা হার্ডওয়্যার পরিবর্তনগুলি লগ করে। এর মানে হল যে আপনি যদি কৌতূহলী হন কেন একটি ডিসপ্লে বেড়ার অবস্থা পরিবর্তিত হয়, তাহলে আপনি দেখতে পারেন যে CPU-তে কি চলছিল তার ট্রানজিশনের সঠিক সময়ে (CPU তে চলমান কিছু লগে সেই পরিবর্তনটিকে ট্রিগার করেছে)। এই ধারণাটি সিস্ট্রেস ব্যবহার করে কর্মক্ষমতা বিশ্লেষণের ভিত্তি।
উদাহরণ: ওয়ার্কিং ফ্রেম
এই উদাহরণটি একটি সাধারণ UI পাইপলাইনের জন্য একটি সিস্ট্রেস বর্ণনা করে। উদাহরণটি অনুসরণ করতে, ট্রেসের জিপ ফাইলটি ডাউনলোড করুন (যা এই বিভাগে উল্লেখ করা অন্যান্য ট্রেসগুলিও অন্তর্ভুক্ত করে), ফাইলটি আনজিপ করুন এবং আপনার ব্রাউজারে systrace_tutorial.html ফাইলটি খুলুন৷
টাচল্যাটেন্সির মতো সামঞ্জস্যপূর্ণ, পর্যায়ক্রমিক কাজের চাপের জন্য, UI পাইপলাইন এই ক্রম অনুসরণ করে:
- SurfaceFlinger-এ EventThread অ্যাপের UI থ্রেডকে জাগিয়ে তোলে, ইঙ্গিত দেয় যে এটি একটি নতুন ফ্রেম রেন্ডার করার সময়।
- অ্যাপটি CPU এবং GPU রিসোর্স ব্যবহার করে UI থ্রেড, RenderThread এবং HWUI টাস্কে একটি ফ্রেম রেন্ডার করে। এটি UI এর জন্য ব্যয় করা ক্ষমতার সিংহভাগ।
- অ্যাপটি রেন্ডার করা ফ্রেমটিকে বাইন্ডার ব্যবহার করে SurfaceFlinger-এ পাঠায়, তারপর SurfaceFlinger ঘুমাতে যায়।
- SurfaceFlinger-এ একটি দ্বিতীয় ইভেন্ট থ্রেড কম্পোজিশন এবং ডিসপ্লে আউটপুট ট্রিগার করতে SurfaceFlinger কে জাগিয়ে তোলে। SurfaceFlinger যদি নির্ধারণ করে যে কোন কাজ করার নেই, তাহলে এটি আবার ঘুমিয়ে যায়।
- SurfaceFlinger হার্ডওয়্যার কম্পোজার (HWC) বা হার্ডওয়্যার কম্পোজার 2 (HWC2) বা GL ব্যবহার করে কম্পোজিশন পরিচালনা করে। HWC এবং HWC2 কম্পোজিশন দ্রুত এবং কম শক্তি কিন্তু একটি চিপ (SoC) সিস্টেমের উপর নির্ভর করে সীমাবদ্ধতা রয়েছে। এটি সাধারণত 4 থেকে 6 ms সময় নেয়, কিন্তু ধাপ 2 এর সাথে ওভারল্যাপ করতে পারে কারণ Android অ্যাপগুলি সর্বদা ট্রিপল বাফার করা হয়। (যদিও অ্যাপগুলি সর্বদা ট্রিপল বাফার করা হয়, সারফেসফ্লিংগারে শুধুমাত্র একটি মুলতুবি ফ্রেম অপেক্ষা করতে পারে, যা এটিকে ডবল বাফারিংয়ের মতো দেখায়৷)
- SurfaceFlinger একটি বিক্রেতা ড্রাইভারের সাথে প্রদর্শনের জন্য চূড়ান্ত আউটপুট প্রেরণ করে এবং ইভেন্ট থ্রেড জেগে ওঠার জন্য অপেক্ষা করে ঘুমাতে ফিরে যায়।
এখানে 15409 ms থেকে শুরু হওয়া ফ্রেম সিকোয়েন্সের একটি উদাহরণ রয়েছে:
চিত্র 1. সাধারণ UI পাইপলাইন, ইভেন্ট থ্রেড চলছে।
চিত্র 1 হল একটি সাধারণ ফ্রেম যা সাধারণ ফ্রেমে ঘেরা, তাই UI পাইপলাইন কীভাবে কাজ করে তা বোঝার জন্য এটি একটি ভাল সূচনা পয়েন্ট। TouchLatency-এর জন্য UI থ্রেড সারি বিভিন্ন সময়ে বিভিন্ন রং অন্তর্ভুক্ত করে। বারগুলি থ্রেডের জন্য বিভিন্ন রাজ্যকে নির্দেশ করে:
- ধূসর। ঘুমন্ত।
- নীল। চালানোর যোগ্য (এটি চলতে পারে, কিন্তু সময়সূচী এখনও চালানোর জন্য এটি বেছে নেয়নি)।
- সবুজ। সক্রিয়ভাবে চলছে (নির্ধারক মনে করে এটি চলছে)।
- লাল। নিরবচ্ছিন্ন ঘুম (সাধারণত কার্নেলে তালা লাগিয়ে ঘুমানো)। I/O লোড নির্দেশক হতে পারে। কর্মক্ষমতা সমস্যা ডিবাগ করার জন্য অত্যন্ত দরকারী।
- কমলা। I/O লোডের কারণে নিরবচ্ছিন্ন ঘুম।
নিরবচ্ছিন্ন ঘুমের কারণ দেখতে ( sched_blocked_reason ট্রেসপয়েন্ট থেকে পাওয়া যায়), লাল নিরবচ্ছিন্ন ঘুমের স্লাইস নির্বাচন করুন।
EventThread চলাকালীন, TouchLatency-এর জন্য UI থ্রেড চালানোর যোগ্য হয়ে ওঠে। এটি কি জাগিয়েছে তা দেখতে, নীল বিভাগে ক্লিক করুন।
চিত্র 2. TouchLatency-এর জন্য UI থ্রেড।
চিত্র 2 দেখায় TouchLatency UI থ্রেডটি tid 6843 দ্বারা জাগ্রত হয়েছিল, যা EventThread-এর সাথে মিলে যায়। UI থ্রেড জেগে ওঠে, একটি ফ্রেম রেন্ডার করে এবং SurfaceFlinger ব্যবহার করার জন্য এটিকে সারিবদ্ধ করে।
চিত্র 3. UI থ্রেড জেগে ওঠে, একটি ফ্রেম রেন্ডার করে এবং সারফেসফ্লিঙ্গার ব্যবহার করার জন্য এটি সারিবদ্ধ করে।
যদি binder_driver ট্যাগটি একটি ট্রেসে সক্ষম করা থাকে, আপনি সেই লেনদেনের সাথে জড়িত সমস্ত প্রক্রিয়ার তথ্য দেখতে একটি বাইন্ডার লেনদেন নির্বাচন করতে পারেন।
চিত্র 4. বাইন্ডার লেনদেন।
চিত্র 4 দেখায় যে, সারফেসফ্লিংগারে 15,423.65 ms Binder:6832_1 টিআইডি 9579-এর কারণে চালানোর যোগ্য হয়ে উঠেছে, যা TouchLatency এর RenderThread। আপনি বাইন্ডার লেনদেনের উভয় পাশে queueBuffer দেখতে পারেন।
SurfaceFlinger পাশে queueBuffer চলাকালীন, TouchLatency থেকে মুলতুবি ফ্রেমের সংখ্যা 1 থেকে 2 হয়ে যায়৷
চিত্র 5. মুলতুবি ফ্রেমগুলি 1 থেকে 2 পর্যন্ত যায়৷
চিত্র 5 ট্রিপল বাফারিং দেখায়, যেখানে দুটি সম্পূর্ণ ফ্রেম রয়েছে এবং অ্যাপটি তৃতীয়টি রেন্ডার করা শুরু করতে চলেছে৷ এর কারণ হল আমরা ইতিমধ্যে কিছু ফ্রেম বাদ দিয়েছি, তাই অ্যাপটি আরও ড্রপ করা ফ্রেম এড়াতে চেষ্টা করার জন্য একটির পরিবর্তে দুটি মুলতুবি ফ্রেম রাখে।
শীঘ্রই, SurfaceFlinger এর প্রধান থ্রেড একটি দ্বিতীয় ইভেন্ট থ্রেড দ্বারা জাগ্রত হয় যাতে এটি ডিসপ্লেতে পুরানো মুলতুবি ফ্রেমটিকে আউটপুট করতে পারে:
চিত্র 6. SurfaceFlinger এর প্রধান থ্রেড একটি দ্বিতীয় ইভেন্ট থ্রেড দ্বারা জাগ্রত হয়।
SurfaceFlinger প্রথমে পুরানো মুলতুবি থাকা বাফারটি আটকে দেয়, যার ফলে মুলতুবি থাকা বাফার সংখ্যা 2 থেকে 1 পর্যন্ত কমে যায়:
চিত্র 7. সারফেসফ্লিঙ্গার প্রথমে পুরানো মুলতুবি থাকা বাফারে আটকে যায়।
বাফারটি ল্যাচ করার পরে, সারফেসফ্লিংগার কম্পোজিশন সেট আপ করে এবং ডিসপ্লেতে চূড়ান্ত ফ্রেম জমা দেয়। (এই বিভাগগুলির মধ্যে কিছু mdss ট্রেসপয়েন্টের অংশ হিসাবে সক্ষম করা হয়েছে, তাই সেগুলি আপনার SoC-তে অন্তর্ভুক্ত নাও হতে পারে।)
চিত্র 8. SurfaceFlinger রচনা সেট আপ করে এবং চূড়ান্ত ফ্রেম জমা দেয়।
এরপর, mdss_fb0 CPU 0-এ জেগে ওঠে। mdss_fb0 হল ডিসপ্লে পাইপলাইনের কার্নেল থ্রেড যা ডিসপ্লেতে একটি রেন্ডার করা ফ্রেম আউটপুট করার জন্য। লক্ষ্য করুন যে mdss_fb0 ট্রেসে তার নিজস্ব সারি (দেখতে নিচে স্ক্রোল করুন):
চিত্র 9. mdss_fb0 CPU 0 এ জেগেছে।
mdss_fb0 জেগে ওঠে, সংক্ষিপ্তভাবে চলে, নিরবচ্ছিন্ন ঘুমে প্রবেশ করে, তারপর আবার জেগে ওঠে।
উদাহরণ: ননওয়ার্কিং ফ্রেম
এই উদাহরণটি পিক্সেল বা পিক্সেল এক্সএল জিটার ডিবাগ করতে ব্যবহৃত একটি সিস্ট্রেস বর্ণনা করে। উদাহরণটি অনুসরণ করতে, ট্রেসের জিপ ফাইলটি ডাউনলোড করুন (যা এই বিভাগে উল্লেখ করা অন্যান্য ট্রেসগুলি অন্তর্ভুক্ত করে), ফাইলটি আনজিপ করুন এবং আপনার ব্রাউজারে systrace_tutorial.html ফাইলটি খুলুন।
আপনি যখন সিস্ট্রেস খুলবেন, আপনি নিম্নলিখিত চিত্রের মতো কিছু দেখতে পাবেন:
চিত্র 10. Pixel XL-এ চলমান টাচ লেটেন্সি বেশির ভাগ বিকল্প সক্রিয় আছে।
চিত্র 10-এ, mdss এবং kgsl ট্রেসপয়েন্ট সহ বেশিরভাগ বিকল্প সক্রিয় করা হয়েছে।
জ্যাঙ্ক খোঁজার সময়, SurfaceFlinger এর অধীনে FrameMissed সারিটি পরীক্ষা করুন। FrameMissed হল HWC2 দ্বারা প্রদত্ত একটি মানের-জীবনের উন্নতি৷ অন্যান্য ডিভাইসের জন্য সিস্ট্রেস দেখার সময়, ডিভাইসটি HWC2 ব্যবহার না করলে FrameMissed সারিটি উপস্থিত নাও হতে পারে। উভয় ক্ষেত্রেই, FrameMissed এর সাথে SurfaceFlinger এর একটি নিয়মিত রানটাইম অনুপস্থিত এবং একটি VSync-এ অ্যাপের ( com.prefabulated.touchlatency ) জন্য একটি অপরিবর্তিত মুলতুবি-বাফার গণনার সাথে সম্পর্কযুক্ত।
চিত্র 11. সারফেসফ্লিংগারের সাথে ফ্রেমমিসড পারস্পরিক সম্পর্ক।
চিত্র 11 15598.29 ms এ একটি মিসড ফ্রেম দেখায়। সারফেসফ্লিংগার VSync ব্যবধানে সংক্ষিপ্তভাবে জেগে ওঠে এবং কোনো কাজ না করেই ঘুমাতে ফিরে যায়, যার মানে SurfaceFlinger নির্ধারণ করেছে যে এটি আবার ডিসপ্লেতে একটি ফ্রেম পাঠানোর চেষ্টা করা মূল্যবান নয়।
এই ফ্রেমের জন্য পাইপলাইন কেন ভেঙেছে তা বোঝার জন্য, প্রথমে একটি সাধারণ UI পাইপলাইন সিস্ট্রেসে কীভাবে উপস্থিত হয় তা দেখতে উপরের কাজের ফ্রেমের উদাহরণটি পর্যালোচনা করুন। প্রস্তুত হলে, মিস করা ফ্রেমে ফিরে যান এবং পিছনের দিকে কাজ করুন। লক্ষ্য করুন যে SurfaceFlinger জেগে ওঠে এবং অবিলম্বে ঘুমাতে যায়। TouchLatency থেকে মুলতুবি থাকা ফ্রেমের সংখ্যা দেখার সময়, দুটি ফ্রেম রয়েছে (কী ঘটছে তা নির্ধারণে সাহায্য করার জন্য একটি ভাল সূত্র)।
চিত্র 12. SurfaceFlinger জেগে ওঠে এবং অবিলম্বে ঘুমাতে যায়।
যেহেতু সারফেসফ্লিংগারে ফ্রেম রয়েছে, এটি কোনও অ্যাপের সমস্যা নয়। উপরন্তু, SurfaceFlinger সঠিক সময়ে জেগে উঠছে, তাই এটি একটি SurfaceFlinger সমস্যা নয়। যদি সারফেসফ্লিংগার এবং অ্যাপ উভয়ই স্বাভাবিক দেখায় তবে এটি সম্ভবত ড্রাইভারের সমস্যা।
যেহেতু mdss এবং sync ট্রেসপয়েন্টগুলি সক্ষম করা আছে, আপনি বেড়া সম্পর্কে তথ্য পেতে পারেন (ডিসপ্লে ড্রাইভার এবং সারফেসফ্লিংগারের মধ্যে ভাগ করা) যা ডিসপ্লেতে ফ্রেম জমা দেওয়ার সময় নিয়ন্ত্রণ করে। এই বেড়াগুলি mdss_fb0_retire অধীনে তালিকাভুক্ত করা হয়েছে, যা বোঝায় যখন একটি ফ্রেম ডিসপ্লেতে থাকে। এই বেড়া sync ট্রেস বিভাগের অংশ হিসাবে প্রদান করা হয়. কোন বেড়াগুলি SurfaceFlinger-এর নির্দিষ্ট ইভেন্টগুলির সাথে সামঞ্জস্যপূর্ণ তা আপনার SOC এবং ড্রাইভার স্ট্যাকের উপর নির্ভর করে, তাই আপনার চিহ্নগুলিতে বেড়া বিভাগগুলির অর্থ বোঝার জন্য আপনার SOC বিক্রেতার সাথে কাজ করুন৷
চিত্র 13. mdss_fb0_retire বেড়া।
চিত্র 13 একটি ফ্রেম দেখায় যা প্রত্যাশিত হিসাবে 16.7 ms নয়, 33 ms এর জন্য প্রদর্শিত হয়েছিল৷ সেই স্লাইসটির অর্ধেক পথ, সেই ফ্রেমটিকে একটি নতুন দ্বারা প্রতিস্থাপন করা উচিত ছিল কিন্তু তা হয়নি৷ আগের ফ্রেমটি দেখুন এবং কিছু সন্ধান করুন।
চিত্র 14. ফ্রেম আগের থেকে আবক্ষ ফ্রেম।
চিত্র 14 একটি 14.482 ms ফ্রেম দেখায়। ভাঙা দুই-ফ্রেম সেগমেন্ট ছিল 33.6 ms, যা মোটামুটিভাবে দুটি ফ্রেমের জন্য প্রত্যাশিত (60 Hz এ রেন্ডার করা হয়েছে, প্রতি ফ্রেমে 16.7 ms, যা কাছাকাছি)। কিন্তু 14.482 ms 16.7 ms এর কাছাকাছি নয়, এটি নির্দেশ করে যে ডিসপ্লে পাইপে কিছু ভুল আছে।
এটি কী নিয়ন্ত্রণ করে তা নির্ধারণ করতে সেই বেড়াটি ঠিক কোথায় শেষ হয়েছে তা তদন্ত করুন:
চিত্র 15. বেড়া শেষ তদন্ত.
একটি ওয়ার্কসারিতে রয়েছে __vsync_retire_work_handler , যা বেড়া পরিবর্তিত হলে চলছে। কার্নেল উৎসের মাধ্যমে খুঁজছেন, আপনি দেখতে পারেন যে এটি ডিসপ্লে ড্রাইভারের অংশ। এটি ডিসপ্লে পাইপলাইনের জন্য জটিল পথে বলে মনে হচ্ছে, তাই এটি যত তাড়াতাড়ি সম্ভব চালাতে হবে। এটি প্রায় 70 μs (দীর্ঘ সময়সূচী বিলম্ব নয়) জন্য চালানোর যোগ্য, তবে এটি একটি ওয়ার্ককিউ এবং সঠিকভাবে নির্ধারিত নাও হতে পারে।
এটি অবদান কিনা তা নির্ধারণ করতে পূর্ববর্তী ফ্রেম পরীক্ষা করুন; কখনও কখনও ঝগড়া সময়ের সাথে যোগ করতে পারে এবং অবশেষে একটি সময়সীমা মিস করতে পারে:
চিত্র 16. পূর্ববর্তী ফ্রেম।
kworker-এ চলমান লাইনটি দৃশ্যমান নয় কারণ এটি নির্বাচন করা হলে দর্শক এটিকে সাদা করে দেয়, কিন্তু পরিসংখ্যান গল্পটি বলে: ডিসপ্লে পাইপলাইনের সমালোচনামূলক পথের অংশের জন্য 2.3 ms সময়সূচী বিলম্ব খারাপ । চালিয়ে যাওয়ার আগে, ডিসপ্লে পাইপলাইনের এই অংশটিকে একটি কাজের সারি (যা একটি SCHED_OTHER CFS থ্রেড হিসাবে চলে) থেকে একটি ডেডিকেটেড SCHED_FIFO কেথ্রেডে সরিয়ে নিয়ে বিলম্বের সমাধান করুন৷ এই ফাংশনের জন্য সময়ের গ্যারান্টি প্রয়োজন যে কাজের সারিগুলি প্রদান করতে পারে না (এবং এটি করার উদ্দেশ্যে নয়)।
এটা স্পষ্ট নয় যে এই জ্যাংকের কারণ। সহজে নির্ণয়ের ক্ষেত্রে যেমন কার্নেল লক বিতর্কের কারণে ডিসপ্লে-সমালোচনামূলক থ্রেডগুলি ঘুমাতে পারে, ট্রেসগুলি সাধারণত সমস্যাটি নির্দিষ্ট করে না। এই ঝাঁকুনি হয়তো ফ্রেমটি পড়ে যাওয়ার কারণ হয়ে থাকতে পারে। বেড়ার সময়গুলি 16.7 ms হওয়া উচিত, কিন্তু ড্রপ করা ফ্রেমের দিকে এগিয়ে যাওয়া ফ্রেমে সেগুলি একেবারেই কাছাকাছি নয়৷ ডিসপ্লে পাইপলাইনটি কতটা দৃঢ়ভাবে সংযুক্ত করা হয়েছে তা বিবেচনা করে, এটা সম্ভব যে বেড়ার চারপাশের ঝাঁকুনির ফলে একটি ড্রপ ফ্রেম হয়েছে৷
এই উদাহরণে, সমাধানটি __vsync_retire_work_handler একটি ওয়ার্ককিউ থেকে একটি ডেডিকেটেড kthread-এ রূপান্তর করা জড়িত। এর ফলে বাউন্সিং বলের পরীক্ষায় লক্ষণীয় জিটার উন্নতি হয় এবং জ্যাঙ্ক কমে যায়। পরবর্তী চিহ্নগুলি বেড়ার সময় দেখায় যা 16.7 ms এর খুব কাছাকাছি ঘোরাফেরা করে৷