MAPS.ME में Apple मेटल

सभी को नमस्कार!

दुनिया में ओपनजीएल पर बड़ी संख्या में एप्लिकेशन हैं, और ऐसा लगता है कि एप्पल इस बात से बिल्कुल सहमत नहीं है। IOS 12 और MacOS Mojave के साथ शुरू, OpenGL को हटा दिया गया है। हमने MAPS.ME में Apple मेटल को एकीकृत किया है और हमारे अनुभव और परिणाम साझा करने के लिए तैयार हैं। हम आपको बताएंगे कि हमारे ग्राफिक्स इंजन ने किस तरह का सुधार किया, हमें किन कठिनाइयों का सामना करना पड़ा और सबसे महत्वपूर्ण बात यह है कि अब हमारे पास कितने एफपीएस हैं।

हर कोई जो रुचि रखता है या ग्राफिक्स इंजन में Apple मेटल समर्थन को जोड़ने पर विचार कर रहा है, बिल्ली का स्वागत है।

समस्याओं

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

नई पीढ़ी के ग्राफिक्स एपीआई एप्पल मेटल और वल्कन के आगमन के साथ, हम, ज़ाहिर है, हमारे आवेदन में उनकी उपस्थिति की संभावना पर विचार करते हैं, हालांकि, हमें निम्नलिखित द्वारा रोका गया था:

1. Vulkan केवल एंड्रॉइड और लिनक्स पर काम कर सकता था, और Apple मेटल केवल iOS और MacOS पर काम कर सकता था। हम ग्राफिक एपीआई के स्तर पर क्रॉस-प्लेटफ़ॉर्मस को खोना नहीं चाहते थे, इससे विकास और डिबगिंग प्रक्रियाओं को जटिल किया जा सकता था, इससे काम की मात्रा बढ़ जाएगी।
2. Apple मेटल पर एक एप्लिकेशन iOS सिम्युलेटर पर (जैसे, अब तक) बनाया और चलाया नहीं जा सकता है, जो हमारे विकास को भी जटिल करेगा और हमें OpenGL से पूरी तरह से छुटकारा नहीं देगा।
3. Qt फ्रेमवर्क, जिसका उपयोग हम आंतरिक उपकरण बनाने के लिए करते हैं, केवल OpenGL ( Vulkan अब समर्थित है ) का समर्थन करता है ।
4. Apple मेटल में C ++ API नहीं था और यह न केवल हमें रनटाइम के लिए, बल्कि एप्लिकेशन के बिल्ड चरण के लिए भी एब्सट्रक्शन के साथ आने के लिए मजबूर करेगा, जब इंजन का हिस्सा Objective-C ++ में संकलित होता है, और दूसरा, C ++ में पर्याप्त रूप से बड़ा होता है।
5. हम विशेष रूप से iOS के लिए एक अलग इंजन या एक अलग कोड शाखा बनाने के लिए तैयार नहीं थे।
6. कार्यान्वयन एक ग्राफिक डेवलपर के काम में कम से कम छह महीने का मूल्यांकन किया गया था।

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

निर्णय लेना

लगभग तुरंत हमने मोल्टेनवीके को देखा। यह ढांचा Apple मेटल का उपयोग करके वल्कन एपीआई का अनुकरण करता है, और इसका स्रोत कोड हाल ही में खोला गया था। MoltenVK का उपयोग करते हुए, ऐसा प्रतीत होता है, ओपनक को वल्कन के साथ बदलने की अनुमति देगा, और एप्पल मेटल के अलग एकीकरण से बिल्कुल भी नहीं निपटना होगा। इसके अलावा, क्यूटी डेवलपर्स ने मोलेन्टवीके के पक्ष में एप्पल मेटल पर प्रतिपादन के लिए अलग समर्थन से इनकार कर दिया है । हालाँकि, हमें रोका गया:

• एंड्रॉइड डिवाइस का समर्थन करने की आवश्यकता है, जिस पर वल्कन उपलब्ध नहीं है;
• OpenGL पर कमबैक की उपस्थिति के बिना iOS सिम्युलेटर पर शुरू करने में असमर्थता;
• डिबगिंग, प्रोफाइलिंग और प्री-क्लिनिंग शेड्स के लिए Apple टूल्स का उपयोग करने में असमर्थता, क्योंकि MoltenVK SPIR-V या GLSL स्रोत कोड से Apple मेटल के लिए रियल-टाइम शेड्स उत्पन्न करता है;
• जब धातु के नए संस्करण जारी किए जाते हैं, तो मोल्टेनवीके के अपडेट और बग फिक्स की प्रतीक्षा करने की आवश्यकता होती है;
• मेटल के लिए सूक्ष्म अनुकूलन की असंभवता, लेकिन वल्कन के लिए विशिष्ट या गैर-मौजूद नहीं है।

यह पता चला कि हमें ओपनजीएल को बचाने की जरूरत है, जिसका मतलब है कि हम ग्राफिकल एपीआई से इंजन को अलग किए बिना नहीं कर सकते। Apple मेटल, OpenGL ES और भविष्य में Vulkan का उपयोग ग्राफिक्स इंजन के स्वतंत्र आंतरिक घटकों को बनाने के लिए किया जाएगा, जो पूरी तरह से विनिमेय हो सकता है। जब मेटल या वल्कन एक कारण या किसी अन्य के लिए अनुपलब्ध है, तो ओएनजीसी फॉलबैक विकल्प की भूमिका निभाएगा।

कार्यान्वयन योजना इस प्रकार थी:

1. ग्राफिक्स इंजन का इस्तेमाल ग्राफिक्स एपीआई को अमूर्त करने के लिए किया जा रहा है।
2. ऐप के iOS वर्जन के लिए Apple मेटल को रेंडर करें।
3. आधुनिक और निचले स्तर के ग्राफिक्स एपीआई उत्पाद को लाभ पहुंचा सकते हैं या नहीं यह देखने के लिए गति और बिजली की खपत के प्रतिपादन के लिए उचित मानदंड बनाएं।

OpenGL और धातु के बीच महत्वपूर्ण अंतर

यह समझने के लिए कि ग्राफिकल एपीआई को कैसे अमूर्त किया जाता है, आइए पहले यह निर्धारित करें कि ओपनजीएल और मेटल के बीच प्रमुख वैचारिक अंतर क्या हैं।

1. यह माना जाता है, और बिना कारण के नहीं, कि धातु एक निचले स्तर की एपीआई है। हालांकि, इसका मतलब यह नहीं है कि आपको कोडांतरक में लिखना होगा या अपने आप को रेखांकन लागू करना होगा। धातु को एक निम्न-स्तरीय एपीआई कहा जा सकता है इस अर्थ में कि यह बहुत कम संख्या में निहित कार्य करता है, अर्थात लगभग सभी कार्यों को प्रोग्रामर को स्वयं लिखा जाना चाहिए। ओपनजीएल बहुत सी चीजें करता है, एक ओपन संदर्भ के एक निहित संदर्भ का समर्थन करने और इस संदर्भ को उस धारा से जोड़ने से शुरू होता है जिसमें इसे बनाया गया था।
2. धातु में, "नहीं" टीमों का रीयलटाइम-सत्यापन। डिबग मोड में, सत्यापन, निश्चित रूप से मौजूद है और कई अन्य एपीआई की तुलना में बेहतर है, मोटे तौर पर एक्सकोड के साथ इसके तंग एकीकरण के कारण। लेकिन जब प्रोग्राम को उपयोगकर्ता को भेजा जाता है, तो अब कोई मान्यता नहीं है, प्रोग्राम केवल पहली त्रुटि पर क्रैश हो जाता है। कहने की जरूरत नहीं है, ओपनजीएल सबसे चरम मामलों में ही दुर्घटनाग्रस्त हो जाता है। सबसे आम अभ्यास: त्रुटि को अनदेखा करना और काम करना जारी रखना।
3. धातु shaders को precompile कर सकती है और उनसे पुस्तकालयों का निर्माण कर सकती है। OpenGL में, शेडर्स को प्रोग्राम की प्रक्रिया में स्रोत से संकलित किया जाता है, इसके लिए एक विशेष डिवाइस पर OpenGL के विशिष्ट निम्न-स्तरीय कार्यान्वयन के लिए जिम्मेदार है। शेडर कंपाइलर्स के कार्यान्वयन में अंतर और / या त्रुटियां कभी-कभी शानदार बग पैदा करती हैं, खासकर चीनी ब्रांडों के एंड्रॉइड डिवाइसों पर।
4. OpenGL सक्रिय रूप से राज्य मशीन का उपयोग करता है, जो लगभग हर फ़ंक्शन में साइड इफेक्ट जोड़ता है। इस प्रकार, OpenGL फ़ंक्शन शुद्ध कार्य नहीं हैं, और ऑर्डर और कॉल इतिहास अक्सर महत्वपूर्ण होते हैं। धातु अंतर्निहित रूप से राज्यों का उपयोग नहीं करता है और उन्हें प्रदान करने के लिए आवश्यक से अधिक लंबे समय तक संरक्षित नहीं करता है। राज्य पहले से निर्मित और असफल वस्तुओं के रूप में मौजूद हैं।

ग्राफिक इंजन रिफैक्टरिंग एंड एम्बेडिंग मेटल

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

• जैसा कि पहले ही उल्लेख किया गया है, ओपनजीएल एपीआई की एक निहित इकाई है जिसे एक संदर्भ कहा जाता है। संदर्भ एक विशिष्ट थ्रेड के साथ जुड़ा हुआ है, और उस थ्रेड में कहा गया OpenGL फ़ंक्शन स्वयं इस संदर्भ को ढूँढता है और उसका उपयोग करता है। धातु, वल्कन (हाँ, और अन्य एपीआई, उदाहरण के लिए, डायरेक्ट 3 डी) इस तरह से काम नहीं करते हैं, उनके पास समान स्पष्ट ऑब्जेक्ट हैं जिन्हें डिवाइस या उदाहरण कहा जाता है। उपयोगकर्ता स्वयं इन वस्तुओं को बनाता है और विभिन्न उप-प्रणालियों में उनके स्थानांतरण के लिए जिम्मेदार है। यह इन वस्तुओं के माध्यम से होता है, जो ग्राफिक कमांड के लिए सभी कॉल किए जाते हैं।
  
  हमने अपनी अमूर्त वस्तु को एक चित्रमय संदर्भ कहा है, और ओपनजीएल के मामले में यह केवल ओएनजीसीएल कमांड के कॉल को सजाता है, और धातु के मामले में इसमें रूट MTLDevice इंटरफ़ेस होता है जिसके माध्यम से मेटल कमांड को बुलाया जाता है।
  
  बेशक, मुझे इस वस्तु को वितरित करना था (और चूंकि हमारे पास बहु-थ्रेडेड रेंडरिंग है, फिर सभी उप-प्रणालियों में ऐसी कई वस्तुएं)।
  
  हमने ग्राफिक संदर्भ के अंदर आदेशों, एन्कोडर्स और उनके प्रबंधन की कतारों के निर्माण को छिपाया, ताकि उन संस्थाओं को न फैलाया जाए जो ओपेनग्ल में मौजूद नहीं हैं।
• उपयोगकर्ता उपकरणों पर ग्राफिक कमांड के सत्यापन के गायब होने की संभावना खुले तौर पर हमें पसंद नहीं थी। हमारे क्यूए विभाग द्वारा उपकरणों और ओएस संस्करणों की एक विस्तृत श्रृंखला को पूरी तरह से कवर नहीं किया जा सकता है। इसलिए, हमें विस्तृत लॉग जोड़ना होगा जहां हमें पहले से ग्राफिकल एपीआई से एक सार्थक त्रुटि मिली थी। बेशक, यह सत्यापन केवल ग्राफिक्स इंजन के संभावित खतरनाक और महत्वपूर्ण स्थानों में जोड़ा गया था, क्योंकि पूरे इंजन को एक नैदानिक ​​कोड के साथ कवर करना व्यावहारिक रूप से असंभव है और आमतौर पर प्रदर्शन के लिए हानिकारक है। नई वास्तविकता यह है कि लॉग के साथ उपयोगकर्ता परीक्षण और डिबगिंग अब अतीत में हैं, कम से कम प्रतिपादन के संदर्भ में।
• हमारा पिछला शेडर सिस्टम रीफैक्टरिंग के लिए अनुपयुक्त था, मुझे इसे पूरी तरह से फिर से लिखना पड़ा। यहां बात केवल विधानसभा के मंच पर shaders के precompilation और उनके सत्यापन की नहीं है। OpenGL मापदंडों को पास करने के लिए तथाकथित समान चर का उपयोग करता है। संरचित डेटा स्थानांतरण केवल OpenGL ES 3.0 के साथ उपलब्ध है, और चूंकि हम अभी भी OpenGL ES 2.0 का समर्थन करते हैं, इसलिए हमने बस इस पद्धति का उपयोग नहीं किया। धातु ने हमें मापदंडों को पारित करने के लिए डेटा संरचनाओं का उपयोग किया, और ओपनजीएल के लिए हमें संरचना क्षेत्रों को एक समान चर के साथ मैप करना पड़ा। इसके अलावा, मुझे प्रत्येक शेड को मेटल शेडिंग लैंग्वेज में फिर से लिखना पड़ा।
• राज्य वस्तुओं का उपयोग करते समय, हमें एक चाल के लिए जाना था। ओपनजीएल में, एक नियम के रूप में, सभी राज्यों को रेंडर करने से ठीक पहले सेट किया जाता है, और मेटल में यह पहले से बनाई गई और मान्य वस्तु होनी चाहिए। हमारा इंजन, जाहिर है, ओपनगेल दृष्टिकोण का उपयोग करता था, और राज्य वस्तुओं के प्रारंभिक निर्माण के साथ रीफैक्टरिंग इंजन के पूर्ण पुनर्लेखन के साथ तुलनीय था। इस नोड को काटने के लिए, हमने चित्रमय संदर्भ के अंदर एक राज्य कैश बनाया। पहली बार राज्य मापदंडों का एक अनूठा संयोजन उत्पन्न होता है, एक राज्य वस्तु धातु में बनाई जाती है और कैश में रखी जाती है। दूसरे और बाद के समय के लिए, वस्तु को केवल कैश से पुनर्प्राप्त किया जाता है। यह हमारे मानचित्रों में काम करता है, क्योंकि राज्य मापदंडों के विभिन्न संयोजनों की संख्या बहुत बड़ी नहीं है (लगभग 20-30)। एक जटिल गेम ग्राफिक्स इंजन के लिए, यह विधि शायद ही उपयुक्त है।

नतीजतन, लगभग 5 महीने के काम के बाद, हम पहली बार Apple मेटल पर पूर्ण रेंडरिंग के साथ MAPS.ME को लॉन्च करने में सक्षम थे। यह पता लगाने का समय था कि क्या हुआ।

रेंडरिंग स्पीड टेस्टिंग

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

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

सबसे पहले, स्क्रिप्ट OpenGL ES 3.0 पर रेंडरिंग के साथ चलाई गई, फिर उसी डिवाइस पर Apple मेटल पर रेंडरिंग के साथ। शुरुआत के बीच, एप्लिकेशन मेमोरी से पूरी तरह से अनलोड था।
निम्नलिखित संकेतक मापा गया:

• पूरे फ्रेम के लिए एफपीएस (प्रति सेकंड फ्रेम);
• फ्रेम के उस भाग के लिए एफपीएस जो केवल डेटा तैयारी और अन्य फ्रेम-बाय-फ्रेम संचालन को छोड़कर, प्रतिपादन में लगे हुए हैं;
• धीमे फ्रेम का प्रतिशत (~ 30 एमएस से अधिक), अर्थात्। उन है कि मानव आंख झटके के रूप में देख सकते हैं।

एफपीएस को मापते समय, डिवाइस की स्क्रीन पर सीधे ड्राइंग को बाहर रखा गया था, क्योंकि स्क्रीन की ताज़ा दर के साथ ऊर्ध्वाधर सिंक्रनाइज़ेशन विश्वसनीय परिणाम प्राप्त करने की अनुमति नहीं देता है। इसलिए, फ्रेम को स्मृति में बनावट में तैयार किया गया था। CPU और GPU को सिंक्रनाइज़ करने के लिए, OpenGL ने glFinish लिए एक अतिरिक्त कॉल का glFinish , जबकि Apple मेटल ने waitUntilCompleted लिए MTLFrameCommandBuffer उपयोग किया।

	iPhone 6s		iPhone 7+		iPhone 8
	ओपन	धातु	ओपन	धातु	ओपन	धातु
एफपीएस	106	160	159	221	196	298
एफपीएस (केवल प्रतिपादन)	157	596	247	597	271	833
धीमी फ़्रेमों का विखंडन (<30 एफपीएस)	4.13%	1.25%	5.45%	0.76%	1.5%	0.29%

	iPhone X		आईपैड प्रो 12.9 '
	ओपन	धातु	ओपन	धातु
एफपीएस	145	210	104	137
एफपीएस (केवल प्रतिपादन)	248	705	147	463
धीमी फ़्रेमों का विखंडन (<30 एफपीएस)	0.15%	0.15%	17.52%	4.46%

	iPhone 6s	iPhone 7+	iPhone 8	iPhone X	आईपैड प्रो 12.9 '
धातु पर फ्रेम का त्वरण (N समय)	1.5	1.39	1.52	1.45	1.32
धातु पर प्रतिपादन का त्वरण (N समय)	3.78	2.41	3.07	2.84	3.15
धीमे फ्रेम में सुधार (एन बार)	3.3	7.17	5.17	1	3.93

परिणाम विश्लेषण

औसतन, Apple मेटल का उपयोग करके फ़्रेम प्रदर्शन लाभ 43% था। आईपैड प्रो 12.9 'पर न्यूनतम मूल्य तय किया गया है - 32%, आईफोन 8 पर अधिकतम - 52%। एक निर्भरता है: स्क्रीन रिज़ॉल्यूशन जितना कम होगा, उतना ही अधिक एप्पल मेटल ओपनजीएल ईएस 3.0 से आगे निकल जाएगा।

यदि हम फ्रेम के उस हिस्से का मूल्यांकन करते हैं जो रेंडरिंग के लिए सीधे जिम्मेदार है, तो Apple मेटल पर रेंडरिंग की औसत गति 3 गुना बढ़ गई है। यह काफी बेहतर संगठन को इंगित करता है, और, परिणामस्वरूप, ओपन मेटल ईएस 3.0 की तुलना में ऐप्पल मेटल एपीआई की दक्षता।

Apple मेटल पर धीमे फ्रेम (~ 30 एमएस से अधिक) की संख्या लगभग 4 गुना कम हो गई थी। इसका मतलब है कि एनिमेशन और नक्शे के चारों ओर घूमने की धारणा चिकनी हो गई है। सबसे खराब परिणाम आईपैड प्रो 12.9 पर 2732 x 2048 पिक्सेल के रिज़ॉल्यूशन के साथ दर्ज किया गया था: ओपनजीएल ईएस 3.0 लगभग 17.5% धीमा फ्रेम देता है, जबकि एप्पल मेटल - केवल 4.5%।

शक्ति परीक्षण

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

IOS 12 पर iPhone 8 पर बिजली की खपत का परीक्षण किया गया था। उसी उपयोगकर्ता परिदृश्य को निष्पादित किया गया था - 1 घंटे के लिए मैप नेविगेशन (चलती और स्केलिंग)। प्रत्येक शुरुआत में आवेदन के भीतर प्रक्रियाओं की लगभग पूर्ण पहचान की गारंटी के लिए स्क्रिप्ट लिखी गई थी। लॉस एंजिल्स क्षेत्र को भी परीक्षण स्थान के रूप में चुना गया था।

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

स्क्रीन की चमक सभी मामलों में नहीं बदली। सिस्टम और MAPS.ME को छोड़कर कोई अन्य प्रक्रिया निष्पादित नहीं की गई थी। एयरप्लेन मोड को चालू किया गया, वाई-फाई और जीपीएस को बंद कर दिया गया। इसके अतिरिक्त, कई नियंत्रण माप किए गए थे।

परिणामस्वरूप, प्रत्येक संकेतक के लिए, OpenGL के साथ धातु की तुलना का गठन किया गया था, और फिर अनुपातों को एक एकत्रित अनुमान प्राप्त करने के लिए औसत किया गया था।

	ओपन	धातु	विकास
बैटरी ड्रेन	32%	28%	12,5%
Xcode में प्रोफाइलिंग बैटरी उपयोग	1.95%	1.83%	6.16%

परिणाम विश्लेषण

औसतन, Apple मेटल पर रेंडरिंग संस्करण की बिजली की खपत में थोड़ा सुधार हुआ है। हमारे GPU एप्लिकेशन की बिजली की खपत बहुत अधिक प्रभावित नहीं है, लगभग 2%, क्योंकि MAPS.ME को GPU का उपयोग करने के मामले में अत्यधिक लोड नहीं कहा जा सकता है। सीपीयू पर GPU के लिए निर्देश तैयार करते समय कम्प्यूटेशनल लागत को कम करके एक छोटा लाभ प्राप्त किया जाता है, जो कि दुर्भाग्य से, प्रोफाइलिंग टूल की मदद से अलग नहीं किया जा सकता है।

परिणाम

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

इस सवाल पर कि क्या हमारी परियोजना को वास्तव में Apple मेटल पर प्रतिपादन की आवश्यकता है, हम सकारात्मक जवाब देने के लिए तैयार हैं। यह इतना नहीं है कि हम नवाचार से प्यार करते हैं, या यह कि Apple अंततः OpenGL को छोड़ सकता है। यह सिर्फ 2018 है, और ओपनजीएल 1997 में दिखाई दिया, अगला कदम उठाने के लिए उच्च समय है।

PS जब तक हमने सभी iOS उपकरणों पर फीचर लॉन्च नहीं किया। इसे मैन्युअल रूप से सक्षम करने के लिए, सर्च बार में ?metal टाइप करें और एप्लिकेशन को पुनरारंभ करें। OpenGL को रेंडरिंग वापस करने के लिए; ?gl कमांड दर्ज करें और एप्लिकेशन को पुनरारंभ करें।

PPS MAPS.ME एक ओपन-सोर्स प्रोजेक्ट है। आप जीथब पर स्रोत कोड पढ़ सकते हैं।