Задержка с NSFileCoordinator coordWritingItemAtURL

Question

Я настраиваю NSFileCoordinator и NSFilePresenter в своем приложении, поэтому я могу сделать файл IO из приложения AppleWatch безопасным. В моем коде есть несколько мест, где я пишу в файл пару раз подряд. Это проблема сама по себе, и я работаю над ее исправлением, но я замечаю какое-то странное поведение в этом процессе.

я обернуть мои пишет так:

//In a class that implements NSFilePresenter: 
NSFileCoordinator *coord = [[NSFileCoordinator alloc]initWithFilePresenter:self]; 
[coord coordinateWritingItemAtURL:self.presentedItemUrl options:0 error:nil byAccessor:^(NSURL *url) 
{ 
    //do my writing here using CFWriteStreamRef or NSOutputStream 
}]; 

На первой записи, блок записи происходит в течение 1 мс. Но после этого, существует около 0,5 секундной задержки между вызовом coordinateWritingItemAtURL и исполняемым блоком записи.

Ожидается ли такое поведение?

Some of the documentation для NSFileCoordinator и NSFilePresenter говорит использовать prepareForReadingItemsAtURLs:writingItemsAtURLs:options:error:byAccessor: для пакетных операций, но это кажется странным, чтобы получить такую ​​длительную задержку, когда я не партий.

Обновление: Это происходит и при чтении.

Обновление 2:Here - пример проекта, воспроизводящий проблему.

Update 3: Используя этот API взаимодействия между приложением и его расширение для apparently является badidea. Но вопрос все еще стоит.

Answer 1

Можно ли использовать опции NSFileCoordinatorReadingImmediatelyAvailableMetadataOnly для чтения и NSFileCoordinatorWritingContentIndependentMetadataOnly для записи в некоторых случаях? Похоже, что варианты iOS8 могут вам помочь.

Answer 2

Ссылаясь на File System Programming Guide, вы можете прочитать следующее:

вы можете избежать включения изменений непосредственно из вашего файла метода ведущий. Вместо этого отправьте блок асинхронно в очередь отправки и обработайте изменения позже. Это позволяет обрабатывать изменения при удобстве вашего приложения, не вызывая ненужные задержки координатору файла, который инициировал изменение. Конечно, при сохранении или отказе от контроля файла (например, в в relinquishPresentedItemToReader:, relinquishPresentedItemToWriter: или savePresentedItemChangesWithCompletionHandler: методы) вы должны выполнить все необходимые действия немедленно и не defer их.

Я думаю, что это ваш случай, когда вы defering действия.

Возможное решение:

Пожалуйста, ознакомьтесь с this хорошо, правильно обрабатывать несколько последовательных операций письма, то relinquishPresentedItemToWriter, может сделать эту работу, то же самое будет работать с чтением файла, relinquishPresentedItemToReader, предположив что несколько разных объектов пытаются читать и записывать один и тот же файл.

PS:

Я не знаю, что ваше приложение делает точно, но я надеюсь, что вы прочитали это:

Если вы реализуете приложение документа на основе, вам не нужно включают семантику презентатора файла в подклассы NSDocument. Класс NSDocument уже соответствует протоколу NSFilePresenter и реализует соответствующие методы. Таким образом, все ваши документы автоматически регистрируются в качестве презентаторов соответствующего файла и выполняют такие действия, как сохранение изменений и изменение дорожки в документе .