Блог

Я нахожусь в процессе создания платформы облачной интеграции для iOS. Мы позволяем вам сохранять, запрашивать, подсчитывать и удалять синхронно и асинхронно с помощью реализаций селектора / обратного вызова и блока. Какова правильная практика? Запуск блоков завершения в основном потоке или фоновом потоке?

Для простых случаев я просто параметрирую его и выполняю всю работу, которую могу, во вторичных потоках:

• По умолчанию обратные вызовы будут выполняться в любом потоке (где это наиболее эффективно и прямолинейно — обычно после завершения операции). Это значение по умолчанию, потому что обмен сообщениями через main может быть довольно дорогостоящим.

• Клиент может дополнительно указать, что сообщение должно быть сделано в основном потоке. Таким образом, для этого требуется одна строка или аргумент. Если безопасность важнее эффективности, то вы можете инвертировать значение по умолчанию.

• Вы также можете попытаться выполнить пакетную обработку и объединить некоторые сообщения или просто использовать таймер в основном цикле выполнения для отправки.

• Рассмотрите как объединенные, так и отдельные модели для некоторых ваших работ.

Если вы можете свести задачу к результату (удалить возможность дополнительных обновлений, если это не требуется), тогда вы можете просто запустить задачу, выполнить работу и предоставить результат (или ошибку) по завершении.

NSURLConnection Класс Apple вызывает свои методы делегирования в потоке, из которого он был инициирован, выполняя свою работу в фоновом потоке. Это кажется разумной процедурой. Вполне вероятно, что пользователю вашего фреймворка не понравится беспокоиться о безопасности потоков при написании простого блока обратного вызова, как это было бы, если бы вы создали новый поток для его запуска.

Две стороны медали: если обратный вызов касается графического интерфейса, он должен выполняться в основном потоке. С другой стороны, если этого не произойдет и потребуется много работы, запуск его в основном потоке заблокирует графический интерфейс, вызывая разочарование у конечного пользователя.

Вероятно, лучше всего поместить обратный вызов в известный документированный поток и позволить программисту приложения определить влияние на графический интерфейс.