UIViewController का जीवन चक्र

अधिकांश iOS एप्लिकेशन एक या दूसरे तरीके से UIViewController का उपयोग करते हैं। जहां UIKit ढांचा है, वहां UIViewController है । उनमें से कई हैं, वे हर जगह हैं, वे हर कोने में घात लगाए बैठे हैं और झांक रहे हैं। इसलिए, कोई भी आईओएस प्रोग्रामर - चाहे वह एक हरे रंग की शुरुआत करने वाला हो, जिसने प्रोग्रामिंग पथ पर मुश्किल से पैर रखा हो, या अपने क्षेत्र के अनुभवी पेशेवर हों, उन्हें UIViewController के बारे में सब कुछ पता होना चाहिए।

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

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

सभी इच्छुक हैं, कृपया बिल्ली के नीचे

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

UIViewController के बारे में

यह MVC डिजाइन पैटर्न के अनुसार एक नियंत्रक है। मॉडल और प्रदर्शन के संबंध प्रदान करता है IOS में, इसे देखने के जीवन चक्र को नियंत्रित करने और विभिन्न डिवाइस ओरिएंटेशन में UIView को प्रदर्शित करने से संबंधित कार्य सौंपे गए हैं। सामान्य जानकारी एक ही दस्तावेज में पाई जा सकती है।

एक UIViewController और उसके UIView का जीवनचक्र

हम उन तरीकों पर ध्यान केंद्रित करते हैं जो UIViewControllera के जीवन चक्र के लिए जिम्मेदार हैं:

सृजन

• init
• initWithNibName:

दृश्य बनाएँ

• (BOOL) .दृश्य है
• loadView
• viewDidLoad
• (UIView *) initWithFrame: (CGRect) फ्रेम
• (UIView *) initWithCoder: (NSCoder *) कोडर

हैंडलिंग स्थिति में परिवर्तन

• viewDidLoad
• viewWillAppear: (BOOL) एनिमेटेड
• viewDidAppear: (BOOL) एनिमेटेड
• देखेंविकास: (BOOL) एनिमेटेड
• viewDidDisappear: (BOOL) एनिमेटेड
• viewDidUnload

स्मृति चेतावनी प्रसंस्करण

• didReceiveMemoryWarning

विनाश

• viewDidUnload
• dealloc

कुछ विधियाँ एक साथ दो वर्गों में गिर गईं, उन पर अलग से चर्चा की जाएगी। एक युगल अधिक विधियां एक यूआईवीईवी बनाने से संबंधित हैं। उन पर भी थोड़ा ध्यान दिया जाएगा।

और अब, पहली चीजें पहले।

सृजन

एक नियंत्रक बनाने के लिए, या बल्कि, इसे आरंभ करने के लिए, दो मुख्य विधियाँ हैं - init और initWithNibName: (NSString *) nibNameOrNil । वास्तव में, init विधि initWithNibName: को बुलाएगी, ताकि आप केवल इस पर विचार कर सकें।

विधि का तर्क काफी सरल है - हम या तो .xib (.nib) फ़ाइल ढूंढते हैं और इसे UIViewController के साथ जोड़ते हैं , या हम इसे संबद्ध नहीं करते हैं। इस स्तर पर, xib फ़ाइल का नाम बस याद रखा जाता है, जिसमें से, किस स्थिति में, आपको दृश्य लोड करने की आवश्यकता है।

UITableViewController के वंशजों से संबंधित एक अपवाद है जिसके बारे में आपको पता होना चाहिए (धन्यवाद हैब्रायुज़र के लिए ):

@interface HabrTestProjectTableViewController : UITableViewController { } @end /*      HabrTestProjectTableViewController.xib      */ HabrTestProjectTableViewController * tableViewController = [[HabrTestProjectTableViewController alloc] init]; /*     UITableViewController,     xib  */ HabrTestProjectTableViewController * tableViewController = [[HabrTestProjectTableViewController alloc] initWitNib:@"HabrTestProjectTableViewController" bundle:nil]; 

महत्वपूर्ण: इस स्तर पर, न तो स्वयं दृश्य है और न ही आउटलेट।

 @interface HabrTestProjectViewController : UIViewController { UIButton * _likeButton; NSDictionary * _userDictionary; } @property(nonatomic, retain) IBOutlet UIButton * likeButton; - (IBAction)buttonClicked:(id)sender; @end HabrTestProjectViewController * controller = [[HabrTestProjectViewController alloc] init]; /*       */ NSLog(@"%@", controller.likeButton); /* (null) */ /*    */ if (controller.view) { NSLog(@"View was created"); /*   , .. controller.view  view */ } /*    */ if ([controller isViewLoaded]) { NSLog(@"View was created"); /*    ,  view  */ } 

बनाया गया UIViewController लंबे समय तक "नो व्यू " स्थिति में हो सकता है, जब तक कि यह मेमोरी से डिलीट न हो जाए। एक दृश्य बनाना केवल [ viewController view ] ( viewController.view ) विधि के बाद कहा जाता है। आप इसे कर सकते हैं, या यह UINavigationController , UITabBarController और कई अन्य लोगों द्वारा किया जा सकता है।

एक उदाहरण जब UIViewController "नो व्यू " स्थिति में है, UITabBarController का उपयोग करते हुए एक वेरिएंट हो सकता है, जब इसमें शुरू में N नियंत्रकों के लिंक होते हैं, और केवल वह जो वर्तमान में स्क्रीन पर प्रदर्शित होता है, उसमें दृश्य लोड होगा। बाकी सभी तब तक इंतजार करेंगे जब तक उपयोगकर्ता टैब को स्विच नहीं करता है, या जब तक कि घुमावदार अनुभवहीन प्रोग्रामर नॉनविजेल व्यू कॉन्ट्रैक्टर.व्यू को कॉल नहीं करता है ।

त्रुटि # 1 (l): दृश्य लोड करने से पहले आउटलेट तक पहुंच
गलती # 2 (पी): देखने से पहले लोड हो रहा है वास्तव में जरूरत है, नजरअंदाज विधि है
गलती # 3 (पी): initWithNibName विधि में दृश्य घटक बनाना

एक UIView बनाना

दृश्य तक पहुँच प्राप्त होने के बाद, तीन संभावित परिदृश्य हैं

• अधिभार loadView पद्धति को कॉल करना
• अपरिभाषित विधि loadView को कॉल करना जो या तो xib फ़ाइल से दृश्य लोड करता है या एक खाली UIView बनाता है

और उसके बाद ही, viewDidLoad विधि को आखिरकार कहा जाएगा।

अगले पैराग्राफ पर जाने से पहले, मुझे UIViews के बारे में कुछ शब्द कहने की ज़रूरत है जो xibs के अंदर हैं। ऐसी स्थिति की कल्पना करें जहां बनाया गया UIPrettyView xib में स्थित है, जिसे जब आरंभीकृत किया जाता है, तो पृष्ठभूमि का रंग गुलाबी करना चाहिए। इसलिए, शरीर के किसी भी हिस्से पर किसी को खींचने के लिए नहीं, मैं तुरंत कहूंगा - अगर यूआईवीईवी को जिब से लोड किया गया है, तो initWithCoder: इनिशियलाइज़ेशन विधि कहा जाएगा : अन्यथा (जब कोड में बनाया जाता है), initWithFrame विधि आमतौर पर कहा जाएगा :

 /*      xib' */ - (id)initWithFrame:(CGRect)frame { ... [self setBackgroundColor:[UIColor pinkColor]]; // [self performInitializations]; ... } /*     xib' */ - (id)initWithCoder:(NSCoder *)coder { ... [self setBackgroundColor:[UIColor pinkColor]]; // [self performInitializations]; ... } /*        */ - (void)performInitializations { [self setBackgroundColor:[UIColor pinkColor]]; } 

दृश्य को जिब से लोड होने के बाद, डिजाइन तत्वों को "खत्म" करने के लिए एक अच्छी जगह है व्यूडालड विधि। यह वह जगह है जहां यह दृश्य घटकों को बनाने के लायक है, जो किसी कारण से, xib या loadView पद्धति में नहीं आया।

गलती # 4 (l): initWithFrame के साथ भ्रम : और initWithCoder:।

हैंडलिंग स्थिति में परिवर्तन

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

 - (void)viewDidLoad { [super viewDidLoad]; _userDictionary = [[NSDictionary alloc] init]; /*    */ } - (void)viewDidUnload { [super viewDidUnload]; } - (void)dealloc{ [_userDictionary release], _userDictionary = nil; [super dealloc]; } 

और अब, यह UIViewController के जीवन के सशर्त आरेख को देखने का समय है


जैसा कि आप आरेख से देख सकते हैं (उम्मीद है), व्यूडीडलड विधि को नियंत्रक के जीवन के दौरान एक से अधिक बार कहा जा सकता है। नतीजतन, उपरोक्त कोड हर नए viewDidLoad कॉल के साथ मेमोरी लीक का कारण हो सकता है

त्रुटि # 5 (l) : viewDidLoad को नियंत्रक जीवनकाल के दौरान एक बार कहा जाता है।

वास्तव में, दृश्य नियंत्रक की स्थिति को पुनर्स्थापित करने के लिए इस पद्धति का उपयोग करना बहुत उपयोगी है। इसलिए, बहुत बार उदाहरणों में आप UIScrollView में स्थिति सेट कर सकते हैं, दृश्य घटकों को वास्तविक स्थिति (सक्रिय / निष्क्रिय) पर सेट कर सकते हैं।

यह ध्यान दिया जाना चाहिए कि नियंत्रक के जीवन चक्र के इस स्तर पर, दृश्य आकार प्रासंगिक नहीं हैं, अर्थात प्रदर्शित होने के बाद वे क्या नहीं होंगे। इसलिए, व्यूडोड विधि में दृश्य की चौड़ाई / ऊंचाई के आधार पर गणना का उपयोग करने की अनुशंसा नहीं की जाती है।

# 6 त्रुटि (यू) : अपने मूल राज्य के लिए इंटरफ़ेस वापस करने के लिए viewDidload ।
गलती # 7 (एल) : चौड़ाई / ऊंचाई दृश्य का उपयोग करते हुए घटक आकार, गणना

देखें

पहले और बाद में देखे जाने वाले तरीके स्क्रीन पर दिखाई देते हैं।
एनीमेशन के मामले में (मोडल विंडो में कंट्रोलर की उपस्थिति, या UINavigationController ई के लिए संक्रमण), viewWillAppear एनीमेशन से पहले बुलाया जाएगा, और देखने के बाद दिखाई देगा।
ViewWillAppear को कॉल करते समय, दृश्य पहले से ही पदानुक्रम में है और वास्तविक आयाम हैं, ताकि यहां आप दृश्य की चौड़ाई / ऊंचाई के आधार पर गणना कर सकें।

देखें

प्रोग्रामर द्वारा उपयोग किए जाने वाले तरीके बहुत ही संक्षिप्त हैं। उसी तरह से काम करें जैसे कि viewWillAppear और viewDidAppear , बस विपरीत;)

viewDidUnload

अधिकांश त्रुटियां इस पद्धति में सबसे अधिक बार पाई जाती हैं।
इसलिए, हमें यह समझना चाहिए कि इसमें क्या हो रहा है।

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

इसलिए, इस पद्धति के सही संचालन और समग्र रूप से कार्यक्रम के लिए, यह आवश्यक है:
- जीरो ऑल आउटलेट्स।
- यदि संभव हो, तो अगली व्यूडिलडैड कॉल में इसे पुनर्स्थापित करने के लिए दृश्य स्थिति को सहेजें।
- ऐसे तरीकों को न कहें जो लोडिंग दृश्य को जन्म देगा।
- नियंत्रक स्थिति को संग्रहीत करने के लिए आउटलेट का उपयोग न करें।

कार्य सरल और स्पष्ट है, लेकिन 90% नौसिखिए डेवलपर्स इसके बारे में नहीं जानते हैं और इसे भूल जाते हैं।

 - (void)viewDidUnload { /*    */ [super viewDidUnload]; /*  ,   .        view */ UIView * observer = self.view; [[NSNotificationCenter defaultCenter] removeObserver:view]; } 

त्रुटि # 8 (पी) viewDidUnload विधि खाली है और लग रहा है [सुपर viewDidUnload]
# 9 त्रुटि (p) व्यूडाउन लोड विधि आउटलेट को मुक्त नहीं करती है
त्रुटि # 10 (यू) व्यूडिडनलोड विधि नियंत्रक की स्थिति को नहीं बचाती है
त्रुटि # 11 (l) आउटलेट्स का उपयोग करके स्टोर कंट्रोलर स्टेट

स्मृति चेतावनी प्रसंस्करण

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

त्रुटि # 12 (p) स्मृति में संसाधनों का संग्रहण जो किसी फ़ाइल में कैश करने के लिए स्वतंत्र रूप से फ्लश किया जा सकता है।

विनाश

नियंत्रक में टैकलॉक की विशेषताओं में से, यह ध्यान दिया जाना चाहिए कि यह एक तथ्य नहीं है कि इससे पहले viewDidUnload कहा जाएगा।
कुछ तृतीय-पक्ष पुस्तकालयों के कार्यान्वयन में, उदाहरण के लिए, तीन20 में, आप सीधे डीलडॉक में viewDidUnload कॉल को पूरा कर सकते हैं।
बाकी के लिए, स्मृति प्रबंधन प्रोग्रामिंग गाइड में निर्धारित सिद्धांतों का पालन करें।

यह लगभग सभी है।
आमतौर पर की गई त्रुटियों के संबंध में कुछ स्पष्टीकरण नीचे दिए जाएंगे।

सामान्य त्रुटियों की व्याख्या

त्रुटियों को सशर्त रूप से तीन प्रकारों में विभाजित किया जाता है:
पी - perfromance त्रुटि (स्मृति लीक करने के लिए त्रुटि, कार्यक्रम धीमा)
एल - तर्क त्रुटि (एक त्रुटि जो गलत प्रोग्राम ऑपरेशन के कारण हो सकती है, गलत मान्यताओं / मान्यताओं के कारण)
यू - उपयोगकर्ता अमित्र त्रुटि (वास्तव में एक त्रुटि नहीं है, बल्कि केवल एक अनुस्मारक है कि उपयोगकर्ता इंटरफ़ेस उपयोगकर्ता के अनुकूल होना चाहिए)

• त्रुटि # 2 (p): वास्तव में जरूरत से पहले दृश्य लोड हो रहा है।
  अक्सर, विशेष रूप से नौसिखिए डेवलपर्स के पास एक अलग राज्य वस्तु में भंडारण राज्य की बुरी आदत होती है, लेकिन नियंत्रक की दृष्टि में (त्रुटि # 11 देखें)। इन कारणों से, आप इस तरह से एक कोड का निरीक्षण कर सकते हैं:
  

    //   SettingsController * settings = [self.tabBarController.viewControllers objectAtIndex:3]; //     if (settings.view.password.text && [settings.view.password length]) { } // Settings view.      //           

  
  इसके अलावा, व्यक्ति अक्सर फॉर्म के बयानों को सही ठहराते हुए सुन सकता है: "सेटिंग्स दृश्य" हमेशा स्मृति में होना चाहिए, क्योंकि अन्यथा, उपयोगकर्ता को बूट होने तक इंतजार करना होगा। और टैब स्विचिंग बहुत धीमी हो जाएगी! एक विकल्प के रूप में, आप हमेशा दृश्य के क्रमिक लोडिंग के विकल्प पर विचार करना चाहिए और अत्यधिक मामलों में, "लोड हो रहा है" सेट करें।
  
• गलती # 3 (पी): initWithNibName विधि में दृश्य घटक बनाना
  प्रदर्शन में बेल्ट के नीचे सीधे हिट। क्योंकि नियंत्रक का प्रारंभ अभी तक यह वादा नहीं करता है कि इसका दृश्य स्क्रीन पर प्रदर्शित किया जाएगा, और दृश्य घटक भी। मेमोरी का उपयोग कुछ भी नहीं (अदृश्य घटकों के लिए) किया जाता है, और उन्हें बनाने में समय लगता है
  
• त्रुटि # 6 (u): viewDidLoad पर , इंटरफ़ेस को उसकी मूल स्थिति में लौटाएँ ।
  त्रुटि # 10 (यू): viewDidUnload विधि नियंत्रक स्थिति को नहीं बचाता है
  आप इस तरह के एक उदाहरण पर विचार कर सकते हैं - उपयोगकर्ता ने पुस्तक को पढ़ा, पेज एन पर रोक दिया, हम इसे अगली बार शुरू होने वाले पहले पृष्ठ पर वापस कर देते हैं। इस घटना से उपयोगकर्ता "बहुत प्रसन्न होगा"। ये छोटी चीजें अनुप्रयोगों के बीच भेद करती हैं कि "किसी कारण से" मैं अनुप्रयोगों से बार-बार भागना चाहता हूं "पोक्ड और भूल गया।"
  उपयोगकर्ता को हमेशा उसी स्थान पर वापस करना संभव नहीं है जहां वह था, और यह हमेशा आवश्यक नहीं है। लेकिन जहां यह संभव है - यह करना बहुत ही वांछनीय है (आखिरकार, आईफोन डैंडी या सेगा मेगाड्राइव नहीं है)।
  
• त्रुटि # 11 (l) आउटलेट्स का उपयोग करके स्टोर कंट्रोलर स्टेट
  त्रुटि आवेदन में वास्तु अंतराल को इंगित करती है। यह विभिन्न प्रकार के UISwitchView , UITextField , UITextView में आवेदन की स्थिति को संग्रहीत करने के लिए असंभव / आवश्यक नहीं है / नहीं है। उपयोगकर्ता इनपुट के अंत के बाद, स्थिति ऑब्जेक्ट में डेटा को बचाने / अपडेट करने के लिए आवश्यक है (यदि यह नियंत्रक की स्थिति है, तो इसे नियंत्रक गुणों में संग्रहीत किया जा सकता है)। लेकिन इसके लिए विजुअल पार्ट का इस्तेमाल न करें।
  
• त्रुटि # 12 (p) स्मृति में संसाधनों का संग्रहण जो किसी फ़ाइल में कैश करने के लिए स्वतंत्र रूप से फ्लश किया जा सकता है।
  जितना संभव हो उतना मेमोरी को मुक्त करना आवश्यक है। हर कोई इसे समझता है। और वे अपने सिर को हिलाते हैं जब उनसे पूछा जाता है कि क्या वे समझते हैं कि जितना संभव हो उतना मुक्त करने का क्या मतलब है। और वे नियंत्रक की स्मृति में 10 छवियों को छोड़ देते हैं, जो उपयोगकर्ता को दिखाई नहीं देता है, क्योंकि "क्या होगा यदि उपयोगकर्ता नियंत्रक में प्रवेश करता है?" ऐसी स्थितियों से बचने की कोशिश करें। विभिन्न कैश का उपयोग करें, कम से कम एक ही NSURLCache ।
  

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

ध्यान देने के लिए आप सभी का धन्यवाद।

अद्यतन। ViewDidUnload विधि का वर्णन ठीक किया
अद्यतन। InitWithNibName में UITableViewController के वारिसों के लिए एक अपवाद : बंडल: विधि ( muryk हैब्रोसर के लिए धन्यवाद) माना जाता है
अद्यतन। श्रमिकों के अनुरोध पर, मैं सामग्री को मजबूत करने के लिए एक छोटी परियोजना पोस्ट करता हूं