Pull to refresh

Comments 5

Очень здорово! За Layout отдельное спасибо, всегда не с первого раза попадал правильно.
Жаль, что все самые интересные доклады проходят только в Москве :(
В Xamarin.Forms 2.5.0 получились такие показатели для страницы Hello World:
XAML без компиляции 441 мс
XAML с компиляцией 188 мс
Код на C# 182 мс.

182 мс это 5 кадров в секунду и это hello world. Если так для каждой незакешированной ячейки, то Xamarin.Forms есть куда еще расти (мягко говоря). Мне кажется вы могли замерить время jit (на android), либо время подгрузки каких-либо библиотек.


Я как-то мерял скорость маршалинга из C# в ObjC и назад и получалось, что разницы практически нет. Затраты на p/Invoke теряются на фоне типичных операций типа выставления текста (label.Text) и составляют доли %. То есть сам Xamarin оказывает незначительное влияние и точно не медленее ObjC/Swift. Forms другое дело, про них я ничего не знаю, всегда работал только с Native.

182 мс это не «5 кадров в секунду» (откуда вообще fps взялись?), а просто 182 мс (~1/5 секунды) задержки перед открытием экрана или первого в приложении создания контрола — дальше все кешируется. Перфекционизм это хорошо, конечно :)

В плане роста и развития — да, в XF еще много всякого будет дорабатываться и улучшаться.
Прочитав Ваш совет, установил утилиту для RAM disk'а, ту, что выдается первым номером по ссылке в статье. Произвёл замеры (правда, не для Xamarin, а для C++/MFC проекта). Получилась не такая уж и большая выгода в моём случае. На полную перекомпиляцию ушло 4:40 на RAM диске против 4:55 на SSD. 15 секунд — это 5% разницы всего, а заморочки с диском и возможная потеря данных в случае непредсказуемого выключения, на мой взгляд, не стоят того.
> правда, не для Xamarin, а для C++/MFC проекта
Статья не про MFC, а про Xamarin.Forms :)
Sign up to leave a comment.