एनालिटिक्स कैसे लागू करें और एप्लिकेशन को न तोड़ें?

नमस्ते! मेरा नाम सोसिन इलिया है। मैं लमोडा एंड्रॉयड डेवलपर में काम करता हूं। मैं बटन पेंट करता हूं, सूचियों को छोड़ता हूं और दुर्भाग्य से, मैं एनालिटिक्स लिखता हूं ...

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

Mitap Mosdroid # 18 आर्गन द्वारा मेरी रिपोर्ट को समझने में , मैं आपको बताता हूं कि हमारा एसडीके कैसे काम करता है और प्रतिबिंब हमेशा खराब क्यों नहीं होता है। और मैं इस विषय के मुख्य प्रश्न का उत्तर दूंगा: "एनालिटिक्स कैसे लागू करें और एप्लिकेशन को तोड़ें नहीं?"।

शुरू करने के लिए, मैं आपसे एक सरल सवाल पूछूंगा: "आप कैसे सोचते हैं, Google Play पर हमारे पास कितने इंस्टॉलेशन हैं?"

10 मिलियन इंस्टॉलेशन!

जुलाई 2019 की शुरुआत में संकेतक।

इस तथ्य के अलावा कि हम उपयोगकर्ताओं के आधार पर निष्कर्ष निकालते हैं, हमारे पास आंतरिक ग्राहक भी हैं जो विश्लेषिकी में रुचि रखते हैं।


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

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



आपको क्या लगता है कि उन विशेषताओं के साथ किया जाना चाहिए जिनकी लोगों को आवश्यकता नहीं है?

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

कठिनाई क्या है?

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

दूसरी चुनौती एनालिटिक्स इकट्ठा करना है। हमारे पास यह प्रक्रिया 7 प्रणालियों में की गई है।



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

LStat हमारे अपने SDK (लामोदा आँकड़े) हैं। यह एक विशाल प्रणाली है, जो विभिन्न घटनाओं का 60% से अधिक समय लेती है। वे घटनाएं जो Google पर आगे बढ़ती हैं, समायोजित होती हैं, उन्हें अक्सर केवल LStat में एकत्र किया जाता था।

एसडीके

हमारा एसडीके इस प्रकार है।


एक साफ LStat चिपक जाता है, जिसके अंदर दो भाग होते हैं: भंडारण और शिपिंग। जब हम कोई घटना एकत्र करते हैं, तो हम उसे तुरंत नहीं भेजते हैं। अन्यथा, बहुत सारी घटनाएं और अनुरोध होंगे, जो बहुत सुविधाजनक नहीं है। इसलिए, हम अपने छोटे SQLite डेटाबेस में सब कुछ डालते हैं, जहां हम सब कुछ स्टोर करते हैं। फिर, कुछ अंतराल पर, हमारी नेटवर्क परत डेटाबेस से डेटा खींचती है और भेजती है।

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

कलेक्टरों

जैसा कि मैंने पहले कहा, हमारे पास 7 कलेक्टर हैं। वे इस तरह के तरीकों से मिलकर बनते हैं: कस्टम एनोटेशन, इवेंटहैंडलर और एपस्टार्टईवेंट। आपको क्या लगता है कि यह ईवेंट ट्रैक कैसे करता है?


बेशक, यह आवेदन के लिए एक ठंडी शुरुआत है। और यहां मुख्य बात यह है कि हमारे पास एक AppStartEvent वर्ग है जो कुछ इवेंट इंटरफ़ेस से विरासत में मिला है। और हमें इसकी आवश्यकता क्यों है, मैं थोड़ी देर बाद बताऊंगा।

कैसा चल रहा है? यहीं से थ्रश, जलन और प्रतिबिंब शुरू होता है।


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

इसके अलावा, इस जावा क्लास से, हम अपने सभी तरीके निकालते हैं जो इस कोड में हैं। अब हमें यह जांचने और सुनिश्चित करने की आवश्यकता है कि हमारी पद्धति एक ट्रैक-ईवेंट विधि है जो भंडारण के लिए जिम्मेदार होगी। ऐसा करने के लिए, हमारे पास कई पैरामीटर हैं: पहला यह है कि हमारे पास @EventHandler एनोटेशन है, हमारे पास मापदंडों की एक खाली सूची नहीं है, और कुछ घटना इनपुट पर आती है।

सभी शर्तों को पूरा किया जाता है, इसलिए हम मान सकते हैं कि यह फ़ंक्शन हमारे साथ एक घटना होगी। मैं इसे केवल कुछ आवरण में लपेटता हूं और इसे हमारे संग्रह में भेजता हूं।

प्रतिबिंब हमेशा बुरा नहीं होता है

हां, आप में से कई लोग कहेंगे कि प्रतिबिंब बुरा, धीमा, भयानक है।

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

हम 7 वर्गों से 500 से अधिक तरीके खींच रहे हैं । और हम इसे प्रति सत्र केवल एक बार करते हैं। एक मार्ग को पूरा करने में लगने वाला समय 40 मिली सेकेंड है। यह 3 फ्रेम (स्प्लैश स्क्रीन स्टेज पर) से कम है। और यह एक टॉप-एंड डिवाइस से बहुत दूर था, लेकिन एंड्रॉइड 6 पर एक सरल एनटीसी, जो कई वर्षों से है।

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

और अब मुख्य प्रश्न: एनालिटिक्स को कैसे लागू किया जाए ताकि आर्किटेक्चर को तोड़ना न हो?

Arhitekturka

हमारे आवेदन एमवीपी का उपयोग करता है।


यह हमारी तरह का ईश्वर-सार है, जो ApplicationScope पर "रहता है" और ठीक उसी जगह पर इंजेक्ट किया जाता है, जहां हमें इसकी आवश्यकता होती है। उदाहरण के लिए, हमें onClick () जमा करना होगा। वास्तुकला को न तोड़ने के लिए, हम दृश्य परत से प्रस्तुतकर्ता तक की घटना को आगे नहीं बढ़ाएंगे, ताकि बाद में यह कहीं चला जाए। इसके बजाय, हम सीधे व्यू से सब कुछ करते हैं और AnalyticsManager को ट्रैक पास करते हैं।

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



यह विधि हमारी सभी समस्याओं को हल करने में सक्षम है।

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

दूसरे, यह एक बार की घटनाओं के साथ समस्या को हल करने में मदद करता है । ये ऐसी घटनाएं हैं, जिन्हें आवेदन के पूरे चक्र के लिए 1 बार सख्ती से गिरवी रखना चाहिए। मार्क e.once, सामान्य बूलियन चर। यदि हम कहते हैं कि यह एक बार की घटना है, तो हम इसे संग्रह से हटा देते हैं। अगर हम इसे फिर से मोहरा बनाने की कोशिश करते हैं तो आगे क्या होता है? जाहिर है, हम इसे इस संग्रह में नहीं पाएंगे। आप एनालिटिक्समैनेजर.ट्रैक (AppStartEvent ()) को लिखना जारी रखते हुए अपने आप को पैर में उतना ही शूट करने की कोशिश कर सकते हैं, यह अभी भी एक बार जाएगा और अधिक नहीं होगा।

लाभ क्या है?

1. हम अपने एप्लिकेशन की वास्तुकला को नहीं तोड़ते हैं , क्योंकि AnalyticsManager झूठ और वास्तुकला के बाहर काम करता है। यह हमें एप्लिकेशन के किसी भी भाग में एम्बेड करने की अनुमति देता है।

2. आपको किसी भी संख्या में एनालिटिक्स सिस्टम में एक पंक्ति में किसी भी घटना को इकट्ठा करने की अनुमति देता है । ऐसा करने के लिए, हम बस लिखते हैं: analyticsManager.track (इवेंट ())। क्योंकि तब वह स्वयं कहाँ, किस मात्रा में, किस मापदण्ड के साथ, कब और कहाँ आदि का समाधान करता है।

3. "एक बार की घटनाओं" की समस्या का समाधान करता है । अब हमें कई तरह के चेक करने की जरूरत नहीं है। एक बार भेजे जाने, हटाने, और हम उससे फिर नहीं मिलेंगे।

4. एक ही तत्व को विभिन्न प्रणालियों में एकत्रित करने की समस्या का समाधान करता है । इस तथ्य के कारण कि हमने अलग-अलग कलेक्टरों में सब कुछ लिखा, यह अलग-अलग कलेक्टरों के पास गया। इस प्रकार, आपको अनावश्यक इशारों का सहारा नहीं लेना है। मेरी राय में, यह अद्भुत है।

परीक्षण ...

हम मैन्युअल रूप से परीक्षण करते हैं। स्वचालित क्यों नहीं, आप पूछते हैं? और फिर एक दुखद बात सामने आती है।

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

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

निष्कर्ष

इस निर्णय के साथ आगे क्या किया जा सकता है?

1. एनालिटिक्स के लिए ऑटोटेस्ट लिखें । इसके लिए बहुत तैयारी के काम की आवश्यकता होगी। लेकिन यह नहीं कहा जा सकता है कि यह असंभव है।

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

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

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

तो इस सबके साथ मैं क्या कहना चाहता हूं?

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

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

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