अनुप्रयोग [खोज] गति अनुकूलन

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


मैं आपका स्वागत करता हूं, हेबर के पाठकों,

मैं थोड़ी पृष्ठभूमि के साथ शुरू करूँगा - समस्या के विवरण के साथ, और फिर मैंने समस्या हल करने के तरीके के साथ जारी रखा।

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

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

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

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

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

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

खैर, चूंकि कुछ भी नहीं है, मैं क्या कर सकता हूं? मैं खुद आईडीई में चाबियों पर एक खाई खोद सकता हूं, मुझे लगता है कि यह एक दिन के लिए है, मैं खुद के लिए एक सुविधाजनक कार्यक्रम बनाऊंगा - जैसा कि वे कहते हैं: "एक दिन खोना और फिर एक घंटे में उड़ना बेहतर है" ।

मुख्य स्थिति: परिणाम ढूंढना जल्दी होना चाहिए।

मैं इस लेख में इसके बारे में बात करूँगा (ताकि ऊब न हो, पाठ समय-समय पर एक कोड के साथ होगा)
जो कुछ लिखा गया है वह नया नहीं है, बल्कि कार्यक्रमों के प्रदर्शन को बेहतर बनाने के लिए आपको ध्यान देने की आवश्यकता है।
एंड्रॉइड ओएस के लिए जावा में लिखा गया एक ठोस कार्यक्रम एक उदाहरण के रूप में दिया गया है, लेकिन उपरोक्त पहलू अन्य वातावरणों पर लागू होते हैं।



वांछित कार्यक्रम में मुख्य कार्रवाई दर्ज किए गए कीवर्ड द्वारा अन्य कार्यक्रमों की खोज करना है, अर्थात। अन्य एप्लिकेशन के मेटाडेटा को खोजें।
ओएस से इस डेटा का अनुरोध करना कोई बड़ी समस्या नहीं है:

Intent i=new Intent(Intent.ACTION_MAIN, null); i.addCategory(Intent.CATEGORY_LAUNCHER); final List<ResolveInfo> apps = context.getPackageManager().queryIntentActivities(i, 0); 

0. सबसे सरल समाधान रैखिक खोज है।

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

1. क्विक सॉल्यूशन - पेड़ों का उपयोग करके खोजें

a) अधिकांश पेड़ जटिलता ओ (लॉग (n)) के साथ जानकारी खोजते समय काम करते हैं, अर्थात औसतन 150 तत्वों को दो से अधिक संचालन की आवश्यकता होती है। ऐसा सुधार लगभग 50-70 बार मेरे अनुकूल था (और जब आप समझते हैं कि खोज कई क्षेत्रों में होती है, तो सुधार हजारों गुना है)।
निष्कर्ष: यदि आप असंरचित जानकारी में कुछ खोजना चाहते हैं, तो कुछ समय या संरचना की जानकारी लें।

ख) मुझे यह पेड़ कहां मिल सकता है? पहले आपको उपलब्ध जानकारी से एक पेड़ बनाने की आवश्यकता है - इस प्रक्रिया को अनुक्रमण कहा जाता है। यहाँ एक बड़ा BUT होता है: यह अनुक्रमण खुद O (n log (n)) से, ओह डियर, O (n (2)) तक ले जा सकता है।
निष्कर्ष: यह मत भूलो कि जब "एक दिन खोना और फिर एक घंटे में उड़ान भरना बेहतर होता है" तो आप अभी भी शुरुआत में ही दिन खो देते हैं, इसलिए केवल तब ही इंडेक्सिंग करें, जब बहुत अधिक डेटा हो, आप अक्सर खोज करने जा रहे हैं और डेटा शायद ही कभी बदलता है (यह डेटा पर भी लागू होता है) हैश तालिकाओं और क्रमबद्ध सूचियों में)।

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

2. डेटाबेस से डेटा आउटपुट

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

 SELECT * FROM data 

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

3. स्मृति या प्रदर्शन

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



अब, आइए देखें कि इस तरह के कैशिंग के मामले में वास्तव में प्रदर्शन को बेहतर बनाने में आपकी मदद करता है:

a) कोड के कुछ वर्गों (चक्रों, कार्यों) में प्राप्त डेटा के अपेक्षित पुन: आवेदन के साथ, परिणाम को बचाने के लिए यह अधिक लाभदायक है। उदाहरण के लिए:

 static int[] a=new int[1000]; for(int i=0;i<a.length;i++){ ... } // 1. for(int i=0,len=a.length;i<len;i++){ ... } // 2. for(int i:a){ ... } // 3. 

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

एंड्रॉइड के लिए प्रलेखन में, Google विकल्प 3 का उपयोग करने पर जोर देता है, जो मुझे लगता है कि int[] को एक सूची के रूप int[] लागू किया गया है, न कि एक ऐरे के रूप में, इसलिए इट्रेटर का उपयोग करने से गति लाभ मिलता है।
निष्कर्ष: प्रोग्रामिंग भाषा के आधार पर, आपको दस्तावेज़ में देखना चाहिए और पता लगाना चाहिए कि किस विधि की सिफारिश की गई है। सरणी के लिए, आमतौर पर विकल्प 2, सूची के लिए, आमतौर पर विकल्प 3।

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

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

4. ग्राफिक खोल

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

  क्लिक करें -> शेल बदलें -> एक लंबा ऑपरेशन शुरू करें -> परिणाम प्राप्त करें -> शेल बदलें 

के बजाय

  क्लिक करें -> एक लंबा ऑपरेशन शुरू करें -> परिणाम प्राप्त करें -> शेल बदलें 

एक लंबे ऑपरेशन की शुरुआत और परिणाम प्राप्त करने के दौरान, शेल को लटका नहीं होना चाहिए, लेकिन उपयोगकर्ता को कार्रवाई की प्रगति दिखाने के लिए एनिमेटेड रहना चाहिए, अन्यथा यह दिखाई दे सकता है कि कार्यक्रम जमी है।

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

एक AsyncTask एप्लिकेशन कुछ इस तरह दिखता है:

 public class Run extends AsyncTask<Context, Integer, Boolean> { @Override protected Boolean doInBackground(Context... arg0) { ... } @Override protected void onPostExecute(Boolean result) { super.onPostExecute(result); // do something or catch by listener } } Run r=new Run();r.execute(this); 

हैंडलर का उपयोग सरल है, लेकिन कम सुविधाओं के साथ:

 private final Handler hRefresh = new Handler(); private final Runnable runRefreshData = new Runnable() { @Override public void run() { ... } }; hRefresh.post(runRefreshData); // or hRefresh.postDelayed(runRefreshData,100); 

टाइमर और मानक जावा थ्रेड को यहां नहीं माना जाएगा।

ख) वैकल्पिक रूप से, ग्राफिकल शेल के एनीमेशन का उपयोग करके, आप पृष्ठभूमि प्रक्रिया में जानकारी के लिए खोज के कारण होने वाली देरी को छिपा सकते हैं (यदि ऐसी प्रक्रिया 1 सेकंड से अधिक नहीं रहती है)। उदाहरण के लिए, मेमोरी में ली गई तस्वीर को रिकॉर्ड करने की प्रक्रिया को छिपाने के लिए, स्क्रीन पर एक दूसरा एनीमेशन प्रदर्शित किया जाता है।

ग) लंबी प्रक्रियाओं के लिए अपेक्षा या प्रगति सूचक (उदाहरण के लिए अनुक्रमण के दौरान) के एनीमेशन की आवश्यकता होगी। इस मामले में सबसे महत्वपूर्ण बात फिर से है, ताकि ग्राफिकल शेल में कार्रवाई बंद न हो।

निष्कर्ष: ग्राफिकल शेल उपयोगकर्ता को यह एहसास दिलाता है कि सब कुछ जल्दी से काम करता है, भले ही प्रसंस्करण में एक निश्चित समय लगे

5. आवेदन तर्क

कार्यक्रम के तर्क को स्पष्ट रूप से समझना बहुत महत्वपूर्ण है - किस स्थान पर गति महत्वपूर्ण है:

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

a) डाउनलोड रणनीति
एप्लिकेशन के लॉन्च समय का अनुकूलन करने के लिए, आपको पहले यह पता लगाना होगा कि यह समय किस पर खर्च किया गया है।
विभिन्न एसडीके में तथाकथित समय के दृश्य परिणाम प्राप्त करने के लिए तथाकथित प्रोफाइलर हैं।




यानी हमारे मामले में, OnCreate और OnResume दोनों ही 80% से अधिक समय तक ग्राफिक तत्वों को लोड करने, गिनने और खींचने में व्यस्त हैं। जितना अधिक वे और उनकी संरचना और स्थान उतना ही जटिल है, स्क्रीन पर निर्देशांक के लिए अधिक रूपांतरण की आवश्यकता है। विशेष रूप से android:weight="" में निर्दिष्ट चौड़ाई / ऊंचाई के साथ उत्तरदायी डिजाइन का उपयोग android:weight="" ग्राफिक्स के निर्माण के दौरान बढ़ी हुई लागतों की आवश्यकता होती है। इस समस्या को अलग-अलग स्क्रीन आकारों के लिए अलग-अलग मार्कअप फ़ाइलों का उपयोग करके हल किया जा सकता है, बजाय इसके कि एडाप्ट करता है। यह निश्चित रूप से अंतिम .apk फ़ाइल का आकार बढ़ाएगा, लेकिन एक ही समय में एप्लिकेशन लॉन्च करने की गति बढ़ाएगा।
मैं स्वीकार करता हूं: यह क्षण अभी पूरी तरह से संतुष्ट नहीं है, लेकिन यह कार्य योजना में दृढ़ता से तय है

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

 <ViewStub android:id="@+id/stub_lv_sugg" android:inflatedId="@+id/lv_sugg" android:layout="@layout/a_main_lv_sugg" android:layout_width="wrap_content" android:layout_height="wrap_content"/> 

और प्रोग्राम कोड में हम lvSugg=(ListView)findViewById(R.id.lv_sugg); बजाय उपयोग करते हैं lvSugg=(ListView)findViewById(R.id.lv_sugg);

 if (lvSugg == null) { lvSugg = (ListView) ((ViewStub) findViewById(R.id.stub_lv_sugg)).inflate(); } 

निष्कर्ष: जटिल ग्राफिकल गोले के साथ, एंड्रॉइड एप्लिकेशन शुरू करने में बहुत समय ग्राफिक तत्वों को लोड करने पर खर्च किया जाता है, जो अनुकूलन के लायक है

बी) कार्यक्रम का उपयोग करने का तर्क
विभिन्न अनुप्रयोगों में, यह तर्क अलग है, लेकिन विशेष रूप से FAppSter के उदाहरण के साथ, मुख्य लक्ष्य वांछित कार्यक्रम खोजने में लगने वाले समय को कम करना है। निम्नलिखित निष्कर्षों के कारण समान मानक खोज लाइन की तुलना में इस समय में एक महत्वपूर्ण कमी आई:

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

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

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

निष्कर्ष

एप्लिकेशन प्रदर्शन कई कारकों पर निर्भर करता है, जो भाषा और प्रोग्रामिंग वातावरण पर निर्भर करता है। इस लेख में, मैंने समस्याओं को हल करने के लिए कुछ कारक और तरीके बताए, और एक उदाहरण पर भी दिखाया कि किस पर ध्यान दिया जाए।

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