Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

फ़्रेम दर

औसत एफ़पीएस

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

स्टेबिलिटी के लिए P90 और P99 एफ़पीएस

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

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

मेट्रिक

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

उदाहरण

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

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

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

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

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

तीसरा उदाहरण: 60 FPS (शेडर कंपाइलेशन / ऐसेट स्ट्रीमिंग स्टटर) की समस्या

औसत: 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. एपीए का इस्तेमाल करके मेज़र करना

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

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

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

एसक्यूएल क्वेरी को APA SQL टैब में चिपकाएं: यहां दी गई एसक्यूएल क्वेरी को कॉपी करें और उसे क्वेरी इनपुट फ़ील्ड में चिपकाएं. यह क्वेरी, 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;

'क्वेरी चलाएं' पर क्लिक करें: क्वेरी इनपुट फ़ील्ड के बगल में मौजूद, क्वेरी चलाएं बटन (या एक्ज़ीक्यूट आइकॉन) पर क्लिक करें. क्वेरी के पूरा होने के बाद, मेज़र किए गए कुल फ़्रेम (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 टाइम, मौजूदा फ़्रेम और पिछले फ़्रेम के बीच का इंटरवल होता है.

यहां आपके गेम के लिए, इन मेट्रिक को इकट्ठा करने और उनकी गिनती करने के लिए सिलसिलेवार निर्देश दिए गए हैं:

डेटा कैप्चर करना शुरू करें: जानकारी कैप्चर करना शुरू करने के लिए, enable और clear फ़्लैग के साथ यह कमांड चलाएं:
```
adb shell dumpsys SurfaceFlinger --timestats -clear -enable
```
डंप की गई जानकारी: जब गेम को काफ़ी देर तक खेला जा चुका हो, तो जानकारी पाने के लिए डंप फ़्लैग के साथ फिर से यह कमांड चलाएं:
```
adb shell dumpsys SurfaceFlinger --timestats -dump
```
लेयर के हिसाब से फ़िल्टर करें: डंप की गई जानकारी में, SurfaceFlinger की रेंडर की गई सभी लेयर का डेटा होता है. आपको अपने गेम से जुड़ा सेक्शन ढूंढना होगा. इसके लिए, layerName के आधार पर फ़िल्टर करें. उदाहरण के लिए, layerName = SurfaceView[com.example.yourgame...].
```
layerName = SurfaceView[com.google.test/com.devrel.MainActivity]@0(BLAST)#132833
```
औसत एफ़पीएस की पहचान करना: हर लेयर के लिए औसत एफ़पीएस की गणना अपने-आप होती है. इसे डंप आउटपुट में सीधे तौर पर दिखाया जाता है. उदाहरण के लिए, averageFPS = 30.179.
```
...
averageFPS = 30.179
...
```

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. कॉन्सेप्ट का उदाहरण (कुल डिस्ट्रिब्यूशन टेबल) मान लें कि आपके गेम सेशन में कुल फ़्रेम की संख्या 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

डेटा कैप्चर करना बंद करें: सभी ज़रूरी जानकारी इकट्ठा करने के बाद, आपको डिसएबल फ़्लैग का इस्तेमाल करके, टाइमस्टैट्स को बंद कर देना चाहिए:
```
adb shell dumpsys SurfaceFlinger --timestats -disable
```

धीमे सेशन

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

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

नतीजा

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

अन्य संसाधन

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

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

फ़्रेम दर संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.