मोबाइल ऐप परफ़ॉर्मेंस
Mobile app performance का मतलब है कि app कितनी जल्दी respond करता है और ऐसा करते हुए phone के कितने resources खर्च करता है। ISO/IEC 25010 की भाषा में यह performance efficiency की दो sub-characteristics, time behaviour और resource utilisation, को cover करता है, और phone पर ज़्यादातर risk पाँच measures में होता है: startup time, frame rate, memory, battery और असली network conditions में व्यवहार। हर measure को किसी तय target या पिछले release के सामने जाँचा जाता है, उन्हीं devices पर जो आपके users के पास सच में हैं।
उदाहरण: एक shopping app developer के नए flagship phone पर home screen 1.8 seconds में दिखाता है। Team जिस सबसे सस्ते phone को support करती है, उस पर रुके हुए process से शुरू करने पर वही screen 4.6 seconds लेती है, images load होते समय product list अटकती है, और कमज़ोर mobile connection पर home screen 19 requests का इंतज़ार करती है। कोई functional test case fail नहीं होता, फिर भी उस phone का हर user यह महसूस करता है।
यह क्यों ज़रूरी है
Users app को पहले कुछ seconds और हर scroll में परखते हैं। धीमा start, अटकती list या गर्म होकर charge खोता phone uninstalls और store में खराब reviews ला सकता है। Platforms भी इसे मापते हैं: Google Play Console में Android vitals असली devices से startup time, slow और frozen frames और battery से जुड़ा व्यवहार दिखाता है, और Xcode Organizer analytics share करने वाले users से launch time, hangs, memory और battery use दिखाता है।
Tester के लिए performance defects आसानी से छूट जाते हैं, क्योंकि वे conditions पर निर्भर होते हैं: सस्ता device, cold start, लंबा session, कमज़ोर signal। ये हर release के साथ थोड़ा-थोड़ा बढ़ते हैं, जब तक app साफ़ तौर पर पहले से धीमा न हो जाए। हर release में वही scenarios उसी तरीके से मापना "धीमा लगता है" को ऐसे numbers में बदल देता है जिन पर developer काम कर सके।
पाँच measures और हर एक का मतलब
हर measure की अपनी definition है और fail होने का अपना तरीका। पहले vocabulary सीखें: "startup धीमा है" कहने वाली report उस report से बहुत कमज़ोर है जो कहती है "cold start से first frame तक का समय 1.4 s से 2.6 s हो गया"।
- Startup time: cold start में app तब launch होता है जब उसका process चल नहीं रहा, इसलिए सब कुछ नए सिरे से बनता और load होता है; warm start मौजूद चीज़ों का कुछ हिस्सा दोबारा इस्तेमाल करता है पर screen फिर से बनाता है; hot start सिर्फ़ memory में मौजूद screen को सामने लाता है। Android दो पलों के नाम देता है: time to initial display (TTID), यानी पहला frame, और time to full display (TTFD), जब user जिस content के लिए आया वह तैयार हो; app इसे
reportFullyDrawn()call करके report करता है। Android vitals startup को first frame (TTID) तक मापता है और 5 seconds या ज़्यादा के cold start, 2 seconds या ज़्यादा के warm start और 1.5 seconds या ज़्यादा के hot start को excessive मानता है। - Frame rate: 60 Hz पर app के पास हर frame बनाने के लिए लगभग 16.7 ms हैं; 120 Hz पर लगभग 8.3 ms। Budget से चूकने वाले frames अटकन के रूप में दिखते हैं, जिसे jank कहते हैं (Apple इन्हें hitches कहता है)। Android vitals slow rendering और frozen frames दिखाता है; frozen frames वे frames हैं जिन्हें render होने में 700 ms से ज़्यादा लगते हैं। आम वजह main thread पर लंबा काम है, वही thread जिसके block होने से Android और iOS वाले lesson का ANR बनता है।
- Memory: देखें कि किसी flow को peak पर कितनी memory चाहिए और flow खत्म होने पर memory अपने baseline पर लौटती है या नहीं; हर repetition के साथ बढ़ती memory leak है। ज़्यादा memory app को बंद करवा देती है: background में system उसे जल्दी बंद कर देता है, तो user लौटने पर restart हुआ app पाता है जिसमें उसका डाला input गायब होता है; foreground में limit पार करने पर app out-of-memory crash के रूप में बंद होता है।
- Battery: energy screen, processor, radios और GPS जैसे sensors पर खर्च होती है। आम defects ऐसा काम है जो रुकता नहीं: user के map छोड़ने के बाद भी location updates, processor को जगाए रखने वाले wake locks, हर कुछ seconds में server polling, और Android के Doze idle mode या iOS के Low Power Mode को नज़रअंदाज़ करने वाले background jobs। हर platform की battery settings हर app का हिस्सा दिखाती हैं।
- Network conditions: users Wi-Fi, तेज़ और धीमे mobile data और no signal के बीच आते-जाते रहते हैं। Latency (हर round trip का समय) उन screens को सज़ा देती है जो एक के बाद एक कई requests भेजती हैं; कम bandwidth बड़ी images और responses को सज़ा देती है; packet loss खोया हुआ data दोबारा भेजने पर मजबूर करता है, जिससे delay और बढ़ता है।
| Measure | क्या record करें | कैसे: Android, फिर iOS | चेतावनी संकेत |
|---|---|---|---|
| Startup time | Cold, warm और hot start; TTID और TTFDRelease build पर 10 runs का median | Android: am force-stop के बाद am start -WiOS: Instruments का App Launch template | 5 s या ज़्यादा का cold startAndroid vitals में excessive, या पिछले release से धीमा |
| Frame rate | Budget के सामने frame time60 Hz पर 16.7 ms, 120 Hz पर 8.3 ms | Android: dumpsys gfxinfo में janky frames और percentilesiOS: Instruments का Animation Hitches | Scroll करते समय दिखने वाली अटकन700 ms से ज़्यादा के frozen frames |
| Memory | Flow के दौरान peak और baseline पर वापसीवही flow 20 बार दोहराएँ | Android: dumpsys meminfo, Android Studio का memory profileriOS: Instruments के Allocations और Leaks | हर repetition के साथ बढ़तBackground से लौटने पर restart हुआ app |
| Battery | तय session में drain; background का कामBattery पर 30 मिनट, फिर background में एक घंटा | Android: dumpsys batterystatsiOS: Xcode का energy gauge; दोनों में: Settings में हर app का हिस्सा | Screen छोड़ने के बाद भी चालू location, wake locks या polling |
| Network conditions | हर profile पर usable screen तक का समय और खर्च हुआ dataअच्छा Wi-Fi, typical 4G, कमज़ोर 3G जैसा | Android: emulator की speed और delay, या throttling proxyiOS: Network Link Conditioner के profiles | कई sequential requests; बड़े responsesकभी न रुकने वाला spinner |
Startup और frozen frames की thresholds Android vitals से हैं; frame budget refresh rate से निकलता है। हर result की तुलना उसी device पर पिछले release से करें।
भरोसेमंद measurement: numbers से पहले conditions
कोई number अपनी conditions के साथ ही मायने रखता है। Debug builds में extra checks होते हैं और वे users के install किए app से काफ़ी धीमे हो सकते हैं, इसलिए release build मापें। असली devices इस्तेमाल करें, सबसे कमज़ोर supported device से शुरू करके; emulator आपके computer के processor पर चलता है और budget phone के बारे में कम बताता है। Runs के बीच state एक जैसी रखें: वही account और data, बाकी apps बंद, power saving off, और गर्म phone को ठंडा होने दें, क्योंकि गर्मी processor को धीमा कर देती है।
हर measurement दोहराएँ (दस runs आम choice है) और median, यानी sorted runs की बीच वाली value, सबसे कम से सबसे ज़्यादा run तक के spread के साथ report करें; एक run कुछ साबित नहीं करता। उसी तरीके से मापे गए पिछले release से तुलना करें: इससे regression दिखता है, भले किसी ने target तय न किया हो। आपके lab numbers problems reproduce करते हैं और fixes confirm करते हैं; Android vitals और Xcode Organizer का field data दिखाता है कि कई devices पर असली users क्या अनुभव करते हैं।
# Android: release build on a real device, adb from the SDK platform tools
adb shell am force-stop com.example.shop # the next launch is a cold start
adb shell am start -W -n com.example.shop/.MainActivity
# TotalTime: 1873 # ms to the first frame, about TTID
adb logcat -d | grep "Fully drawn" # TTFD, if the app reports it
# ... Fully drawn com.example.shop/.MainActivity: +2s105ms
adb shell dumpsys gfxinfo com.example.shop reset # clear the frame statistics
# ...scroll the list for 30 seconds...
adb shell dumpsys gfxinfo com.example.shop # janky frames, frame percentiles
adb shell dumpsys meminfo com.example.shop # memory used by the app process
adb shell dumpsys batterystats --reset # start a battery session
# ...unplug the phone, use the app for 30 minutes, plug it back in...
adb shell dumpsys batterystats com.example.shop # the app's use since the reset
# iOS: Xcode > Product > Profile opens Instruments with templates such as
# App Launch, Time Profiler, Animation Hitches, Allocations, Leaks, Networkअसली network conditions में टेस्टिंग
Scenarios guide ने दिखाया कि networks कैसे बदलें और offline states कैसे लाएँ। Performance के लिए सवाल हैं: user कितना इंतज़ार करता है, और कमज़ोर connection पर app कितना data खर्च करता है? Profiles का एक तय set इस्तेमाल करें ताकि results तुलना लायक रहें, जैसे अच्छा Wi-Fi, typical 4G और high latency व कुछ loss वाला 3G जैसा कमज़ोर profile। Android emulator speed और delay set करता है, iOS का Network Link Conditioner 3G, Edge और Very Bad Network जैसे profiles देता है, और throttling proxy या सीमित test Wi-Fi असली Android devices को cover करता है।
Sequential requests के साथ latency जुड़ती जाती है: 300 ms प्रति round trip पर एक के बाद एक छह calls सिर्फ़ network के इंतज़ार में कम से कम 1.8 s लेती हैं। Bandwidth size को सज़ा देती है: 2 MB का response जो office Wi-Fi पर किसी को पता नहीं चलता, धीमे connection पर कई seconds लेता है। पूछें कि हर key screen कितनी requests भेजती है और वे कितनी बड़ी हैं, और जाँचें कि responses compressed हैं और images उसी size में आती हैं जिसमें screen उन्हें दिखाती है।
- हर profile पर tap से usable screen तक का समय, screen recording या app की अपनी timing से।
- इंतज़ार के दौरान feedback: loading state तुरंत दिखे और screen responsive रहे।
- Timeouts और retries: अटका हुआ request साफ़ message के साथ खत्म हो, और retries traffic को कई गुना न करें।
- API time अलग से मापें, ताकि पता चले कि delay server का है, network का या app का।
आज़माएँ: रिस्पॉन्स साइज़ एनालाइज़र आज़माएँ: API स्टेटस कोड सिम्युलेटर आज़माएँ: रिस्पॉन्स टाइम एनालाइज़र
Worked example: अटकती restaurant list
एक food delivery app version 3.2 की तैयारी में है, और release candidate आज़मा रहे साथी कहते हैं कि सस्ते phones पर restaurant list "भारी लगती है"। Tester release candidate और, तुलना के लिए, current version 3.1.4 को सबसे कमज़ोर supported Android phone (60 Hz display) पर install करता है, standard test account से sign in करता है, 30 seconds तक list को आख़िर तक और वापस scroll करता है, और frame व memory statistics इकट्ठा करता है। हर version के तीन runs नीचे के median values देते हैं।
Frame statistics शिकायत की पुष्टि करती हैं: नया version उन्हीं 30 seconds में कम frames render करता है, और उनमें से कहीं ज़्यादा frames budget से चूकते हैं (38 ms के 90th percentile का मतलब है कि हर दस में से एक frame को 38 ms या ज़्यादा लगे)। Network traffic एक संभावित वजह दिखाता है: हर restaurant card अब 600 KB की photo download करता है जिसे phone छोटे thumbnail में बदलता है, और बड़ी images को decode और छोटा करना processor का समय और memory दोनों खाता है, जिससे frames देर से बनते हैं।
- Verdict: 3.1.4 की तुलना में हर frame measure और memory पर performance regression; janky frames 4.1 % से 27.8 % हो गए।
- Bug report title: "Restaurant list scroll: low-end Android पर 27.8 % janky frames, 3.1.4 में 4.1 %", साथ में device, build, steps, table, screen recording और size के साथ एक image URL।
- संभावित वजह की पुष्टि developer करेगा; अपेक्षित fix है display size वाले thumbnails भेजना।
- Confirmation testing उसी device पर वही scenario दोहराकर हर row की तुलना करता है; फिर यह scenario हर release की performance checklist में जुड़ जाता है।
Device: lowest-end supported Android phone, 60 Hz display, release builds
Scenario: restaurant list, scroll to the end and back for 30 s, median of 3 runs
3.1.4 (current) 3.2.0-rc1
Total frames rendered 1,710 1,240
Janky frames 4.1 % 27.8 %
90th percentile frame time 14 ms 38 ms
99th percentile frame time 31 ms 160 ms
Memory after scroll (meminfo) 160 MB 410 MB
Photo per restaurant card 45 KB 600 KBआम गलतियाँ
- Developer के flagship phone या emulator पर मापना और result को app की performance बताना।
- Debug build मापना और ऐसी slowness report करना जो release build में है ही नहीं।
- एक run को result मान लेना; startup और frame numbers बदलते रहते हैं, इसलिए कई runs और उनका median लें।
- हर launch को cold start कहना। अगर process अभी चल रहा था, तो आपने warm या hot start मापा; पहले उसे रोकें।
- Memory और battery को पाँच मिनट के sessions में टेस्ट करना। Leaks और drain को repetition और समय चाहिए: वही flow बीस बार, 30 मिनट का session, background में एक घंटा।
- सिर्फ़ office Wi-Fi पर टेस्ट करना, या सिर्फ़ यह जाँचना कि offline mode चलता है, और यह न मापना कि धीमे connection पर user कितना इंतज़ार करता है।
QA का नज़रिया
Team में mobile performance का काम targets से शुरू होता है। Product owner और developers से हर key journey का budget माँगें, जैसे सबसे कमज़ोर supported device पर cold start से usable home screen तक का समय और main list की smooth scrolling। जहाँ किसी के पास number नहीं, वहाँ पिछला release baseline है, और साफ़ regression को defect के रूप में report किया जाता है।
हर release candidate के लिए एक छोटी performance checklist रखें: वही devices, build type, scenarios और network profiles, और results पिछले release के बगल में एक table में, raw output और recordings attach करके। Release के बाद developers के साथ Android vitals और Xcode Organizer पढ़ें: users के devices वे problems ढूँढते हैं जो आपके lab से छूट गईं, और हर एक ऐसा lab scenario बनती है जिसे आप दोहरा सकें।
अभ्यास
Release candidate के performance results परखें
आपने एक shopping app के release candidate 5.4 को current release 5.3 के सामने सबसे कमज़ोर supported Android phone पर टेस्ट किया, release builds और इस lesson के तरीके से। हर row के लिए तय करें: क्या यह report करने लायक regression है, normal variation के अंदर का result है, या और मापने की वजह? फिर सबसे ज़रूरी bug report का title लिखें।
App: shopping, lowest-end supported Android phone, release builds, office Wi-Fi
Startup rows: median of 10 cold starts after force-stop, (min-max) in brackets
Measure 5.3 5.4
Cold start, first frame (TTID) 1.4 s (1.3-1.6) 1.5 s (1.3-1.7)
Cold start, home ready (TTFD) 2.1 s (1.9-2.4) 3.9 s (3.6-4.3)
Janky frames, search results scroll 6 % 7 %
Memory before -> after 20x product 142 -> 147 MB 142 -> 236 MB
Battery used, 30-minute browse 4 % 4 %
Home screen requests / transferred 7 / 480 KB 19 / 2.6 MB- 5.4 की हर row की 5.3 से तुलना करें और फ़र्क लिखें।
- दिए गए spread की मदद से तय करें कि कौन से फ़र्क runs के बीच के variation से बड़े हैं।
- Rows को जोड़ें: कौन सा result किसी दूसरे को समझा सकता है?
- Measure, numbers, device और तुलना के साथ bug report का title लिखें।
मॉडल उत्तर दिखाएँ
TTID: 1.5 s बनाम 1.4 s, और spreads overlap करते हैं (1.3–1.6 और 1.3–1.7)। Normal variation के अंदर; report नहीं।
TTFD: 3.9 s बनाम 2.1 s, और spreads overlap नहीं करते। यह साफ़ regression है जिसे report करना है: usable home screen के लिए user 1.8 s ज़्यादा इंतज़ार करता है। Android vitals की 5 s limit इसे बरी नहीं करती, क्योंकि वह limit first frame के लिए है और यहाँ पिछला release ही baseline है।
Home screen requests: 19 requests और 2.6 MB बनाम 7 और 480 KB। यह शायद TTFD regression की वजह है और धीमे connection पर कहीं ज़्यादा बुरा होगा, इसलिए कमज़ोर 3G profile पर भी TTFD मापें और दोनों results attach करें।
Memory: product को 20 बार खोलने के बाद 5.3 अपने baseline के करीब लौटता है (+5 MB), जबकि 5.4 94 MB ज़्यादा रखे रहता है। Repetition के साथ बढ़ती memory product screen में leak की ओर इशारा करती है; steps के साथ report करें और developer से heap dump (memory में मौजूद objects का snapshot) analyse करने को कहें।
Janky frames 6 % बनाम 7 %, और battery 4 % बनाम 4 %: कोई मायने वाला बदलाव नहीं। Battery reading पूरे percent में बदलती है, इसलिए वह सिर्फ़ बड़े फ़र्क दिखा सकती है; इसे note करें और आगे बढ़ें।
Bug report title: "5.4 में cold start से usable home screen तक 3.9 s, 5.3 में 2.1 s (10 runs का median, सबसे कमज़ोर Android)"। दूसरी report product screen पर memory growth को cover करती है।
अक्सर पूछे जाने वाले सवाल
Cold, warm और hot start में क्या फ़र्क है?
Cold start app का process शून्य से बनाता है, इसलिए यह सबसे धीमा है और इसे सबसे पहले मापना चाहिए। Warm start मौजूद चीज़ों का कुछ हिस्सा दोबारा इस्तेमाल करता है, जैसे पहले से चल रहा process, पर screen फिर से बनाता है। Hot start सिर्फ़ मौजूद screen को सामने लाता है। Cold start मापना पक्का करने के लिए process रोकें (जैसे adb shell am force-stop से)।
किस device पर मापूँ?
उस सबसे कमज़ोर device से शुरू करें जिसे आप officially support करते हैं, क्योंकि problems वहीं सबसे पहले और सबसे बड़े रूप में दिखती हैं। एक common mid-range device जोड़ें, और frame rate के लिए high-refresh display वाला एक device, जहाँ frame budget छोटा है। Emulators और simulators network profiles और functional checks के लिए उपयोगी हैं, timing के लिए नहीं।
क्या mobile performance checks automate हो सकते हैं?
कुछ हद तक। Android पर Jetpack Macrobenchmark library असली device पर startup और frame timing मापती है; iOS पर XCTest performance tests XCTApplicationLaunchMetric और ऐसी ही metric classes से launch time, memory और दूसरे metrics माप सकते हैं। Automated runs builds के बीच regression पकड़ने में अच्छे हैं, पर असली devices पर exploratory sessions और users का field data फिर भी ज़रूरी हैं।
क्या mobile performance testing और back end की load testing एक ही हैं?
नहीं। Load testing जाँचती है कि server एक साथ कई users के साथ कैसा व्यवहार करता है। Mobile performance testing एक user के device को देखती है: startup, smoothness, memory, battery और असली network पर इंतज़ार का समय। धीमा API दोनों पर असर डालता है, इसलिए उसका response time अलग से मापें ताकि पता चले कि fix किस तरफ़ चाहिए।
संदर्भ
- Android vitalsउपयोगकर्ताओं के डिवाइस से Google Play द्वारा जुटाए गए ऐप-गुणवत्ता मेट्रिक्स — core vitals में user-perceived crash और ANR rate — और वे bad-behavior thresholds जो ऐप की दृश्यता पर असर डालते हैं।
- Certified Tester Mobile Application Testing (CT-MAT)मोबाइल टेस्टिंग पर ISTQB का specialist पाठ्यक्रम: ऐप के प्रकार, डिवाइस व प्लेटफ़ॉर्म की चुनौतियाँ, टेस्ट प्रकार और टूल।
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelउत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
- XCTestiOS और अन्य Apple प्लेटफ़ॉर्म पर Xcode प्रोजेक्ट के unit, performance और UI टेस्ट के लिए Apple का फ़्रेमवर्क।
Mutqan tools से अभ्यास करें
रिस्पॉन्स साइज़ का विश्लेषण: कच्चे बनाम compressed बाइट, हेडर का साइज़, JSON ढाँचे का भार और सबसे बड़े फ़ील्ड।
ऐसा सार्वजनिक endpoint पाएँ जो कोई भी HTTP स्टेटस कोड लौटाए, वैकल्पिक देरी और कस्टम JSON बॉडी के साथ, ताकि क्लाइंट की error हैंडलिंग टेस्ट हो सके।
किसी endpoint का रिस्पॉन्स टाइम कई सैंपल पर मापें: न्यूनतम, अधिकतम, औसत, माध्यिका और p95।
byte, KB, MB, GB, TB (दशमलव SI) और KiB, MiB, GiB (बाइनरी IEC) के बीच बदलें, साथ में bit भी।
और गहराई से
इस topic में आपकी प्रगति
प्रगति ट्रैक करने के लिए साइन इन करें
Topics पूर्ण चिह्नित करें, जहाँ छोड़ा था वहीं से जारी रखें और specialisation परीक्षाएँ खोलें।