आईओएस प्लेटफॉर्म पर प्रोग्रामिंग (जिसे हाल ही में आईफोन ओएस कहा गया था) फलदायक काम से खुशी और ज्वार के खिलाफ तैरने की पीड़ा का एक अजीब संयोजन है। प्रत्येक डेवलपर की अपनी राय होती है कि इनमें से कौन सा घटक प्रबल है। व्यक्तिगत रूप से, मुझे यह सबक पसंद है, इसलिए मुझे अगली परियोजना पर काम करने की
प्रक्रिया के अपने छापों को साझा करना उचित लगा।
मार्च के अंत में, मुझे iPhone के लिए
बुकमेट का एक मोबाइल संस्करण लिखने के लिए कहा गया था। अधिकांश एप्लिकेशन का डिज़ाइन पहले से ही एक मोटी PSD के रूप में तैयार था, सर्वर की तरफ काम पूरे जोरों पर था, लेकिन मुझे कहना था, जैसा कि वे कहते हैं, "बस" उद्देश्य-सी में क्लाइंट भाग लिखते हैं।
इस लेख में, हम पहले कंटेनर के बारे में बात करेंगे जिसमें एक रेक था जिसने हम पर हमला किया। यदि आप Starcraft खेलते हैं, तो zerg के साथ सादृश्य, जो अचानक अविश्वसनीय रूप से अविश्वसनीय मात्रा में सभी दरारें पर चढ़ गया, और अधिक उपयुक्त होगा।
आर्किटेक्चर
संक्षेप में, बुकमेट एक सर्वर है जो HTML फ़ाइलों के एक सेट से पुस्तकों को संग्रहीत करता है। बुकमेट क्लाइंट का मुख्य कार्य (आम लोगों में, "पाठक") इस HTML को प्रदर्शित और संसाधित करना है। HTML क्यों? इसके विपरीत, उदाहरण के लिए, पीडीएफ, फ़ॉन्ट आकार बदलते समय इसे पुन: स्वरूपित करना काफी आसान है, जो कि छोटे स्क्रीन पर मोबाइल एप्लिकेशन में बिल्कुल आवश्यक है। दूसरी ओर, चूंकि HTML में पृष्ठ की सामान्य अवधारणा नहीं है, कड़ाई से बोलते हुए, यह पारंपरिक पृष्ठ-दर-पृष्ठ फ़ॉर्म में पुस्तकों को प्रदर्शित करने के लिए बहुत उपयुक्त नहीं है। अगले पृष्ठ पर स्क्रीन पर फिट नहीं होने वाली रेखा को सही ढंग से स्थानांतरित करने के लिए, आपको पृष्ठ पर इसके ऊर्ध्वाधर इंडेंटेशन को जानना होगा। ऐसा करने के लिए, HTML इंजन को पहले पूरे दस्तावेज़ को संसाधित करना होगा और स्टाइलशीट के अनुसार दस्तावेज़ में सभी ब्लॉकों के आकार और निर्देशांक की गणना करना होगा। उसके बाद, आप कर सकते हैं कि एडोब इनडिजाइन या क्वार्कएक्सप्रेस जैसे किसी भी टाइपिंग प्रोग्राम क्या करता है।
उस समय बुकमेट के सहकर्मियों ने पहले ही जावास्क्रिप्ट में एक पुस्तकालय लिखा था जो यह सब सुंदर और जल्दी से करता है।
हैलो iPhone
बेस टेस्ट प्लेटफॉर्म के रूप में, हमने iPhone 3 जी को चुना, क्योंकि यह रूस में बहुत लोकप्रिय है और मेरे द्वारा संरक्षित सबसे पुराना iPhone मॉडल है। परीक्षण पुस्तकों में से एक का प्रकाशन "मॉडल फॉर असेंबली" जूलियो कोर्टाज़ द्वारा 890 KB आकार की एक फ़ाइल में किया गया था।
पहला प्रोटोटाइप एक UIWebView, एक जावास्क्रिप्ट पुस्तकालय था, और उद्देश्य-सी में उनके बीच इंटरलेयर कोड की कुछ (यद्यपि महत्वपूर्ण) राशि थी।
iPhone 3G एक बहुत ही स्मार्ट फोन है।
स्थानों में । ईमानदारी से, मैंने शायद ही कभी मोबाइल सफारी में ऐसी भारी साइटों को खोलने की कोशिश की हो, और मुझे यकीन नहीं है कि वे प्रकृति में पाए जाते हैं। गरीब iPhone! उन 40 से अधिक सेकंड के लिए जो उसे "असेंबली के लिए मॉडल" खोलने के लिए ले गए थे, वह स्मृति की कमी के कारण अन्य सभी अनुप्रयोगों को बंद करने में कामयाब रहा और मुझे चिल्लाया कि अब स्मृति पूरी तरह से बाहर निकल जाएगी, और एक कठिन भाग्य के बारे में विलाप करेगी, और bask कुछ भी बदलने में सक्षम नहीं है।
लेकिन उस समय हमारे पास चुटकुलों के लिए समय नहीं था। अवांट-गार्डे से पहला ज़ग पैर में जकड़ गया, और पृथ्वी नीचे की ओर कांप गई, अभी भी अदृश्य है, लेकिन पहले से ही भयानक है।
अनुकूलन करने के लिए अनिवार्य रूप से कुछ भी नहीं था। इन 40 सेकंड के एक आधे हिस्से के लिए, WebKit पार्सिंग में लगा हुआ था, DOM का निर्माण कर रहा था, ज्यामिति की पुनर्गणना कर रहा था, और भक्षण (अन्य शब्दों की कमी के लिए) स्मृति। वर्चुअल मेमोरी के लिए डिस्क का उपयोग करने में असमर्थता के कारण आईओएस अपने आप में एक गंभीर समस्या है, और हमारे मामले में इसे पृष्ठभूमि कार्यक्रमों (जैसे मेल और फोन) के कारण मेमोरी को तत्काल मुक्त करने की आवश्यकता हुई, जिसमें समय भी लगता है। संपूर्ण DOM पर जावास्क्रिप्ट सक्रिय होने से WebKit समाप्त हो गया।
ऐसा प्रदर्शन, जाहिर है, किसी को भी पसंद नहीं आया। यह स्पष्ट था कि iPhone पर जावास्क्रिप्ट हमारे उद्देश्यों के लिए पर्याप्त तेज़ नहीं है, और यह कि हम 20 एमबी मेमोरी का खर्च नहीं उठा सकते।
और इसके बारे में क्या करना है?
आपदा के पैमाने को बेहतर ढंग से समझने के लिए, आपको उस संदर्भ का वर्णन करने के लिए थोड़ा तोड़ना होगा जिसमें यह होता है। WebKit
एक ओपन सोर्स लाइब्रेरी है । लेकिन iOS में, यह
निजी APIs को संदर्भित करता है, जिसका उपयोग Apple द्वारा निषिद्ध है। यहां तक कि अगर खुद को iOS के लिए WebKit का निर्माण करना संभव था और इसे एक स्थैतिक पुस्तकालय के रूप में कार्यक्रम में शामिल किया, UIKit पहले से ही WebKit से लिंक करता है, जो अनिवार्य रूप से वर्णों के टकराव की ओर जाता है; यहां तक कि अगर आप पूरे WebKit का नाम बदलते हैं और टकराव से बचते हैं, तो UIWebView वेबकिट घटकों पर कोई पहुंच प्रदान नहीं करता है, जिस पर यह बनाया गया है: निजी एपीआई का उपयोग करने पर ऊपर देखें। यह पता चला है कि हम जावास्क्रिप्ट के बिना, उद्देश्य-सी से सीधे डोम तक नहीं पहुंच सकते। और इसका मतलब है, जैसा कि हाल ही में एक-आँख वाले कछुए ने कहा था, "ठीक है, हर कोई रवाना हो गया है।"
वेबकेट के बारे में भूल जाने के लिए यह सब कुछ है: libxml का उपयोग करके HTML को पार्स करें और DOM को मैन्युअल रूप से ड्रा करें। यही है, आपको अपना HTML इंजन लिखने की आवश्यकता है। मैं केवल प्रयोग के लिए इस बात से सहमत हो सकता हूं, यह समझने के लिए कि क्या यह प्रदर्शन के संदर्भ में समझ में आता है। अंत में, मैंने WebKit के स्रोत कोड को देखा और इसे और अधिक तेज़ी से बनाते हुए इसे फिर से लिखने की कोशिश करने की निरर्थकता से अवगत हूं। दूसरी ओर, हम 10% से भी WebKit की क्षमताओं का उपयोग नहीं करते हैं। यदि आप अपना स्वयं का अत्यधिक विशिष्ट इंजन लिखते हैं, तो यह किसी भी आधुनिक ब्राउज़र की तुलना में दस गुना हल्का होगा। ओह, जहां हमारा गायब नहीं हुआ था!
libXML
सबसे खराब एपीआई के लिए प्रोग्रामर के लिए नरक में वार्षिक प्रतियोगिता में, libxml का फिर से एक शानदार पुरस्कार है। मुझे गलती मिल सकती है, लेकिन
दस्तावेज़ की तुलना में स्रोत कोड बहुत स्पष्ट है। एक विशिष्ट उदाहरण:
Function: htmlCtxtReset
void htmlCtxtReset(htmlParserCtxtPtr ctxt)
Reset a parser context
ctxt: an HTML parser contextसभी गंभीरता में, और यह सब !? यहां जो कुछ भी लिखा गया है वह फ़ंक्शन और तर्क के नामों से स्पष्ट है। वास्तव में यह कार्य क्या करता है? इसकी आवश्यकता क्यों है? इसका उपयोग कब करें? कौन सा, मुझे माफ करना,
dunce यह लिखा? बैठ जाओ, libxml, ड्यूस।
निष्पक्षता में, यह कहने योग्य है कि पुस्तकालय लगभग सभी द्वारा उपयोग किए जाने के लिए पर्याप्त रूप से काम करता है। और जीवन में यह बहुत सरल है। और हर iPhone पर है।
पहला परिणाम
डेड-एंड डेवलपमेंट पर जितना संभव हो उतना कम समय खोने के लिए, मैंने सबसे धीमी सेक्शन से शुरुआत की। यह पाठ के ब्लॉक के आकार की गणना है, जो
ग्लिफ़ के आकार को
समेटने के लिए उबलता है। प्रदर्शन माप के परिणाम आश्चर्य के बिना नहीं थे।
- UIWebView + जावास्क्रिप्ट - 38 सेकंड, 20 एमबी मेमोरी। सभी अनुकूलन के बाद यह हमारा पहला विकल्प है।
- NSString, -sizeWithFont: - 14 सेकंड, 8 एमबी मेमोरी। चूंकि यह एक ही फ़ॉन्ट में एक ही ग्लिफ़ के आकार की बार-बार गणना करने का कोई मतलब नहीं है, इसलिए परिणाम कैश हैं। 35% समय मेथड कॉल द्वारा लिया जाता है - [NSString sizeWithFont:]।
- IPhone OS 3.1.3 के लिए कोर पाठ - 70 सेकंड से अधिक। कोर पाठ 3.2 संस्करण से पहले iPhone OS में एक निजी एपीआई है, मैं सिर्फ इसकी गति की तुलना करना चाहता था, क्योंकि यह एक अफीम उपकरण पर उपयोग करने में बहुत आसान है और बहुत तेज़ है।
नंबरों के साथ, मैंने उन लोगों को एक पत्र लिखा। डेवलपर्स के लिए समर्थन (तथाकथित
डीटीएस , डेवलपर तकनीकी सहायता, जो आमतौर पर एक भुगतान सेवा है)। उसी समय, मैंने पूछा कि अंतर्निहित फ़ंक्शन CGFontGetGlyGlyphsForUnichars () - [NSString sizeWithFont:] निजी API को संदर्भित करता है।
इसलिए मैं Apple का सम्मान करता हूं, यह डेवलपर्स के प्रति दृष्टिकोण के लिए है, जब उत्तरार्द्ध पूरे इंटरनेट पर नहीं चलता है, लेकिन "स्थापित फॉर्म के अनुसार" प्रश्न पूछें। दो दिनों के बाद, मुझे अपने प्रश्नों का विस्तृत उत्तर मिला, जिसमें से यह निम्नलिखित है:
- पार्टी नीतियों के लिए WebKit तक पहुंच प्रदान नहीं की गई है;
- संस्करण 3.2 से पहले iPhone OS के तहत कोर पाठ बहुत धीमी गति से होने के कारण एक निजी एपीआई है; 3.2 संस्करण के साथ शुरू, यह UIWebView + जावास्क्रिप्ट की तुलना में काफी तेज होना चाहिए;
- CGFontGetGlyphsForUnichars () इसकी अपर्याप्त डिजाइन के कारण एक निजी एपीआई है; इंटरनेट पर आप इसके एनालॉग्स ढूंढ सकते हैं और सुनिश्चित कर सकते हैं कि ऐसा है;
- समग्र रूप से, मैं सही रास्ते पर हूं, क्योंकि वे खुद दूसरे को नहीं जानते हैं;
- आपको सुविधा के बीच चयन करना होगा - [NSString sizeWithFont:] और कोर ग्राफिक्स स्पीड।
कारण के लिए!
यदि आप विवरण में नहीं जाते हैं, तो पाठ को बिछाने के लिए एल्गोरिथ्म बहुत सरल लगता है। पहले आपको पाठ को उसी शैली के टुकड़ों में विभाजित करने की आवश्यकता है, उदाहरण के लिए, यदि पाठ के ब्लॉक के बीच में इटैलिक में एक वाक्यांश है, तो इस तरह के ब्लॉक को तीन शैली के टुकड़ों में विभाजित किया गया है। फिर आपको यह समझने की आवश्यकता है कि पाठ
को किन स्थानों पर एक नई पंक्ति में स्थानांतरित
किया जा सकता है - ये एक नियम के रूप में, शब्दों के बीच विराम चिह्न या शब्दों के भीतर हाइफ़नेशन हैं। हम उन्हें स्थानांतरण के लिए उम्मीदवार कहते हैं। फिर हम हाइफ़नेशन उम्मीदवारों के बीच एक-एक करके टेक्स्ट के टुकड़े लेते हैं, उनकी लंबाई पर विचार करते हैं, और उन्हें लाइन पर लगाते हैं जब तक कि उनकी कुल लंबाई लाइन की लंबाई से अधिक न हो जाए। इसी तरह पृष्ठों के साथ: हम तब तक लाइनें जोड़ते हैं जब तक कि अगली पंक्ति पृष्ठ की ऊँचाई से आगे नहीं निकल जाती।
वस्तुओं का एक प्रभावशाली सेट प्राप्त किया जाता है: पाठ के प्रत्येक ब्लॉक (उदाहरण के लिए, एक पैराग्राफ) में तथाकथित लाइनों वाली एक सरणी होती है।
ग्लिफ़ चलता है - एक ही शैली के पाठ के टुकड़े। ये एक ही ग्लिफ़ रन हम एक पूरे के रूप में आकर्षित करते हैं जैसे वे हैं।
इस बिंदु पर, अनुकूलन के लिए दिलचस्प अवसर दिखाई देते हैं, और कोड जल्दी से स्पेगेटी में बदल जाता है। जैसा कि हम सबसे निचले स्तर के एपीआई पर उतरते हैं, यह स्पष्ट हो जाता है कि पर्याप्त भाषाई शिक्षा नहीं है। नए लेखन सिस्टम क्षितिज पर उभर रहे हैं जिसके साथ यह कोड काम नहीं करता है। उदाहरण के लिए, अक्षर की दिशा के कारण, जैसा कि अरबी या हिब्रू में, या शब्दों के बीच रिक्त स्थान की अनुपस्थिति के कारण, जैसा कि थाई में है।
नतीजतन, यह महसूस करते हुए कि पहले प्रयास में विशालता को पकड़ना असंभव था, मुझे राइट से लेफ्ट और थाई जैसी भाषाओं की दिशा के साथ भाषाओं के समर्थन को स्थगित करना पड़ा, जिनमें से मैं बहुत कम जानता हूं। इसी कारण से, दोनों पक्षों पर पाठ संरेखित करने का कार्य स्थगित कर दिया गया है - इसके लिए एक प्रभावी हाइफ़नेशन प्रणाली की आवश्यकता है, जो बदले में, यह जानने की आवश्यकता है कि प्रत्येक शब्द किस भाषा में है।
हालांकि, प्रदर्शन के मामले में, हमने जहां शुरुआत की थी, उसकी तुलना में महत्वपूर्ण प्रगति हुई है। अब कोर्टेज की कृति 6 (!) सेकंड से भी कम समय में स्क्रीन पर दिखाई देती है। यह वास्तव में एक कठिन महीना था। मुझे अपने मस्तिष्क को अस्थायी रूप से वापस करना पड़ा, अन्यथा उसने HTML और CSS के साथ काम करने से इनकार कर दिया। इस समय मेरी पत्नी ने मेरे कोने से केवल चींटियों और माताओं की बातें सुनीं। यह ग्राहक के लिए भी मीठा नहीं था: सबसे पहले, कोई भी एक अतिरिक्त महीने पर भरोसा नहीं कर रहा था, और दूसरी बात, परियोजना पर काम की शुरुआत हतोत्साहित कर रही थी ("एक अच्छी शुरुआत, आगे क्या होगा?"), तीसरा, कोई गारंटी नहीं थी? कि प्लाईवुड का यह गुच्छा भी बंद हो सकता है। हालांकि, वह जो जोखिम नहीं लेता है वह पैदल चलता है। और हम आकाश में बहुत कुछ चाहते थे!
बुकमेट एप्लिकेशन पहले से ही
ऐप स्टोर में उपलब्ध है (लिंक iTunes में खुलता है; यदि किसी कारण से यह काम नहीं करता है, तो
एक विकल्प है जो ब्राउज़र में खुलता है)।
उपसंहार
स्टीव जॉब्स के बारे में ऐसी
कहानी बताते हैं। 1983 में, उन्होंने इंजीनियरों को इन शब्दों के साथ मैक के बूट समय का अनुकूलन करने के लिए आश्वस्त किया: "कितने लोग मैक का उपयोग करेंगे? एक लाख? अब और नहीं। मैं शर्त लगाता हूं कि कुछ वर्षों में पांच मिलियन लोग दिन में कम से कम एक बार अपने मैक को चालू करेंगे। मान लीजिए कि आप बूट समय को 10 सेकंड तक कम कर सकते हैं। इसे पांच मिलियन उपयोगकर्ताओं से गुणा करें, आपको हर दिन 50 मिलियन सेकंड मिलते हैं। एक वर्ष के लिए यह संभवतया दर्जनों जीवन है। यदि आप इसे 10 सेकंड तेज डाउनलोड करते हैं, तो आपने एक दर्जन लोगों की जान बचाई। अच्छा, क्या यह इसके लायक है? " मुझे ऐसा लगता है।