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

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

सभी समस्याएं मुख्य बात से उपजी हैं: ओवरहेड केवल दो बार कोड लिखने से अधिक निकला ।

विभिन्न प्रकार के ओवरहेड का विश्लेषण करने से पहले, मैं स्पष्ट करना चाहूंगा कि हमें कभी भी उस बिंदु पर नहीं मिला जहां अधिकांश कोड आधार C ++ में था। लागतों ने वास्तव में हमें उस दिशा में जाने से रोका।

यह भी ध्यान देने योग्य है कि बहुत बड़ी कंपनियां जैसे कि Google और Facebook कई वर्षों से स्केलेबल कोड साझाकरण समाधान विकसित कर रहे हैं। इस तरह के समाधान बहुत आम नहीं हैं। हालांकि थर्ड-पार्टी सिस्टम जैसे रिएक्ट नेटिव या फ्लटर कुछ ओवरहेड से बचते हैं, कुछ लागत बनी रहती हैं (कम से कम जब तक इनमें से एक तकनीक लोकप्रिय और पर्याप्त परिपक्व नहीं हो जाती)। उदाहरण के लिए, Airbnb ने इस लेख में उल्लिखित कई समान कारणों के लिए रिएक्ट नेटिव का उपयोग करने से इनकार कर दिया ।

सभी लागतों को चार मुख्य श्रेणियों में बांटा जा सकता है।

कस्टम चौखटे और पुस्तकालयों का ओवरहेड

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

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

यदि आप मंच की मूल भाषाओं में बने रहते हैं, तो इनमें से कोई भी आवश्यक नहीं है। और देशी भाषाओं में ओपन सोर्स प्रोजेक्ट में हमारी भागीदारी शायद डेवलपर्स के लिए अधिक फायदेमंद होगी। C ++ समुदाय में, ओपन सोर्स कल्चर था (और क्या है?) मोबाइल डेवलपर समुदाय में उतना विकसित नहीं है, जितना कि C ++ मोबाइल समुदाय में व्यावहारिक रूप से मौजूद नहीं है।

कृपया ध्यान दें कि ये लागत विशेष रूप से C ++ (अन्य संभावित गैर-देशी भाषाओं जैसे पायथन या C # के विपरीत) के लिए उच्च हैं, क्योंकि पूरी तरह कार्यात्मक मानक पुस्तकालय कोई नहीं है। हालाँकि, केवल C / C ++ में Google और Apple दोनों द्वारा समर्थित एक कंपाइलर है, इसलिए किसी अन्य भाषा में स्विच करने से कई अन्य समस्याएं हो सकती हैं।

अनुकूलित कस्टम विकास वातावरण

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

मुझे विशेष रूप से एक त्रुटि याद है जो पृष्ठभूमि स्ट्रीमिंग संरचना को अवरुद्ध करने का कारण बनी, जिससे आकस्मिक अनुप्रयोग क्रैश हो गया। इस तरह की त्रुटियों को एक साधारण, मानक स्टैक के साथ भी ट्रैक करना मुश्किल है। चूंकि समस्या में C ++ और Java के बीच चल रहे मल्टी-थ्रेडेड कोड को डीबग करना शामिल था, इसलिए इसे ट्रैक करने में कई सप्ताह लग गए!

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

प्लेटफ़ॉर्म अंतर के लिए प्लेटफ़ॉर्म ओवरराइड

हालाँकि iOS और Android "मोबाइल एप्लिकेशन" हैं जो आमतौर पर समान सुविधाएँ प्रदान करते हैं, लेकिन स्वयं को प्रभावित करने वाले प्लेटफार्मों में कुछ अंतर हैं। उदाहरण के लिए, कोई एप्लिकेशन पृष्ठभूमि कार्यों को कैसे करता है। यहां तक ​​कि समान चीजें समय के साथ बहुत भिन्न हो सकती हैं (उदाहरण के लिए, कैमरे के साथ बातचीत)।

परिणामस्वरूप, आप केवल एक बार कोड नहीं लिख सकते हैं और इसे दूसरे प्लेटफ़ॉर्म पर चला सकते हैं। आपको एक विशिष्ट प्लेटफ़ॉर्म के लिए एकीकृत और कोडिंग में बहुत समय बिताने की आवश्यकता है, और कभी-कभी यह कोड C ++ स्तर पर ही समाप्त होता है!

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

डेवलपर्स को काम पर रखने, प्रशिक्षण देने और बनाए रखने के लिए ओवरहेड

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

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

परिणामस्वरूप, हमें C ++ कोड बेस बनाए रखने के लिए महत्वपूर्ण ज्ञान की वास्तविक कमी का सामना करना पड़ा। केवल दो विकल्प बने रहे, और प्रत्येक के लिए महत्वपूर्ण प्रयास थे:

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

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

एक मानक स्टैक के साथ एक परिपक्व उत्पाद को अद्यतित रखना आसान नहीं है। आप स्थिरता के लिए नवीनता का त्याग करते हैं। यह समस्या काफी बढ़ जाती है अगर आप अपने आप को व्यापक मोबाइल पारिस्थितिकी तंत्र के बाहर कस्टम स्टैक में बंद कर देते हैं।

निष्कर्ष

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

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