मल्टीथ्रेडेड कोर डेटा

जैसा कि आप जानते हैं, कोर डेटा एक शक्तिशाली Apple ऑब्जेक्ट ग्राफ प्रबंधन ढांचा है। कोर डेटा के बारे में हैबे पर बहुत सारे लेख हैं, हालांकि, मल्टीथ्रेडिंग खराब रूप से कवर किया गया है, और, यह मुझे लगता है, लगभग सभी ने यह सवाल पूछा कि इसे सही तरीके से कैसे लागू किया जाए।

सामान्य प्रावधान

संक्षेप में, कोर डेटा स्टैक में कई मुख्य भाग होते हैं।



1) NSPersistentStore, जो एक बाइनरी फ़ाइल, XML, SQLite फ़ाइल हो सकती है।
2) NSManagedObjectModel, जो डेटा मॉडल का संकलित बाइनरी संस्करण है।
3) NSPersistentStoreCoordinator, NSPersistentStore और NSManagedObjectModel, बचत और कैशिंग से डेटा लोड करने में लगा हुआ है।
4) NSManagedObjectContext, NSPersistentStore से डेटा को मेमोरी में लोड करना, इंस्टेंस के साथ ऑपरेशन।
5) NSManagedObject - डेटा मॉडल का उद्देश्य।

मेरी राय में, इस सभी चमत्कार की अप्रिय विशेषता यह है कि NSManagedObjectContext थ्रेड-सुरक्षित नहीं है।

स्टैक इनिशियलाइज़ेशन

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

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ //  NSManagedObjectModel NSURL *modelURL = [[NSBundle mainBundle] URLForResource:kModelFileName withExtension:@"momd"]; NSManagedObjectModel *mom = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL]; //  NSPersistentStoreCoordinator NSPersistentStoreCoordinator *psc = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:mom]; //   NSPersistentStoreCoordinator ,          NSURL *doURL = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject]; NSURL *storeURL = [doURL URLByAppendingPathComponent:@"CoreData.sqlite"]; NSError *error = nil; NSPersistentStore *store = [psc addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]; //   }); 

तो, हमारे आवेदन को लॉन्च किया गया था, उपयोगकर्ता को यूआई लैग्स प्राप्त नहीं हुआ था, हर कोई खुश है। हम आगे का अनुसरण करते हैं।

मुख्य संदर्भों का निर्माण

जैसा कि मैंने ऊपर लिखा है, NSManagedObjectContext थ्रेड-सुरक्षित नहीं है। इसलिए, मुख्य थ्रेड पर मुख्य एप्लिकेशन संदर्भ रखना उचित है। लेकिन इस मामले में, यह इस संदर्भ को बनाए रखते हुए UI को धीमा कर देगा, मुझे क्या करना चाहिए? लेकिन यहाँ, iOS 6 में, NSManagedObjectContext प्रकार दिखाई दिए।

1) NSMainQueueConcurrencyType - मुख्य धागे से विशेष रूप से उपलब्ध है।
2) NSPStreetQueueConcurrencyType - एक पृष्ठभूमि थ्रेड पर चलता है।
3) NSConfinementConcurrencyType - उस थ्रेड पर चलता है जिस पर इसे बनाया गया था।

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

 //           . // _daddyManagedObjectContext        ,  . _daddyManagedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; [_daddyManagedObjectContext setPersistentStoreCoordinator:psc]; //      main-thread context,     dispatch_async(dispatch_get_main_queue(), ^{ _defaultManagedObjectContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType]; //     ,       [_defaultManagedObjectContext setParentContext:_daddyManagedObjectContext]; }); 

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

बाल संदर्भों का निर्माण

जैसा कि आप आसानी से अनुमान लगा सकते हैं, जब पृष्ठभूमि के प्रवाह पर काम कर रहे हैं, तो हम पूर्वजों के रूप में ऊपर बनाए गए हमारे बच्चे के संदर्भ को जोड़कर अपने संदर्भों को बना सकते हैं।

 - (NSManagedObjectContext *)getContextForBGTask { NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; [context setParentContext:_defaultManagedObjectContext]; return context; } 

सहेजे जाने पर यह संदर्भ, हमेशा अपने माता-पिता के लिए परिवर्तनों को बचाएगा। इस प्रकार, हमारे पास हमेशा _defaultManagedObjectContext (जो वास्तविक माता-पिता में परिवर्तन को धक्का देता है) में सबसे अधिक प्रासंगिक जानकारी होगी।

सेविंग कॉन्टेक्ट्स

सबसे महत्वपूर्ण बात यह है कि संरक्षण है। पृष्ठभूमि धाराओं पर रहने वाले संदर्भ केवल PerformBlock: और performBlockAndWait: के माध्यम से एक्सेस किए जा सकते हैं। इसलिए, बैकग्राउंड स्ट्रीम को सेव करना इस तरह दिखाई देगा।

 - (void)saveContextForBGTask:(NSManagedObjectContext *)bgTaskContext { if (bgTaskContext.hasChanges) { [bgTaskContext performBlockAndWait:^{ NSError *error = nil; [backgroundTaskContext save:&error]; }]; // Save default context } } 

बच्चे के संदर्भ को बचाने के बाद, आपको माता-पिता को बचाना होगा।

 - (void)saveDefaultContext:(BOOL)wait { if (_defaultManagedObjectContext.hasChanges) { [_defaultManagedObjectContext performBlockAndWait:^{ NSError *error = nil; [_defaultManagedObjectContext save:&error]; }]; } //    _defaultManagedObjectContext    ,   _daddyManagedObjectContext void (^saveDaddyContext) (void) = ^{ NSError *error = nil; [_daddyManagedObjectContext save:&error]; }; if ([_daddyManagedObjectContext hasChanges]) { if (wait) [_daddyManagedObjectContext performBlockAndWait:saveDaddyContext]; else [_daddyManagedObjectContext performBlock:saveDaddyContext]; } } 

निष्कर्ष

कई वर्षों के लिए, मैं अक्सर डेवलपर्स से सुनता हूं कि कोर डेटा में बड़ी संख्या में minuses हैं, इसलिए पसंद के पक्ष में बनाया गया है, उदाहरण के लिए, FMDB , मुख्य तर्क मल्टीथ्रेडिंग है, या यों कहें, माना जाता है कि कोर डेटा में इसकी अनुपस्थिति है। लेख का उद्देश्य इस मिथक को दूर करना है।
कोर डेटा के साथ काम करने के लिए कई रूपरेखाएँ लिखी गई हैं, मुख्य एक, मेरी राय में, MagicalRecord है । इसमें बड़ी मात्रा में कार्यक्षमता शामिल है। यह ध्यान देने योग्य है कि अंदर यह ऊपर वर्णित विधि के अनुसार लगभग काम करता है। किसी भी ढांचे को ठीक से लागू करने की आवश्यकता है, जिसका अर्थ है कि यह कैसे काम करता है।

वह सब है। आपका ध्यान देने के लिए धन्यवाद।