Укоротить те же операции IO так, чтобы это можно было делать блокируя главный поток без фризов, невозможно. Как кстати и блокирующе синхронизировать из главного потока транзакции с состоянием в более менее серьезном приложении на слабых устройствах - чтобы выдать 60 кадров в секунду нужно тратить на все не более 16 мс. Похоже что вы просто использовали какой то стэк, частично решающий проблему за вас, и не особо задумывались почему оно работает, и тестировали на мощных девайсах с полной батарейкой. Чем это грозит я описал в предыдущем комментарии.
В целом же, по моему опыту, приложения на iOS работают быстрее аналогов на Android. Как и сама система. Думаю в том числе благодаря грамотной многопоточке.
Очередь как раз на тредпуле. Представьте что мы просто копим очередь из Action и выполняем их последовательно в потоках тредпула, по одному. Либо гляньте реализацию очереди на Task, там вообще все элементарно - выстраивается цепочка из Task используя ContinueWith.
Я придерживаюсь мнения, что не знать почему что то работает так же плохо, как и не знать почему НЕ работает ?. Иначе в других условиях, например при существенном увеличении кода проекта, все может начать работать очень плохо, и потребуется полное переписывание проекта чтобы это исправить (и я имею подобный опыт, в тч опыт отказа от таких проектов, чтобы сохранить рассудок).
Без изучения кода приложения не могу ответить на данный вопрос, как и протестировать его на фризы, но по опыту скажу, что лучше бы понимать в многопоточности разрабатывая нативные мобильные приложения.
По поводу SO частично согласен, но там сам вопрос не требует обязательного написания кода, скорее разъяснений, и почти ни у одного ответа примеров кода нет, в том числе принятого. Тут проблема что разъяснять можно очень долго, и поэтому и было принято решение писать данную статью.
Но вообще в ближайшее время планируется обновление документации библиотеки (и ответов на SO) со сравнением с каким нибудь lock, примером для не Task-based очереди и тп. И думаю было бы неплохо собрать здесь конструктивные комментарии перед таким обновлением.
А пока можете глянуть реализации бенчмарков, там есть пример и для Monitor, и для SerialQueue, и др. Делают они одно и то же.
Добавил все таки дополнительный блок с описанием очереди, выделил важные моменты в тексте.
Ну суть вы уловили ?.
Ни в коем случае не присваиваю идею себе - это придумал какой то гений из Apple.
Ну да, O(1) от времени операции это не сильно. Иногда лучше, иногда нет - задача хорошего инженера знать когда и как лучше, и почему.
Такой уж у меня стиль повествования, будем работать над собой. Все таки первый опыт.
Это реализация очереди на Task и Monitor. Бенчмарки находятся вот здесь (#region Benchmarks).
Укоротить те же операции IO так, чтобы это можно было делать блокируя главный поток без фризов, невозможно. Как кстати и блокирующе синхронизировать из главного потока транзакции с состоянием в более менее серьезном приложении на слабых устройствах - чтобы выдать 60 кадров в секунду нужно тратить на все не более 16 мс. Похоже что вы просто использовали какой то стэк, частично решающий проблему за вас, и не особо задумывались почему оно работает, и тестировали на мощных девайсах с полной батарейкой. Чем это грозит я описал в предыдущем комментарии.
В целом же, по моему опыту, приложения на iOS работают быстрее аналогов на Android. Как и сама система. Думаю в том числе благодаря грамотной многопоточке.
Очередь как раз на тредпуле. Представьте что мы просто копим очередь из Action и выполняем их последовательно в потоках тредпула, по одному. Либо гляньте реализацию очереди на Task, там вообще все элементарно - выстраивается цепочка из Task используя ContinueWith.
Я придерживаюсь мнения, что не знать почему что то работает так же плохо, как и не знать почему НЕ работает ?. Иначе в других условиях, например при существенном увеличении кода проекта, все может начать работать очень плохо, и потребуется полное переписывание проекта чтобы это исправить (и я имею подобный опыт, в тч опыт отказа от таких проектов, чтобы сохранить рассудок).
Без изучения кода приложения не могу ответить на данный вопрос, как и протестировать его на фризы, но по опыту скажу, что лучше бы понимать в многопоточности разрабатывая нативные мобильные приложения.
Не знаю как тут ответить. Внутри? ?
По поводу SO частично согласен, но там сам вопрос не требует обязательного написания кода, скорее разъяснений, и почти ни у одного ответа примеров кода нет, в том числе принятого. Тут проблема что разъяснять можно очень долго, и поэтому и было принято решение писать данную статью.
Но вообще в ближайшее время планируется обновление документации библиотеки (и ответов на SO) со сравнением с каким нибудь lock, примером для не Task-based очереди и тп. И думаю было бы неплохо собрать здесь конструктивные комментарии перед таким обновлением.
А пока можете глянуть реализации бенчмарков, там есть пример и для Monitor, и для SerialQueue, и др. Делают они одно и то же.