फोनगैप: ऐप को उत्तरदायी कैसे बनाया जाए

आज तक, PhoneGap के बारे में काफी संख्या में समीक्षा लेख हैं, लेकिन दुर्भाग्य से, वे या तो फ्रंट-एंड डेवलपर्स द्वारा लिखे गए थे, जिन्होंने मोबाइल प्लेटफ़ॉर्म लेने का फैसला किया था, या देशी प्रोग्रामर जिन्होंने क्रॉस-प्लेटफॉर्म विकास में खुद को आज़माने का फैसला किया था। और यह इस दृष्टिकोण से है कि फोनगैप के फायदे और नुकसान पर विचार किया जाता है, लेख "क्रॉस-प्लेटफॉर्म कितना अच्छा है", या "क्रॉस-प्लेटफॉर्म समाधानों की हीनता" के बारे में उठता है।

बीज के रूप में - 6 घंटे में लिखा गया वीडियो डेमो एप्लिकेशन; 3.5 घंटे के लिए तैयार यूआई बूटस्ट्रैप, पुस्तकालयों iScroll, backbone, underscore, Jquery और बैकबोन पर एक छोटा आवरण (RAD.js - रैपिड एप्लिकेशन डेवलपमेंट, एक आर्किटेक्चरल फ्रेमवर्क जो मोबाइल रनटाइम से संबंधित अनुकूलन का हिस्सा होता है) का उपयोग किया।


इंजन को ठीक करने में एक और 2 घंटे का समय लगा। लेकिन आज यह कुछ धीमा नहीं है, ट्विचिंग या स्व-लिखित स्वाइप हमेशा समय के साथ 14,000 डेटा ऑब्जेक्ट पर काम नहीं कर रहा है; यह आपके बारे में क्या कर सकता है और आपको PhoneGap पर लिखना चाहिए।

हम आपके ध्यान में उन लोगों की राय लाते हैं जो फोनगैप पर क्रॉस-प्लेटफॉर्म डेवलपमेंट में लगे हुए हैं, इस बारे में बात करने के लिए कि फोनगैप पर विकास करते समय हमें क्या-क्या सूक्ष्मताएं आवश्यक और महत्वपूर्ण लगती हैं, और वे इतनी महत्वपूर्ण क्यों हैं।

PhoneGap सात मोबाइल ऑपरेटिंग प्लेटफॉर्म के लिए HTML / जावास्क्रिप्ट के लिए एक क्रॉस-प्लेटफॉर्म डेवलपमेंट प्लेटफॉर्म के रूप में तैनात है ।

PhoneGap में क्रॉस-प्लेटफ़ॉर्म इस तथ्य से प्राप्त होता है कि आपके HTML / JavaScript एप्लिकेशन का कोड webView घटक (जो कि एप्लिकेशन में निर्मित ब्राउज़र है) में निष्पादित होता है।

वास्तव में, PhoneGap एप्लिकेशन का विकास रनटाइम वातावरण (मोबाइल डिवाइस, सीमित प्रोसेसर शक्ति, मेमोरी, टचस्क्रीन, आदि) और ... ब्राउज़र चिड़ियाघर की बारीकियों को ध्यान में रखते हुए HTML5 अनुप्रयोग का विकास है।
जैसे डेस्कटॉप ब्राउज़र के लिए विकसित करते समय, मोबाइल साइटों या फोनगैप एप्लिकेशन को विकसित करते समय, आपको प्रत्येक ऑपरेटिंग सिस्टम और उसके डिफ़ॉल्ट ब्राउज़र की बारीकियों को जानना और लेना होगा, जिसके आधार पर webView घटक बनाया गया है।

और सबसे महत्वपूर्ण बात यह है कि सीमित मोबाइल फोन गैप एप्लिकेशन रनटाइम और संसाधनों से जो प्रभावित होता है वह यूजर इंटरफेस की जवाबदेही है।

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

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

हम इसके विपरीत, बारीकियों और बारीकियों पर ध्यान देना चाहेंगे, जिन पर अक्सर ध्यान नहीं दिया जाता है, लेकिन अंत में यह उपयोगकर्ता के लिए निर्णायक भूमिका निभाने लगता है।

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

हम उन समस्याओं के बारे में बताते हैं जिन्हें हम विशेषता मानते हैं, और जिन पर हम आज विचार करना चाहते हैं:

• "स्पर्श" उपकरणों पर "क्लिक" घटना के 300 मिलीसेकंड की देरी;
• स्पर्श की समस्या
• डोम संरचना अनुकूलन;
• बड़ी सूची की समस्या।

शायद हम खुद को किसी चीज़ में दोहराएंगे, लेकिन फिर भी हम शुरू कर देंगे।

300 एमएस देरी की समस्या:

उनके ब्राउज़र में अधिकांश मोबाइल ऑपरेटिंग सिस्टम (और परिणामस्वरूप, webView में) झूठे स्पर्श की समस्या को हल करने के लिए DOM में "क्लिक" इवेंट को सीधे क्लिक करने और ट्रिगर करने के बीच लगभग 300 मिली सेकेंड की विशेष देरी का परिचय देते हैं।

इस समस्या को हल करने के लिए एक दृष्टिकोण इंटरनेट पर खोजना मुश्किल नहीं है। कम से कम कुछ दर्जन जावास्क्रिप्ट पुस्तकालय हैं जो इस समस्या को हल करते हैं। उन सभी के संचालन का सिद्धांत समान है - "टचस्टार्ट" और "टचेंड" की घटनाओं को ट्रैक करने के लिए - और अंतिम कॉल के अंत में घटना "क्लिक" या एक समान कस्टम इवेंट (उदाहरण के लिए, "टैप")। उदाहरण दोनों को स्टैकओवरफ्लो पर एक समाधान के रूप में और jQuery के लिए प्लग-इन के रूप में और एक अलग पुस्तकालय के रूप में भी लागू किया जा सकता है, यहां तक ​​कि मोज़िला से या सिर्फ टिप्स के रूप में।

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

एक पुस्तकालय खोजना जो तत्वों के लिए क्लिक करते समय सही ढंग से स्थानान्तरण और सेट करता है, और एक ही समय में विभिन्न प्रकार के इनपुट क्षेत्रों के साथ सही ढंग से काम करता है, काफी मुश्किल है और, इसके अलावा, यह काफी बड़ा होगा। यह आम तौर पर स्वीकृत दृष्टिकोण का उपयोग करने के लिए बहुत सरल और अधिक दर्द रहित है - किसी भी "क्लिक" घटना को उत्पन्न करने के लिए नहीं, बल्कि किसी भी अन्य कस्टम घटना - और श्रोता को सीधे इसे टाई।

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

दूसरी समस्या स्पर्श बिंदु है:

मोबाइल उपकरणों के गलत तरीके से डिज़ाइन किए गए इंटरफेस (फोनगैप पर सहित) में एक अन्य आम समस्या उपयोगकर्ताओं के होंठों से इस प्रकार है: "मैं क्लिक करता हूं, लेकिन यह हमेशा काम नहीं करता है" या "मैं क्लिक करता हूं, लेकिन यह काम नहीं करता है"।
आइए निम्नलिखित आंकड़े पर ध्यान से विचार करें, जो दिखाता है कि उपयोगकर्ता की उंगली डिवाइस की स्क्रीन के साथ कैसे इंटरैक्ट करती है।



यह देखना आसान है कि उंगलियों के वास्तविक संपर्क का बिंदु (हरा) और दृश्य संपर्क (लाल) का बिंदु अलग है। सबसे पहले, हम आम तौर पर एक कोण पर एक मोबाइल डिवाइस को देखते हैं। दूसरे, स्क्रीन ही स्पर्श निर्देशांक उत्पन्न करती है क्योंकि उंगलियों के स्पर्श के क्षेत्र पर भार-औसत निर्देशांक होता है। हम कितनी भी कोशिश कर लें, हम उंगलियों से आदर्श घेरे में सफल नहीं हुए।

इन कारणों से, स्पर्श का वास्तविक बिंदु दृश्य के साथ कभी मेल नहीं खाएगा।

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

यह बिंदु काफी सरल रूप से तय किया गया है - आवेदन नियंत्रण का एक सक्षम लेआउट; उदाहरण के लिए, जब एक बटन में 4-6 पिक्सेल की अदृश्य गद्दी होती है यदि यह डिज़ाइन में पर्याप्त बड़ी नहीं होती है: अर्थात, इसकी पृष्ठभूमि में अदृश्य बाहरी सीमाएँ होती हैं जो उपयोगकर्ता के लिए इसके भौतिक आकार को आवश्यक और सुविधाजनक बनाती हैं (चित्र में गुलाबी बॉक्स)।



इस समस्या पर यहां विस्तार से चर्चा की गई है , और Microsoft की सिफारिशों में आप इंटरफ़ेस तत्वों के अनुशंसित आकारों को स्क्रीन आकार के आधार पर देख सकते हैं।

और अब सबसे गैर-तुच्छ चीज के बारे में - डोम संरचना के अनुकूलन के बारे में



यदि आप "औसत" एप्लिकेशन के अधिक या कम "मानक" स्क्रीन को देखते हैं, तो आप 200-300 HTML टैग (DOM नोड्स) से गिन सकते हैं जिसके साथ एप्लिकेशन स्क्रीन होने की संभावना है। इस विशेष उदाहरण में, पृष्ठ 225 HTML तत्वों का उपयोग करने की संभावना है। सबसे इष्टतम लेआउट से दूर, लेकिन हम किसी भी मामले में कितना भी प्रयास करें, किसी भी मामले में, फोनगैप एप्लिकेशन की औसत स्क्रीन 100 से 250 एचटीएमएल तत्वों की गणना कर सकती है। और हम आपको इस बात पर ध्यान देने के लिए कहते हैं कि हम अभी तक सूचियों के साथ स्क्रीन पर विचार नहीं करते हैं (हम थोड़ी देर बाद इस बारे में बात करेंगे)।

देशी एक के समान एक औसत एप्लिकेशन में पांच से डेढ़ दर्जन स्क्रीन होते हैं। PhoneGap के मामले में, ये सभी पृष्ठ एकल-पृष्ठ अनुप्रयोग का हिस्सा हैं।

इस तरह के एक अनुप्रयोग की वास्तुकला के लिए आम तौर पर स्वीकृत दृष्टिकोण है: सभी पृष्ठों को ब्लॉक के रूप में एक HTML फ़ाइल में रखा जाता है, और फिर, कार्यक्रम के निष्पादन के दौरान, किस पृष्ठ की आवश्यकता होती है, इस पर निर्भर करता है

प्रदर्शन: कोई नहीं;
प्रदर्शन: ब्लॉक;

वांछित पृष्ठ प्रदर्शित किया जाता है (उदाहरण के लिए, JqueryMobile में किया जाता है)।

लेकिन यह दृष्टिकोण, दुर्भाग्य से, पृष्ठों को स्विच करते समय एप्लिकेशन में देरी होती है (और न केवल)। और आवेदन जितना जटिल होगा, ये देरी उतनी ही लंबी होगी।

यह इस तथ्य के कारण है कि डोम को क्वेरी करने के सबसे सामान्य जावास्क्रिप्ट फ़ंक्शन के लिए भी, उदाहरण के लिए, document.querySelector ('चयनकर्ता'), निष्पादन का समय दस्तावेज़ के ऑब्जेक्ट मॉडल में नोड्स की संख्या पर निर्भर करता है। उदाहरण के लिए, तीन-स्तरीय चयनकर्ता के साथ निर्दिष्ट ऑपरेशन 100 तत्वों के लिए 0.003 एमएस में और 10,000 तत्वों (लगभग 40 एप्लिकेशन पेज) के लिए 0.36 एमएस में किया जाता है। कोई यह तर्क दे सकता है कि ये त्रिभुज हैं: 40 पृष्ठ अक्सर वास्तविक जीवन में नहीं मिलते हैं, और 0.36 एमएस एक पैसा है।

लेकिन कोई भी कभी भी शुद्ध जावास्क्रिप्ट का उपयोग नहीं करता है, और JQuery (संस्करण 2 तक) का उपयोग करते समय, निर्दिष्ट समय बढ़कर 2.46 एमएस हो जाता है। और अगर आप मानते हैं कि एक साधारण अनुरोध के अलावा, DOM के साथ कोई हेरफेर करना भी आवश्यक है, तो यह पहले से ही एक जटिल आवेदन में आंखों की देरी से भी ध्यान देने योग्य हो सकता है।

यहाँ एक छोटा सा SYNTHETIC परीक्षण है जो विभिन्न तत्वों के साथ एक दस्तावेज बनाता है और कंसोल में दो-स्तरीय CSS का चयन करने का परिणाम प्रदर्शित करता है।

क्रोम पर इसके निष्पादन का परिणाम 28.0.1500.63

1 आइटम index.js बनाना शुरू करें: 12
कोई भी 1 आइटम: 0.078ms index.js: 38
कोई नहीं jquery 1 आइटम: 0.774ms index.js: 43
ब्लॉक 1 आइटम: 0.131ms index.js: 38
ब्लॉक jquery 1 आइटम: 0.234ms index.js: 43
jquery show1 आइटम: 1.768ms index.js: 52
10 आइटम index.js बनाना शुरू करें: 12
कोई नहीं 10 आइटम: 0.071ms index.js: 38
कोई नहीं jquery 10 आइटम: 0.138ms index.js: 43
10 आइटम ब्लॉक करें: 0.139ms index.js: 38
ब्लॉक jquery 10 आइटम: 0.090ms index.js: 43
jquery show10 आइटम: 0.865ms index.js: 52
100 आइटम index.js बनाना शुरू करें: 12
कोई नहीं 100 आइटम: 0.071ms index.js: 38
कोई नहीं jquery 100 आइटम: 0.099ms index.js: 43
100 आइटम ब्लॉक करें: 0.103ms index.js: 38
ब्लॉक jquery 100 आइटम: 0.105ms index.js: 43
jquery show100 आइटम: 1.418ms index.js: 52
1000 आइटम index.js बनाना शुरू करें: 12
कोई नहीं 1000 आइटम: 0.178ms index.js: 38
कोई नहीं jquery 1000 आइटम: 0.163ms index.js: 43
1000 आइटम ब्लॉक करें: 0.156ms index.js: 38
ब्लॉक jquery 1000 आइटम: 0.176ms index.js: 43
jquery show1000 आइटम: 9.709ms index.js: 52
10000 आइटम index.js बनाना शुरू करें: 12
कोई नहीं 10000 आइटम: 2.333ms index.js: 38
कोई नहीं jquery 10000 आइटम: 2.434ms index.js: 43
10000 आइटम ब्लॉक करें: 1.810ms index.js: 38
ब्लॉक jquery 10000 आइटम: 1.810ms index.js: 43
jquery show10000 आइटम: 106.425ms

जैसा कि आप परीक्षण से देख सकते हैं, "प्रदर्शन: कोई नहीं" के साथ समाधान मदद नहीं करता है, क्योंकि यह केवल दस्तावेज़ को रेंडर करने के काम को हटा देता है, लेकिन "अनावश्यक" डोम का अनुरोध करते समय समय नहीं बदलता है।
यह समाधान हमें केवल रिफ्लो और दमन से छुटकारा पाने में मदद करता है, इन घटनाओं के दौरान ब्राउज़र का व्यवहार लेख में पूरी तरह से चर्चा करता है।

एक बार फिर, हम आपको याद दिलाते हैं कि परीक्षण सिंथेटिक है , जो वास्तविक परिस्थितियों के अनुरूप नहीं है, और कुछ पद विशेष रूप से "अभिभूत" थे। लेकिन यह पूरी तरह से एक विचार देता है कि बड़ी संख्या में पृष्ठों और जटिल लेआउट के साथ एकल-पृष्ठ एप्लिकेशन के साथ वास्तविक परियोजना में क्या हो सकता है।

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

इस मामले में, दो समाधान हैं:

• पेज पेज लोड करना अजाक्स अनुरोध के साथ;
• यदि पृष्ठ पहले से ही एक मानक दृष्टिकोण होने की संभावना है, तो इसे DOM में लोड करने के बाद, आपको मुख्य DOM पेड़ से अदृश्य पृष्ठों के लिए जिम्मेदार DOM शाखाओं को डिस्कनेक्ट करने की आवश्यकता है, ताकि जावास्क्रिप्ट में इन शाखाओं के लिंक को रखा जा सके (उदाहरण के लिए, ap..jery.com/detach का उपयोग करके), इस मामले में GC डिस्कनेक्ट की गई शाखाओं को साफ़ नहीं करेगा।

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

हमें अनुकूलन के ज्ञात स्थानों के बारे में नहीं भूलना चाहिए।

और फिर से डोम के बारे में - बड़ी सूची की समस्या

बड़ी सूचियों की समस्या पिछले अनुभाग में वर्णित समस्या का हिस्सा है।
आपके पास जितने अधिक सूची तत्व होंगे, पृष्ठ में उतने अधिक HTML तत्व होंगे, और सूची के अद्यतन और प्रतिपादन के लिए धीमी गति होगी।

मूल घटकों में, यह कैश के माध्यम से लागू किया जाता है ( एंड्रॉइड पर मूल घटक के कार्यान्वयन का एक उदाहरण )।



समस्या को पहले से ही छिपे हुए तत्व में डेटा की जगह और उसकी स्थिति को फिर से व्यवस्थित करके या छिपे हुए सूची तत्व को हटाकर और एक नया निर्माण करके हल किया जा सकता है। यही है, स्क्रीन पर, वास्तव में, 1000 तत्वों की सूची नहीं है, लेकिन स्क्रीन पर दिखाई देने वाले 10 तत्वों की एक सूची है, और संभवतः कई छिपे हुए तत्व हैं जो वर्तमान में काम कर रहे हैं।

वेब अनुप्रयोगों में, सूचियों का ऐसा क्रियान्वयन देखना लगभग असंभव है; एक नियम के रूप में, सब कुछ यथासंभव सरल किया जाता है: 1000 तत्वों की एक सूची। और अगर डेस्कटॉप पर यह इतना महत्वपूर्ण नहीं है, तो मोबाइल प्लेटफार्मों पर, बड़ी सूचियां एक विकास मंच के रूप में फोनगैप को छोड़ने में एक निर्णायक भूमिका निभा सकती हैं।

इस समस्या के समाधान के रूप में, आप "पेजिंग" की सिफारिश कर सकते हैं, अर्थात, भागों में सूची प्रदर्शित करना। यह वास्तु समाधान कई जेएस पुस्तकालयों द्वारा कार्यान्वित किया जाता है; आप उसे बहुत खूबसूरती से हरा सकते हैं - उदाहरण के लिए, एक स्वाइप के साथ।



या आप एक जावास्क्रिप्ट पुस्तकालय लिख सकते हैं या पा सकते हैं जो देशी घटकों के समान कार्यक्षमता को लागू करता है; उदाहरण के लिए, जैसा कि InfiniteWall में या यहाँ किया गया है ।

अंत में, मैं कुछ उपयोगी सुझाव देना चाहूंगा, जो हमें आशा है, समय और तंत्रिकाओं को बचाने में आपकी मदद करेंगे:

1. आपके द्वारा उपयोग किए जाने वाले कम तृतीय-पक्ष लाइब्रेरी बेहतर हैं, यह मोबाइल डिवाइस के सीमित संसाधनों के कारण है। तुलना के लिए, मैं "स्टारशिप" के एक स्क्वाड्रन का हवाला दे सकता हूं - तीसरे पक्ष के पुस्तकालय। आप चाहते हैं कि यह स्क्वाड्रन आपके आवेदन के व्यावसायिक मामले को पूरा करने के लिए एक "लोड" ले जाए। लेकिन ईंधन का सेवन पूरे स्क्वाड्रन द्वारा किया जाएगा। इसलिए, संसाधनों (अपने "ईंधन") को बचाएं, पुस्तकालयों को सबसे बेहतर तरीके से चुनें और उनकी क्षमताओं का पूरा उपयोग करने का प्रयास करें। उदाहरण के लिए, संस्करण 2 से शुरू होने वाला jQuery, प्रदर्शन में जिप्टो से बहुत अधिक हीन नहीं है, लेकिन बहुत अधिक कार्यक्षमता है।
2. आपके एप्लिकेशन को सभी प्लेटफार्मों और OS संस्करणों पर समान नहीं दिखना है। यह कार्यक्रम की गति और कार्यक्षमता को बनाए रखने के लिए शैलियों और डिजाइन में कुछ रियायतें देने के लायक हो सकता है। आईई के साथ स्थिति को याद रखें;
3. सूचियों में, img टैग के लिए "src" विशेषता का उपयोग न करें, छवि को प्रदर्शित करने के लिए CSS पृष्ठभूमि का उपयोग करें; इस स्थिति में, छवि केवल तभी लोड की जाएगी जब सूची आइटम स्क्रीन पर दिखाई दे;
4. ऑप्टिमाइज़ेशन के तरीके जो क्लाइंट-सर्वर आर्किटेक्चर के साथ वेब पेजों के मामले में काम करते हैं, वे हमेशा फोनगैप पर एप्लिकेशन के लिए महत्वपूर्ण और इष्टतम नहीं होते हैं। उदाहरण के लिए, लोड की गई जावास्क्रिप्ट फ़ाइल के आकार पर ध्यान देना या छवि में अदृश्य पिक्सल को कम करने का कोई मतलब नहीं है, क्योंकि हमारे मामले में इन फ़ाइलों को डाउनलोड करने के लिए कोई लंबा नेटवर्क अनुरोध नहीं है। दुर्भाग्य से, किसी ने भी प्रत्येक फ़ाइल को डाउनलोड करने से पहले 250 मिली सेकेंड की देरी को रद्द नहीं किया, और आप तय करते हैं कि इससे कैसे निपटना है। हमने अपने लिए आलसी प्रीलोड और टाइलें चुनीं;
5. स्क्रीन के शीर्ष पर इनपुट फ़ील्ड रखें - यह मोबाइल उपकरणों पर कीबोर्ड प्रदर्शित करते समय पृष्ठ के विभिन्न लेआउट व्यवहार से बचना होगा;
6. बड़ी सूचियों से बचें - यह एक मुश्किल काम है; इसे तब पकड़ें जब आपके पास इसे हल करने के लिए कम से कम एक खाका हो;
7. अधिकतम करने के लिए छाया, ग्रेडिएंट और पारभासी से छुटकारा पाएं। इस सभी सौंदर्य को मोबाइल डिवाइस से अतिरिक्त शक्ति की आवश्यकता होती है, इसलिए इसका उपयोग केवल उसी स्थान पर करें जहां इसकी वास्तव में आवश्यकता है;
8. सीपीएस के माध्यम से GPU शक्ति का उपयोग करें, जैसे:
   transform: translate3d(0,0,0);
-webkit-transform: translate3d(0,0,0);

   विशेष रूप से, आप एक विशिष्ट कार्यान्वयन के बारे में पढ़ सकते हैं।
   या परीक्षणों के साथ अधिक विस्तार से ।
   

और सुझावों के साथ लेख के कुछ और लिंक: यहां , यहां या यहां ।

लेकिन सबसे महत्वपूर्ण बात, जो हम कहना चाहते हैं: आप फोनगैप पर लिख सकते हैं।

हालांकि यह विकास के लिए रामबाण नहीं है। प्रत्येक उपकरण को अपने स्वयं के कार्यों के लिए डिज़ाइन किया गया है । PhoneGap का उपयोग करके, आप एक उत्तरदायी एप्लिकेशन और / या एक गैर-मानक डिजाइन के साथ एक आवेदन लिख सकते हैं (और यह देशी कोड के साथ करना भी आसान है)। लेकिन अगर आपको बड़ी मात्रा में डेटा संसाधित करने की आवश्यकता है, तो सबसे अधिक संभावना है कि फोनगैप आपको सूट नहीं करेगा, हालांकि कभी-कभी आप इससे निपट सकते हैं।

हमें उम्मीद है कि हमारे सुझाव काम आएंगे।

पुनश्च 11 घंटे यूआई अनुकूलन के बाद, कीड़े एक ही बटन के आकार के साथ बने रहे, लेकिन आवेदन वास्तव में "बेहतर हो गया"।