नया Yandex.Metro इंटरफ़ेस और तकनीक जिसके साथ यह काम करता है

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



इस पोस्ट में हम आपको यह बताना चाहेंगे कि हमने यह कैसे किया, हमने क्या निर्णय लिए और क्यों चुने।

Yandex.Metro सेवा को 2007 में वापस लॉन्च किया गया था। तब से, वेब इंटरफ़ेस व्यावहारिक रूप से विकसित नहीं हुआ है, डिजाइन स्पष्ट रूप से पुराना लग रहा था। सेवा की आदरणीय आयु ने तकनीकी पक्ष को प्रभावित किया। सभी योजनाएं जीआईएफ प्रारूप में छवियों के सेट थीं, जिन पर ऑब्जेक्ट्स को निर्देशांक का उपयोग करके रखा गया था। इस वजह से, ग्राफ़ को अपडेट करने में कठिनाइयाँ उत्पन्न हुईं; अपने दम पर इस योजना में बदलाव करना असंभव था (आपको आउटसोर्सर्स को आकर्षित करना था, उनसे चित्र मंगवाना)। चूंकि स्टेशन के नाम चित्रों में भी अंतर्निहित थे, इसलिए सर्किट के स्थानीयकरण के लिए जीआईएफ चित्रों के पूर्ण सेट की पीढ़ी की आवश्यकता होगी।

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

यह कहना नहीं है कि Yandex.Metro को पूरी तरह से छोड़ दिया गया था, इसमें काफी व्यापक दर्शक हैं। रोजाना लगभग 220 हजार लोग वेब इंटरफेस पर जाते हैं, आईओएस के लिए एंड्रॉइड एप्लिकेशन को 3 मिलियन बार डाउनलोड किया गया है - 1 मिलियन डाउनलोड। यह ध्यान देने योग्य है कि मोबाइल एप्लिकेशन वेब संस्करण की तुलना में कुछ समय बाद विकसित किए गए थे, और इसकी अधिकांश कमियों से रहित हैं।

विकसित करते समय, मेट्रो के लॉन्च के बाद से कई महत्वपूर्ण बदलावों को ध्यान में रखना आवश्यक था:

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

नया संस्करण कैसे विकसित किया गया था?

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

विकास की शुरुआत में, इस योजना को बनाने के लिए कौन सी तकनीक का उपयोग करना है, इस बारे में सवाल उठता है: कैनवास, एसवीजी या सीएसएस 3। राफेलजेएस विज़ुअलाइज़ेशन लाइब्रेरी के माध्यम से एक प्रतिपादन पद्धति पर भी विचार किया गया। यह पुस्तकालय एसवीजी में आकर्षित करता है, लेकिन अगर यह IE8 का पता लगाता है, तो प्रतिपादन वीएमएल में होता है, जो अधिकतम क्रॉस-ब्राउज़र संगतता सुनिश्चित करता है।

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

प्रौद्योगिकी	time_to_download	time_to_draw	overall_time
कैनवास	34.58 मि	181.72 मि	216.30 मि
svg	28.02 मि	74.02 एमएस	102.07 मि
svg-Raphael	45.87 मि	1147.58 एमएस	1193.45 एमएस

प्रौद्योगिकी	time_to_download	time_to_draw	overall_time
कैनवास	55.26 मि	769.16 एमएस	824.42 मि
svg	102.60 मि	136.51 मि	239.11 एमएस
svg-Raphael	148.40 मि	2369.88 एमएस	२५१ 25.२ ms एमएस

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

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



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

एक ग्राफ़ पर पथ खोजें

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

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

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

फ़िल्टरिंग खोज परिणाम

प्रत्येक अनुरोध के लिए, राउटर लगभग 30 मार्ग देता है। उनमें से बहुत कम प्रासंगिक हैं - 10% से अधिक नहीं। लेकिन समस्या यह है कि कई उपयोगकर्ताओं को "इष्टतम मार्ग" के बारे में एक अलग समझ है। कुछ गति पसंद करते हैं और कुछ आराम पसंद करते हैं। ऊँची एड़ी के जूते में एक लड़की अतिरिक्त 10 मिनट बिताने के लिए तैयार हो जाएगी ताकि लंबे मार्ग के साथ न जाए, लेकिन एक व्यक्ति के लिए जो विमान के लिए देर हो रही है, यह अंतर महत्वपूर्ण होगा। इसलिए, विभिन्न मानदंडों के अनुसार मार्गों का मूल्यांकन किया जाना चाहिए।

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

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

ग्राहक अनुप्रयोग वास्तुकला

एमवीसी को विकसित करने में, हमने यैंडेक्स में मौजूदा प्रथाओं का लाभ उठाया: जेएस पुस्तकालयों ने द्वीप के डिजाइन, तर्क, डेटा भंडारण और उपयोगकर्ता कार्यों और राज्य परिवर्तनों के बारे में घटकों की अधिसूचना के लिए जिम्मेदार है।

योजनाओं

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