फ़्रेम दर

औसत एफ़पीएस

Android डिवाइसों पर बेहतरीन क्वालिटी वाला गेमिंग अनुभव देने के लिए, फ़्रेम रेट का स्थिर और स्मूद होना ज़रूरी है. गेम की परफ़ॉर्मेंस को मेज़र करते समय, आपको औसत एफ़पीएस को बेसलाइन के तौर पर मेज़र करना चाहिए. इससे, गेमिंग अनुभव के बारे में बुनियादी जानकारी मिलती है. आपको अपने गेम को 60 एफ़पीएस के औसत फ़्रेम रेट के हिसाब से ऑप्टिमाइज़ करना चाहिए, ताकि गेमिंग का बेहतरीन अनुभव दिया जा सके.

स्थिरता के लिए P90 और P99 एफ़पीएस

औसत 60 एफ़पीएस के साथ, किसी गेम में रुक-रुककर गड़बड़ियां, माइक्रो-स्टटरिंग, और इनपुट लैग की समस्या हो सकती है. इससे, खिलाड़ियों को खराब अनुभव मिलता है.

इसलिए, फ़्रेम की स्थिरता उतनी ही ज़रूरी है जितना कि औसत फ़्रेम रेट को ट्रैक करना. इस मामले में, आपको P90 और P99 फ़्रेम रेट की मेट्रिक को, क्रमशः स्थिर बेसलाइन और स्टटर इंडिकेटर के तौर पर मेज़र करना चाहिए. इन मेट्रिक से, परफ़ॉर्मेंस के "टेल एंड" को कैप्चर किया जाता है, ताकि खिलाड़ियों को मिलने वाले अनुभव को ऑप्टिमाइज़ किया जा सके.

मेट्रिक

• औसत एफ़पीएस (बेसलाइन): यह बुनियादी मेट्रिक, आपके गेम की परफ़ॉर्मेंस की सामान्य बेसलाइन देती है. यह एक स्टैंडर्ड बेंचमार्क है. हालांकि, औसत की गणना का मतलब है कि रुक-रुककर होने वाले फ़्रेम ड्रॉप और माइक्रो-स्टटरिंग का पता नहीं लगाया जा सकता. इसलिए, यह मेट्रिक अकेले ही खिलाड़ियों के अनुभव को नहीं दिखा सकती.
• P90 एफ़पीएस (10% पर्सेंटाइल पर स्थिर बेसलाइन): इससे पता चलता है कि आपके 90% फ़्रेम, इस स्थिर बेसलाइन से ज़्यादा हैं. साथ ही, सिर्फ़ 10% सबसे धीमे फ़्रेम को रेंडर होने में ज़्यादा समय लगा. अगर आपका P90 फ़्रेम रेट ज़्यादा है और यह आपके औसत के आस-पास है, तो गेम, सेशन के ज़्यादातर हिस्से में लगातार अच्छी तरह से काम कर रहा है.
• P99 एफ़पीएस (1% पर्सेंटाइल पर स्टटर इंडिकेटर): इससे पता चलता है कि आपके 99% फ़्रेम, इस स्टटर इंडिकेटर से ज़्यादा हैं. साथ ही, सिर्फ़ 1% सबसे धीमे फ़्रेम को अलग किया गया है. यह मेट्रिक, माइक्रो-स्टटर, ऐसेट लोड होने में लगने वाली देरी, और ऐसेट-हैवी रेंडरिंग में अचानक होने वाली बढ़ोतरी का पता लगाने के लिए ज़रूरी है. इनकी वजह से, साफ़ तौर पर गड़बड़ियां दिखती हैं.

उदाहरण

अपने औसत एफ़पीएस की तुलना P90 और P99 मेट्रिक से करके, किसी गेम के असल व्यवहार का सटीक तरीके से पता लगाया जा सकता है.

पहला विकल्प: ऑप्टिमल कर्व (ऑप्टिमाइज़ किया गया गेम)

• औसत: 60 एफ़पीएस (16.6 मि॰से॰)
• P90: 58 एफ़पीएस (17.2 मि॰से॰)
• P99: 52 एफ़पीएस (19.2 मि॰से॰)
• विश्लेषण: मेट्रिक, एक-दूसरे के काफ़ी करीब हैं. गेम, बहुत स्मूद और लगातार अच्छी तरह से काम कर रहा है. इसमें माइक्रो-स्टटर नहीं हैं. साथ ही, 1% सबसे खराब फ़्रेम भी, आम तौर पर आंखों से नहीं दिखते.

दूसरा विकल्प: लोड बॉटलनेक (सीपीयू/जीपीयू बाउंड)

• औसत: 45 एफ़पीएस (22.2 मि॰से॰)
• P90: 40 एफ़पीएस (25.0 मि॰से॰)
• P99: 38 एफ़पीएस (26.3 मि॰से॰)
• विश्लेषण: औसत फ़्रेम रेट कम है, लेकिन यह लगातार कम है. औसत की तुलना में, P99 में ज़्यादा गिरावट नहीं आई है. इससे पता चलता है कि सिस्टम, ग्राफ़िकल सेटिंग या रिज़ॉल्यूशन की पाबंदियों की वजह से, ज़्यादा लोड ले रहा है. गेम में स्टटरिंग नहीं होगी, लेकिन यह सुस्त होगा. आम तौर पर, ग्राफ़िक्स सेटिंग कम करने से, इन मेट्रिक में एक जैसा सुधार होता है.

तीसरा विकल्प: 60 एफ़पीएस का अस्थिर फ़्रेम रेट (शेडर कंपाइलेशन / ऐसेट स्ट्रीमिंग स्टटर)

• औसत: 60 एफ़पीएस (16.6 मि॰से॰)
• P90: 45 एफ़पीएस (22.2 मि॰से॰)
• P99: 15 एफ़पीएस (66.6 मि॰से॰)
• विश्लेषण: यह सबसे खराब स्थिति है. औसत फ़्रेम रेट भले ही बेहतरीन हो, लेकिन P99 से एक गंभीर समस्या का पता चलता है. 66.6 मि॰से॰ पर P99 का मतलब है कि गेम, एक साथ कई फ़्रेम के लिए पूरी तरह से फ़्रीज़ हो रहा है. इससे, गंभीर आउटलायर का पता चलता है. आम तौर पर, ये सीपीयू बॉटलनेक, ऐसेट स्ट्रीमिंग में लगने वाली देरी (उदाहरण के लिए, धीमी रैम या स्टोरेज) या शेडर कंपाइलेशन की वजह से होने वाली गड़बड़ियों की वजह से होते हैं.

आकलन

औसत एफ़पीएस, P90, और P99 एफ़पीएस को असरदार तरीके से मेज़र करने के लिए, इन दो तरीकों का इस्तेमाल किया जा सकता है. पहला तरीका है, Android Performance Analyzer (APA) का इस्तेमाल करके, सिस्टम ट्रेस का विश्लेषण करना. यह परफ़ॉर्मेंस प्रोफ़ाइलिंग टूल है. दूसरा तरीका है, मौजूदा adb dumpsys SurfaceFlinger --timestats कमांड का इस्तेमाल करना.

1. एपीए का इस्तेमाल करके मेज़र करना

एपीए का इस्तेमाल करके, सिस्टम ट्रेस रिकॉर्ड किया जा सकता है. साथ ही, एसक्यूएल क्वेरी की मदद से, फ़्रेम डेटा का सटीक विश्लेषण किया जा सकता है. अपनी मेट्रिक मेज़र करने के लिए, यह तरीका अपनाएं:

1. एपीए की मदद से ट्रेस कैप्चर करना: अपना गेम चलाएं. इसके बाद, एपीए का इस्तेमाल करके, उस सेगमेंट के दौरान सिस्टम ट्रेस कैप्चर करें जिसका आपको विश्लेषण करना है. उदाहरण के लिए, गेमप्ले के दौरान वह पॉइंट जहां आपको फ़्रेम ड्रॉप होने का शक है. डिवाइस के कनेक्ट होने और ट्रेस रिकॉर्डिंग पूरी होने के बाद, ट्रेस डेटा, एपीए इंटरफ़ेस में लोड हो जाएगा.

   

2. एपीए में एसक्यूएल टैब पर क्लिक करना: ट्रेस विश्लेषण स्क्रीन खुलने के बाद, यूज़र इंटरफ़ेस (यूआई) के सबसे ऊपर या साइड नेविगेशन वाले सेक्शन में मौजूद एसक्यूएल टैब पर क्लिक करें. इससे, ट्रेस प्रोसेसर एनवायरमेंट खुलेगा. यहां, डेटा के लिए सीधे क्वेरी की जा सकती है.

3. एपीए के एसक्यूएल टैब में एसक्यूएल क्वेरी चिपकाना: यहां दी गई एसक्यूएल क्वेरी कॉपी करें और इसे क्वेरी इनपुट फ़ील्ड में चिपकाएं. इस क्वेरी से, SurfaceFlinger प्रोसेस की पहचान की जाती है. साथ ही, डिसप्ले अपडेट के असल टाइमस्टैंप के आधार पर, फ़्रेम इंटरवल का हिसाब लगाया जाता है. इसके अलावा, औसत एफ़पीएस, सबसे कम 10% (P90) एफ़पीएस, और सबसे कम 1% (P99) एफ़पीएस का पता लगाया जाता है.

   WITH target_process AS (
   -- 1. Get SurfaceFlinger process ID where frames were identified in debugging step 3
   SELECT upid
   FROM process
   WHERE name = '/system/bin/surfaceflinger'
   ),
   actual_present_times AS (
   -- 2. Calculate the hardware display timestamps when SurfaceFlinger actually updated the screen
   SELECT
       (ts + dur) AS present_ts
   FROM actual_frame_timeline_slice
   WHERE upid IN (SELECT upid FROM target_process)
       AND dur > 0
   ),
   present_intervals AS (
   -- 3. Calculate intervals between physical screen refreshes
   SELECT
       (LEAD(present_ts) OVER (ORDER BY present_ts ASC) - present_ts) / 1000000.0 AS p2p_ms
   FROM actual_present_times
   ),
   valid_intervals AS (
   -- 4. Filter for valid frame intervals
   SELECT p2p_ms
   FROM present_intervals
   WHERE p2p_ms IS NOT NULL AND p2p_ms > 0
   ),
   ordered_frames AS (
   -- 5. Sort in ascending order to calculate percentiles
   SELECT
       p2p_ms,
       ROW_NUMBER() OVER (ORDER BY p2p_ms ASC) AS row_num,
       COUNT(1) OVER () AS total_frames
   FROM valid_intervals
   )
   -- 6. Output final metrics
   SELECT
   (SELECT COUNT(1) FROM valid_intervals) AS total_presented_frames,
   ROUND(1000.0 / NULLIF((SELECT AVG(p2p_ms) FROM valid_intervals), 0), 2) AS average_fps,
   ROUND(1000.0 / NULLIF((SELECT p2p_ms FROM ordered_frames WHERE row_num = CAST(total_frames * 0.90 AS INT)), 0), 2) AS low_10_fps,
   ROUND(1000.0 / NULLIF((SELECT p2p_ms FROM ordered_frames WHERE row_num = CAST(total_frames * 0.99 AS INT)), 0), 2) AS low_1_fps;
   

4. 'क्वेरी चलाएं' पर क्लिक करना: क्वेरी इनपुट फ़ील्ड के पास मौजूद, क्वेरी चलाएं बटन (या एक्ज़ीक्यूट आइकॉन) पर क्लिक करें. क्वेरी के एक्ज़ीक्यूट होने के बाद, मेज़र किए गए कुल फ़्रेम (total_presented_frames), औसत फ़्रेम रेट (average_fps), सबसे कम 10% एफ़पीएस (low_10_fps), और सबसे कम 1% एफ़पीएस (low_1_fps), नतीजों वाले पैन में एक टेबल में दिखेंगे.

   

2. adb (dumpsys SurfaceFlinger) का इस्तेमाल करके मेज़र करना

औसत एफ़पीएस, P90, और P99 को असरदार तरीके से मेज़र करने के लिए, Android dumpsys surfaceflinger timestats कमांड का इस्तेमाल किया जा सकता है. यह टूल, रेंडर किए जा रहे सभी लेयर के लिए औसत एफ़पीएस और presentToPresent टाइमिंग हिस्टोग्राम देता है. किसी फ़्रेम का presentToPresent टाइम, मौजूदा फ़्रेम और उससे पहले वाले फ़्रेम के बीच का इंटरवल होता है.

अपने गेम के लिए इन मेट्रिक को इकट्ठा करने और इनका हिसाब लगाने के लिए, यहां दिया गया तरीका अपनाएं:

1. कैप्चर करना शुरू करना: जानकारी कैप्चर करने के लिए, enable और clear फ़्लैग के साथ यह कमांड चलाएं:

   adb shell dumpsys SurfaceFlinger --timestats -clear -enable
   

2. जानकारी डंप करना: गेम को काफ़ी समय तक खेलने के बाद, जानकारी आउटपुट करने के लिए, dump फ़्लैग के साथ यह कमांड फिर से चलाएं:

   adb shell dumpsys SurfaceFlinger --timestats -dump
   

3. लेयर के हिसाब से फ़िल्टर करना: डंप की गई जानकारी में, SurfaceFlinger से रेंडर की गई सभी लेयर का डेटा होता है. layerName के आधार पर फ़िल्टर करके, आपको अपने गेम से जुड़ा सेक्शन ढूंढना होगा. उदाहरण के लिए, layerName = SurfaceView[com.example.yourgame...].

   layerName = SurfaceView[com.google.test/com.devrel.MainActivity]@0(BLAST)#132833
   

4. औसत एफ़पीएस की पहचान करना: हर लेयर के लिए औसत एफ़पीएस अपने-आप कैलकुलेट हो जाता है और यह डंप आउटपुट में सीधे दिखता है. उदाहरण के लिए, averageFPS = 30.179.

   ...
   averageFPS = 30.179
   ...
   

5. P90 और P99 एफ़पीएस का हिसाब लगाना: P90 और P99 मेट्रिक ढूंढने के लिए, आपको totalFrames और presentToPresent टाइमिंग हिस्टोग्राम का विश्लेषण करना होगा जो डंप में दिया गया है.

   totalFrames = 1000
   ...
   presentToPresent histogram is as below:
   0ms=0 1ms=0 2ms=0 3ms=0 4ms=0 5ms=0 6ms=0 7ms=0 8ms=0 9ms=0 10ms=0 11ms=0 12ms=0
   13ms=0 14ms=0 15ms=0 16ms=850 17ms=0 18ms=0 19ms=0 20ms=0 21ms=0 22ms=0 23ms=0
   24ms=0 25ms=0 26ms=0 27ms=0 28ms=0 29ms=0 30ms=0 31ms=0 32ms=0 33ms=100 34ms=0
   36ms=0 38ms=0 40ms=0 42ms=0 44ms=0 46ms=0 48ms=0 50ms=35 54ms=0 58ms=0 62ms=0
   66ms=10 70ms=0 74ms=0 78ms=0 82ms=0 86ms=0 90ms=0 94ms=0 98ms=0 102ms=5 106ms=0
   110ms=0 114ms=0 118ms=0 122ms=0 126ms=0 130ms=0 134ms=0 138ms=0 142ms=0 146ms=0
   150ms=0 200ms=0 250ms=0 300ms=0 350ms=0 400ms=0 450ms=0 500ms=0 550ms=0 600ms=0
   650ms=0 700ms=0 750ms=0 800ms=0 850ms=0 900ms=0 950ms=0 1000ms=0
   

   A. कॉन्सेप्ट वाला उदाहरण (क्युमुलेटिव डिस्ट्रिब्यूशन टेबल) मान लें कि आपके गेम सेशन में, totalFrames की संख्या 1,000 रिकॉर्ड की गई. P90 और P99 ढूंढने के लिए, आपको मिलीसेकंड के उन थ्रेशोल्ड का हिसाब लगाना होगा जहां क्युमुलेटिव फ़्रेम की संख्या, क्रमशः 900 फ़्रेम (90%) और 990 फ़्रेम (99%) तक पहुंचती है. इसके लिए, सबसे कम मिलीसेकंड बकेट से गिनती शुरू करें.

   फ़्रेम रेंडर होने में लगने वाला समय (मिलीसेकंड)	फ़्रेम की संख्या (हिस्टोग्राम)	क्युमुलेटिव फ़्रेम की संख्या	पर्सेंटाइल स्टेटस / कैलकुलेशन
   16 मि॰से॰	850	850	85.0%
   33 मि॰से॰	100	950	95.0% (P90 का टारगेट 900 पूरा हुआ! → 1000/33 = 30.3 एफ़पीएस)
   50 मि॰से॰	35	985	98.5%
   66 मि॰से॰	10	995	99.5% (P99 का टारगेट 990 पूरा हुआ! → 1000/66 = 15.1 एफ़पीएस)
   102 मि॰से॰	5	1,000	100%

   B. लागू करने का लॉजिक (स्यूडोकोड) अगर Python स्क्रिप्ट या लॉग पार्सर का इस्तेमाल करके, इस विश्लेषण को ऑटोमेट किया जा रहा है, तो हिस्टोग्राम से P90 और P99 की वैल्यू निकालने के लिए, इस लॉजिक को इस तरह लागू किया जा सकता है:

   # Define target thresholds based on total frame count
   p90_target = totalFrames * 0.90
   p99_target = totalFrames * 0.99
   
   cumulative_frames = 0
   p90_fps = None
   p99_fps = None
   
   # Iterate through the parsed SurfaceFlinger histogram data (sorted by millisecond)
   for ms_bucket, frame_count in present_to_present_histogram:
       cumulative_frames += frame_count
   
       # Capture P90 when cumulative frames cross the 90% threshold
       if p90_fps is None and cumulative_frames >= p90_target:
           p90_fps = 1000 / ms_bucket
   
       # Capture P99 when cumulative frames cross the 99% threshold
       if p99_fps is None and cumulative_frames >= p99_target:
           p99_fps = 1000 / ms_bucket
           break # Optimization: stop iterating once both targets are found
   

6. कैप्चर करना बंद करना: सभी ज़रूरी जानकारी इकट्ठा करने के बाद, आपको disable फ़्लैग का इस्तेमाल करके, timestats को बंद करना चाहिए:

   adb shell dumpsys SurfaceFlinger --timestats -disable
   

धीमे सेशन

धीमे सेशन से, असल दुनिया में परफ़ॉर्मेंस से जुड़ी समस्याओं का पता चलता है. अगर 25% से ज़्यादा फ़्रेम, किसी थ्रेशोल्ड (उदाहरण के लिए, 20 एफ़पीएस) से कम हो जाते हैं, तो सेशन को "धीमा" माना जाता है. यह मेट्रिक, बिल्ड से जुड़ी गंभीर समस्याओं का पता लगाने में मददगार है. हालांकि, सिर्फ़ इस मेट्रिक के आधार पर, बेहतरीन क्वालिटी और लगातार अच्छा अनुभव मिलने की गारंटी नहीं दी जा सकती. ऐसा हो सकता है कि कोई गेम, धीमे सेशन के थ्रेशोल्ड से बच जाए, लेकिन उसमें माइक्रो-स्टटरिंग की समस्या हो. इससे, 60 एफ़पीएस का स्मूद अनुभव नहीं मिल पाता.

'धीमे सेशन' और 'फ़्रेम रेट', दोनों मेट्रिक, फ़्रेम रेंडर होने में लगने वाले समय से मिलती हैं. हालांकि, दोनों अलग-अलग काम करती हैं. औसत, P90, और P99 एफ़पीएस मेट्रिक, परफ़ॉर्मेंस की क्वालिटी और स्थिरता को मेज़र करती हैं. साथ ही, ये अचानक होने वाले फ़्रेम ड्रॉप और रुक-रुककर होने वाली गड़बड़ियों का पता लगाती हैं. धीमे सेशन की मेट्रिक में इन समस्याओं का पता नहीं चल पाता.

नतीजा

परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए, एक पूरी रणनीति की ज़रूरत होती है. डेवलपर को, परफ़ॉर्मेंस में होने वाली गंभीर गिरावट का पता लगाने के लिए, धीमे सेशन को मुख्य रडार के तौर पर इस्तेमाल करना चाहिए. इसके बाद, असल वजहों का पता लगाने और गेमप्ले की असल स्मूदनेस की पुष्टि करने के लिए, औसत एफ़पीएस, P90, और P99 की जांच करनी चाहिए. इन मेट्रिक को इंटिग्रेट करके, यह पक्का किया जा सकता है कि आपका ऐप्लिकेशन, लगातार अच्छा और बेहतरीन उपयोगकर्ता अनुभव दे.

अन्य संसाधन

प्रोफ़ाइलिंग की बेहतर तकनीकों, Frame Pacing API को लागू करने, और इंजन के हिसाब से ऑप्टिमाइज़ेशन की रणनीतियों के बारे में ज़्यादा जानने के लिए, Android डेवलपर के आधिकारिक दस्तावेज़ देखें:

• Android की ज़रूरी जानकारी: धीमे सेशन: जानें कि Google Play, धीमे रेंडरिंग के लगातार बने रहने वाले समय को कैसे मेज़र करता है और इसकी रिपोर्ट कैसे देता है. इससे, उपयोगकर्ता अनुभव पर सीधे असर पड़ता है. "धीमे सेशन" का मतलब है, उपयोगकर्ता का ऐसा सेशन जिसमें 25% से ज़्यादा फ़्रेम धीमी रफ़्तार से रेंडर होते हैं. उदाहरण के लिए, 50 मि॰से॰ से ज़्यादा समय लगना. यह 20 एफ़पीएस के बराबर है.
• Android डेवलपर: गेम की परफ़ॉर्मेंस ऑप्टिमाइज़ करना: Android गेम ऑप्टिमाइज़ेशन के लिए, मुख्य हब देखें. इस पूरी गाइड में, सबसे सही तरीकों और प्रोफ़ाइलिंग टूल (जैसे, APA और Perfetto) के बारे में बताया गया है. इनकी मदद से, अपने गेम की कुल परफ़ॉर्मेंस को बेहतर बनाया जा सकता है.