IOS / Android मोबाइल उपकरणों के लिए पोर्टिंग कोड

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

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

कार्य योजना

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

प्रोसेसर

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

बाद में चर्चा की जाने वाली सभी विधियां इन सभी प्रणालियों पर लागू होंगी। लेकिन सुविधा के लिए, हम उन्हें सबसे आम एआरएम प्रोसेसर के उदाहरण पर विचार करेंगे। हमें उनके बारे में क्या जानने की जरूरत है?

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

लाइसेंस

एआरएम स्वयं प्रोसेसर जारी नहीं करता है, यह एक रिलीज़ लाइसेंस बेचता है, और विभिन्न कंपनियां (सैमसंग, एलजी, ब्रॉडकॉम, ऐप्पल, क्वालकॉम, फ्राइसेल) लाइसेंस खरीदती हैं और प्रोसेसर के अपने संस्करणों को जारी करती हैं, सिंगल-कोर या मल्टी-कोर - जो भी उन्हें पसंद है।
क्या देता है लाइसेंस? आप सिर्फ कर्नेल नहीं लेते हैं, आप अपना प्रोसेसर बनाते हैं। आप इसे परिष्कृत कर सकते हैं: सुधार या, इसके विपरीत, सरल करें - यह आपका अधिकार है। कहानी का एक उदाहरण XScale प्रोसेसर के साथ प्रसिद्ध इंटेल है। उन्होंने v5TE के लिए एक लाइसेंस खरीदा और इसे गंभीरता से लिया। मेरी राय में, यह मौजूदा प्रसंस्करण में अब तक का सबसे सफल है। उन्होंने मेमोरी के साथ काम में सुधार किया, कैश में वृद्धि की, और, अगर हम इंटेल और सैमसंग कार्यान्वयन की तुलना v5TE के आधार पर करते हैं, तो इंटेल जीता, शायद दो बार। इस प्रोसेसर की मुख्य विशेषता यह थी कि पहली बार इसमें एक 40-बिट बैटरी वाला एक कोप्रोसेसर दिखाई दिया, जिसने 1 घड़ी में 4 संख्याओं को गुणा करना संभव बनाया, और पुराने लोगों के पास एक वायरलेस MMX कोप्रोसेसर था, जो SIMD निर्देशों का एक शक्तिशाली सेट प्रदान करता है।

चिप पर सिस्टम

एक इंजीनियर के दृष्टिकोण से, चिप पर एक प्रणाली क्या है? यह एक छोटा माइक्रोप्रोसेसर है जिस पर विभिन्न उपकरणों का एक गुच्छा स्थापित किया जाता है। आप एआरएम से एक लाइसेंस खरीदते हैं, वहां एक डालते हैं, दो - आपको कितनी गुठली चाहिए। अतिरिक्त सहसंसाधक (ग्राफिक्स, डीएसपी, आदि), मेमोरी (ROM, FLASH ...) इसके अलावा, I / O इंटरफेस आमतौर पर वहां डाला जाता है: यदि आवश्यक हो, तो ईथरनेट, USB, COM पोर्ट। यह सब सामान काम करने के लिए, दोलक और टाइमर एक ही क्रिस्टल में जोड़े जाते हैं ताकि बोर्ड पर अलग-अलग ब्लॉक के अतिरिक्त स्ट्रैपिंग न करें।

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

RISC वास्तुकला

डेवलपर्स के लिए महत्वपूर्ण हैं कि वास्तु सुविधाओं पर विचार करें।

• सबसे पहले, यह लोड / स्टोर वास्तुकला है । सभी ऑपरेशन रजिस्टरों के साथ किए जाते हैं: लोड किए गए - गिने - अपलोड किए गए, और कुछ नहीं। आप स्मृति में एक ऑपरेंड के साथ एक ऑपरेशन नहीं कर सकते।
• रजिस्टरों के साथ काम करना सुनिश्चित करने के लिए, कर्नेल के पास एक बड़ी रजिस्टर फ़ाइल है - प्रत्येक के 32 बिट्स के 16 रजिस्टर । वे सिद्धांत रूप में, समतुल्य हैं। कुछ, बेशक, विशेष नाम हैं जो उनके उद्देश्य पर संकेत देते हैं, लेकिन आप किसी भी रजिस्टर के संबंध में सभी कार्यों तक पहुंच सकते हैं।
• निश्चित कमांड की लंबाई । एआरएम मोड में, यह आमतौर पर 32 बिट्स होता है: 1 कमांड - 1 शब्द, एक के बाद एक। कन्वेयर निश्चित रूप से इस तथ्य से खुश है, क्योंकि कुछ भी नहीं बदलता है, सब कुछ अनुमानित है।
• एआरएम की विशेषताओं में से एक है, न केवल मेमोरी ऑफ़सेट तक पहुंच प्राप्त करने की क्षमता, बल्कि रजिस्टर में एक ऑफसेट के साथ या सीधे संख्यात्मक रूप में एक प्रीइंकेरमेंट, पोस्टिंक्रेमेंट के साथ मेमोरी से उन्हें पढ़ना और लोड करना है। शक्तिशाली संबोधित करने वाली टीमें - एआरएम की सबसे महत्वपूर्ण विशेषताओं में से एक
• सभी ऑपरेशन 1 बीट में पूरे किए जाते हैं । शायद कम या ज्यादा - ये अलग-अलग कोर के लिए बारीकियां हैं।
• एआरएम की एक और शांत विशेषता सशर्त निष्पादन है । जब आप एक निर्देश लिखते हैं (अंकगणित, या बस ध्वज की जांच करते हैं), तो आपके पास अभी भी झंडे हैं, और शर्त पूरी होने पर ही निम्न संचालन किया जाता है। तदनुसार, आपको बड़े बदलाव करने की आवश्यकता नहीं है। यह बहुत सुविधाजनक है: यह उत्पादकता को बढ़ाते हुए, कन्वेयर को रीसेट नहीं करता है।
• त्वरित पारी। एआरएम आपको एक पाली के साथ अंकगणितीय संचालन करने की अनुमति देता है: आप एक + = (जे << 2) लिख सकते हैं; एक कमांड में, जिसे एक चक्र में निष्पादित किया जाएगा।

एआरएम परिवार

एआरएम परिवार कैसे विकसित और प्रगति करता है:

• ARM9 को आधार माना जाएगा। यह अतीत है, हालांकि उपयोग किया जाता है, लेकिन आधुनिक फोन में नहीं।
• ARM9E अभी भी एंड्रॉइड में पाया जाता है, और इसे ध्यान में रखा जाना चाहिए। ARM9E ने DSP निर्देशों की शुरुआत की, जो आवाज प्रसंस्करण एल्गोरिदम को बहुत तेज करता है।
• ARM10 कोर लगभग किसी का ध्यान नहीं गया।
• ARM11 के आधार पर विभिन्न डिवाइस सामने आए, लेकिन पहला iPhone सबसे प्रतिष्ठित डिवाइस था। यहाँ एक नवाचार SIMD के निर्देशों का उद्भव था, जो XScale में Intel के वायरलेस MMX की तुलना में कमजोर था।
• कॉर्टेक्स आज तक का सबसे आम कोर है। यह मल्टी-कोर कोर्टेक्स ए 9 सिस्टम या सिंगल-कोर कोर्टेक्स ए 8 हो सकता है, लेकिन उनके पास एक ही वास्तुकला है - एआरएमवी 7। यहाँ ARM ने NEON नामक एक छोटी क्रांति की। यह एक अलग कोप्रोसेसर है, जो चिप पर नहीं हो सकता है, हालांकि यह ARMv7 आर्किटेक्चर में शामिल है। NEON की एक विशेषता 64-बिट और 128-बिट कमांड की उपस्थिति है जो समानांतर जोड़, घटाव, बदलाव और संतृप्ति प्रदान करती है। यह यहां है कि एआरएम के पास एक पूर्ण-SIMD है जो डिजिटल सिग्नल को संसाधित करते समय त्वरण प्रदान करता है।
• एआरएम ने "हमारे उज्ज्वल भविष्य" की घोषणा की है - ARMv8 वास्तुकला के साथ 64-बिट कॉर्टेक्स-ए 50 कोर। वे सब कुछ के साथ पूर्ण संगतता का वादा करते हैं जो एक अलग 32-बिट मोड में था।

अंगूठा

मैं पिछले पैराग्राफ से तालिका की अंतिम पंक्ति पर अलग से रहना चाहूंगा। अँगूठा क्या है? यह मूल रूप से पैक एआरएम निर्देशों का एक सेट था। यदि कोड की गति और कॉम्पैक्टनेस के बीच हम दूसरा चुनते हैं, तो सीमित कार्यक्षमता के साथ 16-बिट निर्देश एक उत्कृष्ट समाधान है।

Thumb2, Thumb का विकास है। इसमें ARM निर्देशों का हिस्सा शामिल है, और इसमें 16-बिट और 32-बिट निर्देशों का एक सेट शामिल है जो कि Thumb की तरह कोड घनत्व सुनिश्चित करने के लिए डिज़ाइन किया गया है और एक ही समय में एक पूर्ण ARM के प्रदर्शन को बनाए रखता है।

क्रॉस-प्लेटफॉर्म

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

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

1. सबसे पहले, एकसमान टाइपिंग - अपने एकल प्रकारों में कोड लिखना महत्वपूर्ण है, क्योंकि अंतर्निहित मूल प्रकार अलग-अलग प्लेटफार्मों पर भिन्न हो सकते हैं
2. एल्गोरिथम और गैर-एल्गोरिथम भाग में कोड को अलग करना। एल्गोरिदम को सिस्टम कॉल और बुनियादी संचालन मिलते हैं
3. हार्डवेयर-निर्भर भाग : हम प्रोग्राम को एल्गोरिथम भाग (गणित) में विभाजित करते हैं और सिस्टम पर निर्भर करता है

आइए हम प्रत्येक वस्तु पर अधिक विस्तार से ध्यान दें।

एकल टाइपिंग

#if defined(_MSC_VER) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed __int64 int64_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned __int64 uint64_t; #elif defined(LINUX_ARM) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed long long int64_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned long long uint64_t; #else #include <stdint.h> #endif 

किसी एकल टंकण से मेरा क्या अभिप्राय है? आप बस अपने प्रकारों को परिभाषित करें। उपरोक्त उदाहरण में stdint का वर्णन है। इसे Microsoft कंपाइलर और लिनक्स के लिए परिभाषित किया गया है। यदि आप अधिक नियंत्रण चाहते हैं, तो आप "my_love_int8", "my_love_int16" लिख सकते हैं और फिर अपने प्रोग्राम में इन प्रकारों का उपयोग कर सकते हैं। यह बहुत मदद करता है, उदाहरण के लिए, यदि आप एक नेटवर्क के साथ काम करते हैं: आप हमेशा सुनिश्चित करते हैं कि आपके पास जितने भी पैकेट int16 हैं, उनके बीच की दूरी 0 है, ऑफसेट कुछ और नहीं है। आखिरकार, यदि आप एक चर के माध्यम से सब कुछ परिभाषित करते हैं, जो अचानक डबल-बाइट हो जाता है, तो सब कुछ कहीं न कहीं गलत हो जाएगा।

 struct NetworkStatistics { uint16_t currentBufferSize; uint16_t preferredBufferSize; uint16_t currentPacketLossRate; uint16_t currentDiscardRate; uint16_t currentExpandRate; uint16_t currentPreemptiveRate; uint16_t currentAccelerateRate; }; 

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

 #if defined(__APPLE__) # ifdef TARGET_OS_IPHONE # define MAILRU_OS_IOS # elif defined(TARGET_IPHONE_SIMULATOR) # define MAILRU_OS_IOS # define MAILRU_OS_IOS_SIMULATOR # elif defined(TARGET_OS_MAC) || defined (__OSX__) # define MAILRU_OS_MACOSX # else # define MAILRU_OS_MACOSX # endif #elif defined(_WIN64) # define MAILRU_OS_WIN64 # define MAILRU_OS_WINDOWS #elif _WIN32 # define MAILRU_OS_WIN32 # define MAILRU_OS_WINDOWS #elif ANDROID # define MAILRU_OS_ANDROID #else # error Unsupported OS target! #endif #if defined(_M_X64) || defined(__x86_64__) # define MAILRU_ARCH_X86_FAMILY # define MAILRU_ARCH_64_BIT #elif defined(__ARMEL__) || defined(__arm) || defined(_M_ARM_FP) # define MAILRU_ARCH_ARM_FAMILY # define MAILRU_ARCH_32_BIT #elif defined(__ppc__) # define MAILRU_ARCH_PPC_FAMILY # define MAILRU_ARCH_32_BIT #else # error Please add support for your architecture in typedefs.h #endif 

एल्गोरिदम

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

सिस्टम कॉल

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

 // Interface int32 MyAlgorithm_GetMemSizeNeed() int32 MyAlgorithm_Init(void *memory) void *MyAlgorithm_Destroy() // Using { void *m = MyManager_GetMem(MyAlgorithm_GetMemSizeNeed()); MyAlgorithm_init(m); //... m = MyAlgorithm_Destroy(); MyManager_FreeMem(m); } 

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

मूल संचालन

बेसिक ऑपरेशंस का मतलब है कि गैर-विशिष्ट ऑपरेशनों का आवंटन जो C में नहीं हैं, लेकिन जो आप अक्सर उपयोग करते हैं।

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

आकस्मिक व्यय

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

उदाहरण: uint64 >> n

 uint64_t LogicalShiftRigth(uint64_t number, int shift) { return number >> shift; } uint64_t test = 0x1234567812345678; uint64_t res63 = LogicalShiftRigth(test, 63); uint64_t res64 = LogicalShiftRigth(test, 64); 

एक मूल ऑपरेशन पर विचार करें जिसे लॉजिकल शिफ्ट सही कहा जाता है। कुछ संख्या है जिन्हें 63 और 64 तक स्थानांतरित करना होगा। ये सीमा मूल्य हैं। जैसा कि आप जानते हैं, यह सीमा मूल्य हैं जो सबसे अधिक परेशानी लाते हैं। Res63 और res64 में क्या होगा? सिद्धांत रूप में, शून्य होना चाहिए। लेकिन वास्तव में, सब कुछ इतना सरल नहीं है।



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

हार्डवेयर डिपेंडेंट पार्ट्स

मोबाइल एप्लिकेशन के डिवाइस-निर्भर भागों में निम्नलिखित विशेषताएं हैं:

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

बेसिक रैपर्स

किसी तरह से कोड के डिवाइस-निर्भर भागों के साथ काम को एकीकृत करने के लिए, मूल रैपर के एक सेट को एकल करना अच्छा है। मैं रैपर की सूची के अपने संस्करण की पेशकश करूंगा।

• सिस्टम लॉग नियमित रूप से प्रिंटफ () विकास के साथ बहुत मदद करता है। प्रत्येक मंच की अपनी रूपरेखाएँ होती हैं; उदाहरण के लिए, iOS के लिए यह NSLog हो सकता है, Android के लिए यह Logcat हो सकता है।
• मेमोरी मैनेजर । जैसा कि हमने पहले ही पता लगा लिया है, अपने स्वयं के मेमोरी मैनेजर के लिए बेहतर है, जो मॉलोक / मुक्त करता है। इसके अलावा, आप उसे मेमोरी लीक देखने के लिए सिखा सकते हैं।
• म्यूटेक्स / परमाणु संचालन के विभिन्न प्रणालियों में अलग-अलग कार्यान्वयन भी हैं।
• थ्रेड मैनेजर - मल्टी-थ्रेडेड एप्लिकेशन बनाने के लिए म्यूटेक्स और मुख्य एपीआई के लिए ऐड-ऑन।
• यदि आप रनटाइम में कुछ बदलते हैं तो सिस्टम की जानकारी उपयोगी हो सकती है। यदि आपका कोड कई प्रोसेसरों के लिए ऑप्टिमाइज़ किया गया है, तो आप यह पता लगा सकते हैं कि रनटाइम में क्या सिस्टम है और आवश्यक भाग को कनेक्ट करें।
• ट्रेसिंग / लॉगिंग अब केवल सिस्टम लॉग नहीं है; यह डिबगिंग त्रुटियों है, और यह बहुत अच्छा है अगर यह सभी प्लेटफार्मों के लिए समान है।
• फ़ाइलों के साथ कार्य में फ़ाइलों का इनपुट / आउटपुट, .pm डंप वगैरह शामिल हैं। एकल इंटरफ़ेस के माध्यम से आउटपुट प्राप्त करना बहुत सुविधाजनक है।
• प्रोफाइलिंग उपकरण । यदि आपके पास भारी कोड है, तो मानक टूल का उपयोग करके यह पता लगाना हमेशा संभव नहीं है कि क्या और कहाँ खो गया है। आप निश्चित रूप से, प्रत्येक विशिष्ट प्लेटफ़ॉर्म के मूल टूल का उपयोग कर सकते हैं, या आप अपने क्रॉस-प्लेटफॉर्म घड़ी, लॉग, और इसी तरह लिख सकते हैं, और उन्हें कोड में कॉल कर सकते हैं।

अतिरिक्त आवरण

डिवाइस क्या कर रहा है इसके आधार पर, आपको अतिरिक्त रैपर की आवश्यकता हो सकती है। यहां हार्डवेयर भागों की एक छोटी सूची है जो आवरणों के उपयोग को अनिवार्य बनाते हैं (वे आसानी से जाने के लिए पोर्टिंग के लिए आवश्यक हैं)।

• सॉकेट्स / नेटवर्किंग
• ऑडियो डिवाइस
• वीडियो उपकरण
• इनपुट डिवाइस

उप-योग

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

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

सावधान!

अंत में, मैं कुछ सामान्य सिफारिशें देना चाहूंगा: पोर्टेबल कोड लिखते समय मुझे क्या देखना चाहिए।

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

एक छोटा सा सारांश

1. पहला: प्रोसेसर की समझ को पोर्ट करना गुणवत्ता को बेहतर बनाता है।
2. दूसरा: सफल पोर्टिंग की कुंजी एक अच्छा क्रॉस-प्लेटफॉर्म कोड है। यही है, कम समय जब आप मौजूदा कोड को पुनर्लेखन करते हैं, तो बेहतर, तेज और सस्ता। हर कोई खुश होगा, विशेष रूप से प्रबंधक।
3. और तीसरा: कोड पोर्टेबिलिटी की सादगी वास्तुकला की सुदृढ़ता से निर्धारित होती है। इसलिए यदि आप एक नया एप्लिकेशन लिख रहे हैं, तो शुरू में इसके बारे में सोचें। यहां तक ​​कि अगर आप इसे स्थानांतरित करने की योजना नहीं बनाते हैं, तो शायद किसी और को यह करना होगा।

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

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