Специфическая проблема iOS 12: повреждение двоичных данных во внешнем хранилище основных данных

24

Я потратил большую часть рабочего дня, пытаясь решить эту проблему.

Фон

У меня простая базовая модель данных с книгами и сеансами чтения. В книгах есть обложки (изображения), которые хранятся в виде двоичных данных с помощью "Разрешить внешнее хранилище".

На iOS 11.4 и ниже все работает отлично все время. Когда я сохраняю новый сеанс, все обновляется должным образом.

проблема

Начиная с iOS 12, когда я создаю новый сеанс чтения и связываю его с книгой, каждый второй раз основные данные генерируют инструкцию SQL, которая также обновляет поле обложки книги, что иногда приводит к плохой ссылке (на файл на диске), которая часто приводит к тому, что обложка равна нулю при перезапуске приложения и почти всегда создает дубликат копии обложки на диске (как видно _EXTERNAL_DATA папки Simulator _EXTERNAL_DATA).

Контекст и объекты в памяти остаются правильными (и, следовательно, все в пользовательском интерфейсе), пока приложение не будет перезапущено, тогда обложка часто равна нулю.

Спецификация iOS 12

На iOS 12 я могу детерминистически воспроизвести ошибку в симуляторе, на физических устройствах, и пользователи также сообщили об ошибке. Я не могу воспроизвести ошибку на iOS 11.4, и ни одна из пользователей не сообщила об ошибке, предшествующей iOS 12.

Сделанные шаги

  • Я включил " -com.apple.CoreData.ConcurrencyDebug 1 ", поэтому не должно быть, что я получаю доступ к чему-либо из неправильной очереди. Я также включил " -com.apple.CoreData.SQLDebug 3 ", чтобы я мог точно видеть, что написано.

  • Я убедился, что экземпляр книги (и, следовательно, обложка) не изменен моим кодом перед ассоциацией с новым newSession.book = book проверив hasChanges, как раз перед тем, как я сделаю newSession.book = book и context.save().

  • Чтобы быть на 100% уверенным, что я не касаюсь свойства обложки ни на одном потоке, я коротко замыкал мои получатели и сеттеры для этого свойства. Без улучшения.

  • Я попытался использовать objectID для запроса экземпляра книги непосредственно перед ассоциацией и сохранения. Без улучшения.

  • Я даже попробовал вариант, где контекст содержит сильные ссылки на все объекты, просто чтобы убедиться, что это не проблема управления памятью. Без улучшения.

Вопрос

Любые идеи для следующих шагов?

Обновление статуса

Это дефект в iOS 12. См. Принятый ответ ниже для подробного описания резонансного обходного пути.

  • 1
    Я думаю, что у меня точно такая же проблема. Любые обходные пути или решения для этого будут высоко оценены!
  • 2
    Я думаю, что мы столкнулись с той же ошибкой, хотя и с другим вариантом использования. forums.developer.apple.com/thread/109189
Показать ещё 3 комментария
Теги:
core-data
ios12

1 ответ

7
Лучший ответ

Обновление. Основная проблема с основными данными, по-видимому, разрешена в iOS 12.1 (проверена в бета-версии 4). Мы сохраним обходное решение, описанное ниже в нашем приложении, и в ближайшее время не будем рекомендовать использование опции внешнего хранилища.

После разговора с инженерами Apple и подачи радара, упомянутого выше, мы не могли подождать исправления, поэтому мы взяли его и переключили на хранение файлов в файловой системе и сами управляли им.

Другой альтернативой, которую мы рассматривали, была миграция нашей модели, чтобы не допускать использование внешнего хранилища для BLOB, но я не знаю, какое влияние это оказало бы на производительность, и я также беспокоился о миграции модели в момент, когда эта часть iOS кажется быть неустойчивым, особенно после чтения таких историй в прошлом: Основные данные: не хранить большие файлы в виде двоичных данных - Alexander Edge - Medium

Это не было слишком большой проблемой для самообслуживания локального хранилища. Вам просто нужно иметь уникальный идентификатор для каждой записи, который вы можете использовать для создания имени файла, чтобы вы могли сопоставлять файлы с записями. Мы добавили расширение к нашему подклассу Managed Object с методами для чтения, записи и удаления файлов. Теперь вместо вызова, например article.photo = image.pngData(), теперь нам нужно вызвать что-то вроде article.savePhoto(image.pngData()) а затем мы делаем подобное, когда хотим получить изображение. Вы также можете добавить код к этим методам для поддержки обратной совместимости с любыми изображениями, которые в настоящее время хранятся в Core Data.

Удаление было немного сложнее, потому что наши объекты удалены из нескольких мест в коде, включая каскадные удаления. В конце концов я решил сделать это в методе prepareForDeletion управляемого объекта, но он не идеален. Существует много дискуссий о том, как лучше всего реализовать это здесь: cocoa - Как обрабатывать очистку внешних данных при удалении несохраненных объектов Core Data? - Переполнение стека

Наконец, чтобы предотвратить сбой приложения после того, как из-за этой ошибки исчезнет необязательный двоичный атрибут, я переопределяю awakeFromFetch в моем подклассе Managed Object, чтобы гарантировать, что любые необходимые атрибуты не равны нулю, а если они есть, я установил их в placeholder чтобы они могли быть сохранены без сбоев проверки.

Поделиться
  • 0
    Ницца! Я решил эту проблему почти точно так же. Я также не мог дождаться, пока Apple исправит это. Также я чувствую, что файлы, URL-адреса которых я знаю и к которым я могу получить прямой доступ, являются для меня лучшим решением в долгосрочной перспективе.
  • 0
    Забавно, мы сделали то же самое. Теперь мы храним изображения в файловой системе с уникальным UUID, хранящимся в coredata.
Показать ещё 5 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню