🙍🏾 📖 🥀 Android एप्लिकेशन बनाते समय बेंचमार्किंग ORM का उपयोग किया जाता है 🖌️ 🙇🏼 👨🏾‍⚕️

नमस्कार, हेब्र! मेरा नाम एर्टोम डोब्रोविंस्की है और मैं फिनिच में एक एंड्रॉइड डेवलपर हूं।

एक बार, सुबह के सिगार के धुएं में खुद को लपेटते हुए, मैंने एंड्रॉइड के लिए एक ओआरएम के स्रोत कोड का अध्ययन किया। वहां देखते हुए benchmarks नामक एक पैकेज तुरंत वहां देखा, और आश्चर्यचकित था कि सभी मूल्यांकन Log.d(System.nanoTime()) का उपयोग करके किए गए थे। यह पहली बार नहीं है जब मैंने यह देखा है। ईमानदार होने के लिए, मैंने System.currentTimeMillis() का उपयोग करते हुए बेंचमार्क भी देखा। ढह गई जागरूकता कि कुछ बदलने की जरूरत है, मुझे एक व्हिस्की का गिलास अलग करने और कीबोर्ड पर बैठने के लिए मजबूर होना पड़ा।

यह लेख क्यों लिखा गया है

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

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

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

यदि आपको प्रदर्शन को मापने के लिए तीसरे पक्ष के ढांचे का उपयोग करने के बारे में तर्क की आवश्यकता है, तो आप हमेशा अलेक्सई शिपिलेव को पढ़ सकते हैं और समस्या की गहराई पर चमत्कार कर सकते हैं। सब कुछ संदर्भ द्वारा लेख में है: बेंचमार्किंग से पहले वार्मअप की आवश्यकता क्यों होती है, क्यों System.currentTimeMillis() पर भरोसा नहीं किया जा सकता है, जब बीते हुए समय की गिनती की जाती है, और 300 के लिए चुटकुले। उत्कृष्ट पढ़ने।

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

तथ्य यह है कि मैं एक व्यापक रूप से विकसित डेवलपर हूं: मैं न केवल एंड्रॉइड एसडीके का मालिक हूं, जैसे कि यह मेरा पालतू-प्रोजेक्ट था, लेकिन एक और महीने के लिए मैंने बैकएंड के लिए कोड लिखा।

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

चलो चलते हैं।

हम क्या माप रहे हैं

एंड्रॉइड के लिए बेंचमार्किंग डेटाबेस के मामले के हिस्से के रूप में, मैंने प्रारंभिक गति को मापने और पेपर, हॉक, रियलम और रूम जैसे ओआरएम के लिए लिखने / पढ़ने की गति को मापने का निर्णय लिया।
हां, मैं एक परीक्षण NoSQL और एक रिलेशनल डेटाबेस में मापता हूं - अगला सवाल क्या है?

हम मापते हैं

ऐसा लगता है कि अगर हम JVM के बारे में बात कर रहे हैं, तो चुनाव स्पष्ट है - JMH का महिमामंडन , पूर्णता और दोषपूर्ण दस्तावेज है । लेकिन नहीं, यह एंड्रॉइड के लिए इंस्ट्रूमेंटेशन टेस्ट शुरू नहीं करता है।

Google कैलीफ़र उनका अनुसरण करता है - उसी परिणाम के साथ।

स्पैनर नामक कैलीफ़र का एक कांटा है - जो कई वर्षों से ज़ेपरकेय है और एंड्रॉइड बेंचमार्क के उपयोग को प्रोत्साहित करता है।

आइए हम उत्तरार्द्ध पर ध्यान केंद्रित करें। यदि केवल इसलिए कि हमारे पास कोई विकल्प नहीं था।

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

परिणामों की हास्यास्पदता को कम करने के लिए, मैं 10 बार सभी परीक्षण चलाऊंगा और औसत की गणना करूंगा।

परीक्षण उपकरण - Xiaomi A1। बाजार में सबसे कमजोर नहीं, "स्वच्छ" एंड्रॉइड।

किसी प्रोजेक्ट के लिए लाइब्रेरी कनेक्ट करना

Andoridx बेंचमार्क को एक परियोजना से जोड़ने के लिए उत्कृष्ट निर्देश हैं। मैं दृढ़ता से आपको सलाह देता हूं कि आप आलसी न हों और माप बनाने के लिए एक अलग मॉड्यूल कनेक्ट करें।

प्रयोग की प्रगति

हमारे सभी बेंचमार्क निम्नलिखित क्रम में निष्पादित किए जाएंगे:

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

यहां कोड पाया जा सकता है । यदि आप चलने के लिए आलसी हैं, तो पेपरडब के लिए पैमाइश समारोह इस तरह दिखता है:

 @Test fun paperdbInsertReadTest() = benchmarkRule.measureRepeated { //   (     ) benchmarkRule.scope.runWithTimingDisabled { Paper.book().destroy() if (Paper.book().allKeys.isNotEmpty()) throw RuntimeException() } //    repository.store(persons, { list -> Paper.book().write(KEY_CONTACTS, list) }) val persons = repository.read { Paper.book().read<List<Person>>(KEY_CONTACTS, emptyList()) } }

ओआरएम के बाकी हिस्सों के लिए बेंचमार्क समान दिखते हैं।

परिणाम

प्रारंभ

परीक्षण का नाम	मतलब	1	2	3	4	5	6	7	8	9	10
HawkInitTest	49_512	49_282	50_021	49_119	50_145	49_970	50_047	46_649	50_230	49_863	49_794
PaperdbInitTest	224	223	223	223	233	223	223	223	223	223	223
RealmInitTest	218	217	217	217	217	217	217	217	227	217	217
RoomInitTest	61_695.5	63_450	59_714	58_527	59_175	63_544	62_980	63_252	59_670	63_868	62_775

विजेता रियलम है, दूसरे स्थान पर पेपर है। कमरा क्या कर रहा है, आप अभी भी कल्पना कर सकते हैं कि हॉक लगभग समान समय करता है - यह पूरी तरह से समझ से बाहर है।

लिखना और पढ़ना

परीक्षण का नाम	मतलब	1	2	3	4	5	6	7	8	9	10
HawkInsertReadTest	278_736_469.2	278_098_654	283_956_846	276_748_308	282_447_384	272_609_500	284_699_653	271_869_770	278_719_693	278_836_115	279_378_769
PaperdbInsertReadTest	173_519_957.3	172_953_347	174_702_000	169_740_846	174_401_192	173_930_037	174_179_616	173_937_460	173_739_115	176_215_038	171_400_922
RealmInsertReadTest	111_644_042.3	108_501_578	110_616_078	102_056_461	112_946_577	111_701_231	114_922_962	106_198_000	118_742_498	120_888_230	109_866_808
RoomInsertReadTest	1_863_499_483.3	187_250_3614	1_837_078_614	1_872_482_538	1_827_338_460	1_869_147_999	1_857_126_229	1_842_427_537	1_870_630_652	1_878_862_538	1_907_396_652

यहाँ फिर से दायरे के विजेता, लेकिन इन परिणामों में विफलता के स्मैक।

दो "सबसे धीमे" डेटाबेस और सोलह बार "सबसे तेज़" और "सबसे धीमी" के बीच चार बार अंतर बहुत संदिग्ध है। यहां तक कि इस तथ्य को ध्यान में रखते हुए कि अंतर स्थिर है।

निष्कर्ष

अपने कोड के प्रदर्शन को मापना कम से कम जिज्ञासा से बाहर है। यहां तक कि अगर हम सबसे अधिक उद्योग-लॉन्च किए गए मामलों (जैसे कि एंड्रॉइड के लिए इंस्ट्रूमेंटल परीक्षणों का मूल्यांकन) के बारे में बात कर रहे हैं।

इस व्यवसाय के लिए थर्ड-पार्टी फ्रेमवर्क का उपयोग करने का हर कारण है (समय और चीयरलीडर्स के साथ खुद लिखने के बजाय)।

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

हैप्पी कोडिंग!

पुनश्च: यदि एक चौकस पाठक को एंड्रॉइड के लिए इंस्ट्रूमेंटल टेस्ट के बेंचमार्क आयोजित करने की रूपरेखा के बारे में पता है, तो लेख में सूचीबद्ध नहीं - कृपया टिप्पणियों में साझा करें।

PPS: टेस्ट रिपॉजिटरी पुल अनुरोधों के लिए खुला है।

Android एप्लिकेशन बनाते समय बेंचमार्किंग ORM का उपयोग किया जाता है