स्पंदन फ्रेमवर्क डिफ़ॉल्ट रूप से ठीक और तेज काम करता है, लेकिन इसका मतलब यह है कि आपको प्रदर्शन के बारे में सोचने की ज़रूरत नहीं है? नहीं। यह स्पंदन अनुप्रयोगों को लिखने के लिए बिल्कुल वास्तविक है जो धीमा होगा। दूसरी ओर, आप फ्रेमवर्क का अधिकतम उपयोग कर सकते हैं और अपने अनुप्रयोगों को न केवल तेज, बल्कि कुशल बना सकते हैं, कम प्रोसेसर और बैटरी समय का उपभोग कर सकते हैं।

यह वही है जो हम देखना चाहते हैं: कुछ महत्वपूर्ण मीट्रिक द्वारा आपके आवेदन के दो संस्करणों की तुलना करने का एक सांख्यिकीय महत्वपूर्ण परिणाम। कैसे पता लगाने के लिए आगे पढ़ें।

स्पंदन में प्रदर्शन के अनुकूलन के लिए कुछ सामान्य दिशानिर्देश हैं:

• स्थिति को अपडेट करते समय यथासंभव कुछ विजेट संलग्न करें।
• जरूरी होने पर ही स्टेटस अपडेट करें।
• अपने build तरीकों से कम्प्यूटेशनल रूप से गहन कार्यों को बाहर निकालें और आदर्श रूप से मुख्य आइसोलेट से।

दुखद सच्चाई यह है कि प्रदर्शन के अनुकूलन के बारे में कई सवालों के लिए, जवाब "कितना भाग्यशाली होगा।" क्या यह विशेष अनुकूलन इस विशेष विजेट के लिए प्रयास और रखरखाव लागत के लायक है? क्या यह विशेष दृष्टिकोण इस विशेष स्थिति में समझ में आता है?

इन प्रश्नों का एकमात्र उपयोगी उत्तर परीक्षण और माप है। यह निर्धारित करें कि प्रत्येक विकल्प प्रदर्शन को कैसे प्रभावित करता है और इस डेटा के आधार पर निर्णय लेते हैं।

अच्छी खबर यह है कि फ़्लटर डार्ट DevTools (वर्तमान में पूर्वावलोकन रिलीज) जैसे महान प्रदर्शन प्रोफाइलिंग उपकरण प्रदान करता है, जिसमें फ़्लटर इंस्पेक्टर शामिल है, या आप फ़्लटर इंस्पेक्टर को सीधे एंड्रॉइड स्टूडियो (स्थापित फ़्लटर प्लगइन के साथ) का उपयोग कर सकते हैं। प्रदर्शन जानकारी सहेजने के लिए आपके पास अपने एप्लिकेशन और Profile mode का परीक्षण Flutter Driver लिए एक Flutter Driver है।

बुरी खबर यह है कि आधुनिक स्मार्टफोन बहुत स्मार्ट हैं।

नियामकों के साथ समस्या

फ़्लटर अनुप्रयोग प्रदर्शन को बढ़ाना iOS और Android नियंत्रकों के लिए विशेष रूप से कठिन है। ये सिस्टम-स्तरीय डेमॉन लोड के आधार पर केंद्रीय और ग्राफिक प्रोसेसर की गति को नियंत्रित करते हैं। बेशक, मूल रूप से यह अच्छा है, क्योंकि यह कम बैटरी खपत के साथ सुचारू संचालन प्रदान करता है।

नुकसान यह है कि आप अपने काम को बहुत तेज कर सकते हैं, जिससे यह काम करता है।

नीचे आप देख सकते हैं कि कैसे एप्लिकेशन को अर्थहीन प्रिंट कॉल का एक चक्र जोड़कर नियामक ने सीपीयू को एक बढ़ी हुई आवृत्ति पर स्विच किया, जिससे एप्लिकेशन बहुत तेज हो गया और इसका प्रदर्शन अधिक पूर्वानुमानित हो गया।

नियामकों के साथ समस्या: डिफ़ॉल्ट रूप से, आप अपनी संख्या पर भरोसा नहीं कर सकते। इस स्पैन आरेख में, हमारे पास एक्स अक्ष पर अलग-अलग रन होते हैं (सटीक समय वे शुरू हुए द्वारा चिह्नित) और वाई अक्ष पर समय का निर्माण करते हैं। जैसा कि आप देख सकते हैं, जब हम कुछ पूरी तरह से अनावश्यक प्रिंट स्टेटमेंट पेश करते हैं, तो यह इस तथ्य की ओर जाता है कि बिल्ड समय कम हो जाता है। लेकिन नहीं।

इस प्रयोग में, सबसे खराब कोड में तेजी से बिल्ड टाइम (ऊपर देखें), तेजी से रेखांकन समय और उच्च फ्रेम दर के परिणामस्वरूप हुआ। जब उद्देश्यपूर्ण रूप से बदतर कोड बेहतर प्रदर्शन संकेतकों की ओर जाता है, तो आप इन संकेतकों पर एक गाइड (सिफारिश) के रूप में भरोसा नहीं कर सकते।

यह केवल एक उदाहरण है कि मोबाइल ऐप के प्रदर्शन का परीक्षण कैसे अनपेक्षित और जटिल हो सकता है।

नीचे, मैं कुछ युक्तियों को साझा करता हूं जो मैंने Google I / O के लिए Flutter के डेवलपर क्वेस्ट एप्लिकेशन पर काम करते समय एकत्र किए थे।

सामान्य टिप्स

• डिबग मोड ( DEBUG mode ) में प्रदर्शन को मापें नहीं। केवल प्रोफ़ाइल Profile mode में प्रदर्शन मापें।
• एक असली डिवाइस पर मापें, आईओएस सिम्युलेटर या एंड्रॉइड एमुलेटर पर नहीं। सॉफ्टवेयर एमुलेटर विकास के लिए महान हैं, लेकिन प्रदर्शन विशेषताओं में वास्तविक से अलग हैं। स्पंदन आपको नकली डिवाइस पर प्रोफाइलिंग मोड में काम करने की अनुमति नहीं देगा, क्योंकि इसका कोई मतलब नहीं है। इस तरह से आपके द्वारा एकत्र किया गया डेटा वास्तविक प्रदर्शन पर लागू नहीं होता है।
• आदर्श रूप में सटीक एक ही भौतिक उपकरण का उपयोग करें। इसे अपना समर्पित प्रदर्शन परीक्षण उपकरण बनाएं और इसे किसी और चीज़ के लिए कभी उपयोग न करें।
• स्पंदन प्रदर्शन प्रोफ़ाइल उपकरण का अन्वेषण करें।

सीपीयू / जीपीयू रेगुलेटर

जैसा कि ऊपर चर्चा की गई है, आधुनिक ऑपरेटिंग सिस्टम प्रत्येक प्रोसेसर और GPU की आवृत्ति को लोड और कुछ अन्य आंकड़ों के अनुसार उनके निपटान में बदलते हैं। (उदाहरण के लिए, स्क्रीन को छूने से आमतौर पर आपके एंड्रॉइड फोन की गति बढ़ जाएगी।)

Android पर, आप इन नियंत्रणों को अक्षम कर सकते हैं। हम इस प्रक्रिया को "स्केलिंग लॉक" कहते हैं।

• एक स्क्रिप्ट बनाएं जो प्रदर्शन का परीक्षण करने के लिए आपके डिवाइस पर नियंत्रण को निष्क्रिय करता है। आप प्रेरणा के लिए स्कीया उदाहरण का उपयोग कर सकते हैं। आप यूनिक्स सीपीयू एपीआई की जांच भी कर सकते हैं।
• आप कुछ कम बहुमुखी और हल्का चाहते हैं यदि आप स्कीया के रूप में अधिक परीक्षण कार्य नहीं करते हैं। डेवलपर क्वेस्ट में शेल स्क्रिप्ट देखें कि कहां जाना है। उदाहरण के लिए, स्क्रिप्ट का अगला भाग यूजरस्पेस नियंत्रक के लिए सीपीयू सेट करता है (केवल नियंत्रक जो प्रोसेसर आवृत्ति को स्वयं नहीं बदलता है)।
  

   #!/usr/bin/env bash GOV="userspace" echo "Setting CPU governor to: ${GOV}" adb shell "echo ${GOV} > /sys/devices/system/cpu/cpu${CPU_NO}/cpufreq/scaling_governor" ACTUAL_GOV=`adb shell "cat /sys/devices/system/cpu/cpu${CPU_NO}/cpufreq/scaling_governor"` echo "- result: ${ACTUAL_GOV}" 

• यहां आपका लक्ष्य वास्तविक प्रदर्शन का अनुकरण करना नहीं है (उपयोगकर्ता अपने उपकरणों पर नियामकों को बंद नहीं करते हैं), लेकिन रन के बीच तुलनीय प्रदर्शन संकेतक हैं।
• अंत में, आपको शेल स्क्रिप्ट का उपयोग करने और उस डिवाइस को अनुकूलित करने की आवश्यकता है जिसे आप उपयोग करेंगे। यह काम करता है, लेकिन जब तक आप ऐसा नहीं करते, तब तक आपका प्रदर्शन डेटा आपको धोखा देगा।

डेवलपर क्वेस्ट का एक प्रारंभिक संस्करण, मेरे डेस्कटॉप पर फ़्लटर चालक के साथ परीक्षण किया गया।

स्पंदन चालक

स्पंदन चालक आपको स्वचालित रूप से अपने आवेदन का परीक्षण करने की अनुमति देता है। Flutter.dev पर "प्रदर्शन रूपरेखा" अनुभाग पढ़ें, यह पता लगाने के लिए कि आपके आवेदन को रूपरेखा करते समय इसका उपयोग कैसे करें।

• प्रदर्शन का परीक्षण करने के लिए, मैन्युअल रूप से अपने आवेदन का परीक्षण न करें। वास्तव में सूचक डेटा प्राप्त करने के लिए हमेशा फ़्लटर ड्राइवर का उपयोग करें।
• अपना फ़्लटर ड्राइवर कोड लिखें ताकि यह जांचे कि आप वास्तव में क्या मापना चाहते हैं। यदि आपको समग्र अनुप्रयोग प्रदर्शन की आवश्यकता है, तो आवेदन के सभी भागों के माध्यम से जाने की कोशिश करें और उपयोगकर्ता क्या करेंगे।
• यदि आपके आवेदन में यादृच्छिकता ( Random , नेटवर्क ईवेंट आदि) का एक तत्व है, तो ऐसी स्थितियों के लिए "नकली" बनाएं। टेस्ट रन जितना संभव हो उतना एक दूसरे के करीब होना चाहिए।
• यदि आप चाहते हैं, तो आप टाइमलाइन वर्ग के startSync() और finishSync() विधियों का उपयोग करके समय के लिए कस्टम ईवेंट जोड़ सकते हैं। यह उपयोगी हो सकता है यदि आप किसी विशेष कार्य के प्रदर्शन में रुचि रखते हैं। इसके अंत में finishSync() डालें और इसके अंत में finishSync() डालें।
• दोनों सारांश ( राइटसमैरीटॉइफ़ाइल ) और, अधिक महत्वपूर्ण बात, कच्ची समयरेखा ( राइटट्रीमलाइनटॉफ़ल ) को सहेजें ।
• अपने आवेदन के प्रत्येक संस्करण का कई बार परीक्षण करें। डेवलपर क्वेस्ट के लिए, मैंने 100 शुरू किए। (जब आप ऐसी चीज़ों को मापते हैं जो शोर हो सकती हैं, जैसे कि p99 मीट्रिक का उपयोग करना, तो आपको बहुत अधिक रन की आवश्यकता हो सकती है।) पोसिक्स-आधारित सिस्टम के लिए, इसका for i in {1..100}; do flutter drive --target=test_driver/perf.dart --profile; done अर्थ है कि निम्नलिखित कुछ करना: for i in {1..100}; do flutter drive --target=test_driver/perf.dart --profile; done for i in {1..100}; do flutter drive --target=test_driver/perf.dart --profile; done for i in {1..100}; do flutter drive --target=test_driver/perf.dart --profile; done ।
  

Flutter में प्रोफाइलिंग परिणामों की जाँच के लिए Chrome का समयरेखा उपकरण।

समय

टाइमलाइन आपके प्रोफाइलिंग परिणामों का कच्चा आउटपुट है। स्पंदन इस जानकारी को JSON फ़ाइल में लिखता है, जिसे chrome://tracing में डाउनलोड किया जा सकता है।

• समझें कि क्रोम में पूर्ण समयरेखा कैसे खोलें। आप बस क्रोम ब्राउज़र में chrome://tracing खोलते हैं chrome://tracing “लोड” पर क्लिक करें और JSON फ़ाइल चुनें। आप इस लघु मार्गदर्शिका में और अधिक पढ़ सकते हैं। ( एक फ़्लटर टाइमलाइन टूल भी है जो वर्तमान में तकनीकी पूर्वावलोकन में है। मैंने इसका इस्तेमाल नहीं किया क्योंकि फ़्लटर टूल तैयार होने से पहले डेवलपर क्वेस्ट प्रोजेक्ट लॉन्च किया गया था।)
• ऑपरेटिंग मोड को बदलने के लिए chrome://tracing में टाइमलाइन नेविगेट करने के लिए WSAD कुंजियों का उपयोग करें chrome://tracing और 1234।
• पहली बार प्रदर्शन परीक्षण स्थापित करते समय, सिस्ट्रेस एंड्रॉइड टूल के साथ फ़्लटर ड्राइवर चलाने पर विचार करें। यह आपको एक बेहतर विचार देता है कि वास्तव में डिवाइस में क्या चल रहा है, जिसमें प्रोसेसर आवृत्ति को स्केल करने की जानकारी भी शामिल है। सिस्ट्रेस के साथ पूरे आवेदन को न मापें, क्योंकि इससे सब कुछ धीमा और कम अनुमानित होगा।
• फ़्लटर ड्राइवर के साथ एंड्रॉइड सिस्ट्रेस कैसे चलाएं? सबसे पहले, एंड्रॉइड /path/to/your/android/sdk/platform-tools/systrace/systrace.py --atrace-categories=gfx,input,view,webview,wm,am,sm,audio,video,camera,hal,app,res,dalvik,rs,bionic,power,pm,ss,database,network,adb,pdx,sched,irq,freq,idle,disk,load,workq,memreclaim,regulators,binder_driver,binder_lock को /path/to/your/android/sdk/platform-tools/systrace/systrace.py --atrace-categories=gfx,input,view,webview,wm,am,sm,audio,video,camera,hal,app,res,dalvik,rs,bionic,power,pm,ss,database,network,adb,pdx,sched,irq,freq,idle,disk,load,workq,memreclaim,regulators,binder_driver,binder_lock साथ लॉन्च /path/to/your/android/sdk/platform-tools/systrace/systrace.py --atrace-categories=gfx,input,view,webview,wm,am,sm,audio,video,camera,hal,app,res,dalvik,rs,bionic,power,pm,ss,database,network,adb,pdx,sched,irq,freq,idle,disk,load,workq,memreclaim,regulators,binder_driver,binder_lock । फिर flutter run test_driver/perf.dart --profile --trace-systrace एप्लिकेशन flutter run test_driver/perf.dart --profile --trace-systrace । अंत में, flutter drive --driver=test_driver/perf_test.dart --use-existing-app=http://127.0.0.1:NNNNN/ ड्राइवर flutter drive --driver=test_driver/perf_test.dart --use-existing-app=http://127.0.0.1:NNNNN/ (जहाँ NNNNN पोर्ट है जो आपको flutter drive --driver=test_driver/perf_test.dart --use-existing-app=http://127.0.0.1:NNNNN/ देता है) को flutter drive --driver=test_driver/perf_test.dart --use-existing-app=http://127.0.0.1:NNNNN/ ।

मैट्रिक्स

जितना संभव हो उतने मीट्रिक देखना बेहतर है, लेकिन मैंने तय किया कि कुछ दूसरों की तुलना में अधिक उपयोगी हैं।

• निर्माण समय और रेखांकन समय (मैट्रिक्स जो TimelineSummary का उपयोग करके डिफ़ॉल्ट रूप से प्रदान किया जाता है) केवल वास्तव में कठिन प्रदर्शन परीक्षणों के लिए उपयोगी होते हैं, जिसमें उपयोगकर्ता इंटरफ़ेस बनाने के अलावा बहुत कुछ शामिल नहीं होता है।

  
  

• प्रति सेकंड (एफपीएस) फ्रेम की गणना करने के तरीके के रूप में TimelineSummary.frameCount पर विचार न करें। स्पंदन प्रोफाइलिंग उपकरण वास्तविक फ्रेम दर की जानकारी प्रदान नहीं करते हैं। TimelineSummary countFrames() विधि प्रदान करता है, लेकिन यह केवल पूर्ण फ़्रेम असेंबलियों की संख्या की गणना करता है। एक अच्छी तरह से अनुकूलित अनुप्रयोग जो अनावश्यक रीबिल्ड्स (अपडेट) को सीमित करता है, एक अडॉप्ट किए गए एप्लिकेशन की तुलना में कम एफपीएस होगा जो अक्सर पुनर्निर्मित करता है।

  
  

• व्यक्तिगत रूप से, मुझे डार्ट कोड को निष्पादित करने के लिए खर्च किए गए कुल प्रोसेसर समय को मापकर सबसे उपयोगी डेटा मिलता है। यह आपके build तरीकों और उनके बाहर निष्पादित कोड को गिनता है। मान लें कि आप स्केल-लॉक डिवाइस पर प्रोफाइलिंग टेस्ट चलाते हैं, तो कुल सीपीयू समय को एक अच्छा अनुमान माना जा सकता है कि आपका एप्लिकेशन कितनी अधिक / कम बैटरी का उपभोग करेगा।
  

  
  

• डार्ट कोड को निष्पादित करने वाले कुल प्रोसेसर समय का पता लगाने का सबसे आसान तरीका MessageLoop:FlushTasks की संख्या का अनुमान MessageLoop:FlushTasks समय पर MessageLoop:FlushTasks इवेंट। डेवलपर क्वेस्ट के लिए, मैंने उन्हें निकालने के लिए एक डार्ट टूल लिखा।

  
  

• कबाड़ (कचरा) (यानी, गिरा हुआ फ्रेम) खोजने के लिए, चरम सीमाओं की तलाश करें। उदाहरण के लिए, डेवलपर क्वेस्ट के एक विशिष्ट मामले और जिस डिवाइस पर हमने परीक्षण किया, वह 95 वें प्रतिशत के निर्माण के समय पर एक नज़र रखना उपयोगी है। (90 वें प्रतिशताइल का निर्माण समय भी समान था, भले ही आप कोड की तुलना प्रदर्शन के विभिन्न स्तरों के साथ करते हों, और 99 वें प्रतिशताइल की संख्या आमतौर पर शोर होती है। आपका प्रदर्शन भिन्न हो सकता है।)
  

  
  

• जैसा कि ऊपर उल्लेख किया गया है, अपने आवेदन के प्रत्येक संस्करण का परीक्षण कई (शायद 100) बार करें। फिर त्रुटि क्षेत्रों के साथ औसत या प्रतिशत डेटा का उपयोग करें। बेहतर अभी तक, स्पैन चार्ट का उपयोग करें।

  
  

परिणाम

ट्यूनिंग के बाद, आप आत्मविश्वास से तुलना और प्रयोगों का संचालन कर सकते हैं। नीचे आप एक सामान्य दुविधा का उत्तर देख सकते हैं: "क्या यह रखरखाव लागत का अनुकूलन है?"

मुझे लगता है कि इस विशेष मामले में जवाब हां है। कोड की कुछ पंक्तियों के लिए धन्यवाद, हमारे आवेदन के प्रत्येक स्वचालित मार्ग में औसतन 12% कम सीपीयू समय लगता है।

लेकिन - और यह इस लेख का मुख्य संदेश है - एक और अनुकूलन का माप कुछ पूरी तरह से अलग दिखा सकता है। मोटे तौर पर एक प्रदर्शन माप को अतिरिक्त रूप से फैलाने की कोशिश करना गलत है, लेकिन यह गलत है।

दूसरे शब्दों में: "कितना भाग्यशाली है।" और हमें इसके साथ लगना होगा।