आईफोन

Question

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

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

• ढेर
• बहुत सारे वर्गों झटका (उपयोगकर्ता द्वारा यानी प्रत्यक्ष) iPhone धीमी हो जाएगी
• नेस्टेड विधि कॉल प्रदर्शन को नुकसान होगा (यानी द्वारा प्रत्यक्ष जाएगा उपयोगकर्ता)

प्रैक्टिस में मैंने इन मुद्दों का अनुभव नहीं किया है। कुछ iPhone performance metrics पर सतही रूप से देखकर मुझे लगता है कि अतिरिक्त विधि कॉल और ऑब्जेक्ट लाइफ-साइक्सा ओवरहेड सामान्य पैटर्न को लागू करने के लिए आवश्यक है और छोटी विधियों को किसी भी उपयोगकर्ता को समझने योग्य देरी बनाने की संभावना नहीं है। हालांकि, अन्य आईफोन डेवलपर्स की सलाह ने मुझे थोड़ा सा झुका दिया है।

मैं डोमेन अज्ञेय प्रोग्रामिंग प्रथाओं को सीखना और परिशोधित करना जारी रखना चाहता हूं जिन्होंने मुझे अतीत में अच्छी तरह से सेवा दी है, लेकिन जब आईफोन पर विकास होता है तो मैं ऐसे मार्ग को नीचे नहीं करना चाहता जो दर्द में खत्म हो जाए!

तो इस प्लेटफ़ॉर्म के संबंध में - क्या मुझे कुछ सामान्य सर्वोत्तम प्रथाओं को त्यागना चाहिए और विधि कॉल को अनुकूलित करने और जीवन चक्र ओवरहेड को ऑब्जेक्ट करने के बारे में अधिक जागरूक होना चाहिए? या मैं Knuth's सलाह निम्नलिखित जारी रखना चाहिए:

समय से पहले अनुकूलन सब बुराई (या कम से कम इसमें से अधिकांश) में

Answer 1

मेरे लिए प्रोग्रामिंग यह वास्तव में रख-रखाव के लिए नीचे आता है की जड़ है। अच्छी गुणवत्ता वाले कोड के साथ आप सिस्टम को इतना आसान बना सकते हैं।

मेरे पास ऐसे डेवलपर हैं जो मेरे साथ काम करते हैं और जब मेरा सुझाव है कि वे सिस्टम को काम करने के लिए कम कटौती करते हैं, तो वे मुझ पर घृणा करते हैं और परियोजना को देर से वितरित करते हैं। और यह हर बार लंबे समय तक भुगतान किया है !!!

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

और यदि आप ढेर को उड़ाते हैं, तो उन तरीकों/कक्षाओं में से कुछ को एकल कॉल में फिर से कारक करें (कम से कम आप जानते हैं कि यह हो सकता है और जैसे ही यह होता है) और यदि यह नहीं है तो आपके पास शानदार है बनाए रखने के लिए कोड जिसे किसी भी आधा बेक्ड कोड बंदर द्वारा आसानी से पठनीय किया जाता है जिसे इसे बाद में देखना होता है।

Answer 2

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

यदि आपकी ऑब्जेक्ट्स का बहुत उपयोग किया जाता है, और आपके पास अक्सर कुछ निचले स्तर की ऑब्जेक्ट्स होती हैं जिन्हें आप अक्सर कॉल करते हैं, तो हो सकता है कि आप शायद उनका उपयोग करने से प्रदर्शन प्राप्त कर सकें - लेकिन मैं लाखों कॉलों के बारे में बात कर रहा हूं (मैंने देखा है मेरे समय में कुछ भयानक कोड, दोनों संरचित, संरचित और ओओ!)। यदि आप निरंतर वस्तुओं के बहुत सारे (एलओटीएस) आवंटित और हटाते हैं तो आपको अधिक प्रदर्शन हिट भी मिल जाएगी।

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

'सुरुचिपूर्ण' कोड और कोड के बीच एक व्यापार बंद है जो आसानी से और जल्दी से काम करता है, डॉन या तो चरम पर नहीं जाते हैं और आपको ठीक होना चाहिए।

Answer 3

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

Answer 4

आम तौर पर बोलते हुए: इसके बारे में चिंता न करें। एकमात्र मामला जहां वस्तुओं और संदेशों का उपयोग करना एक संभावित प्रदर्शन मुद्दा हो सकता है, जहां आप एक बार में सैकड़ों या हजारों आवंटन कर रहे हैं, या हजारों संदेश हर कुछ एमएस भेजते हैं। आप भौतिकी सिमुलेशन में हजारों 3 डी वैक्टरों का प्रतिनिधित्व करने के लिए ओब्जे-सी ऑब्जेक्ट्स का उपयोग नहीं करना चाहेंगे।

यहां तक ​​कि जिस मामले में आप बहुत सारे संदेश लूप में भेज रहे हैं, आप लूप से पहले उचित विधि में फ़ंक्शन पॉइंटर संग्रहीत करके बेहतर प्रदर्शन प्राप्त कर सकते हैं।