Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале:
— Рендеринг интерфейса происходит на главном потоке приложения;
— Рендеринг интерфейса происходит с нормальным приоритетом;
Даже с Galaxy Nexus, или четырехъядерным процессором EeePad Transformer Prime, нет никакого способа, чтобы гарантировать гладкость и приемлемую частоту кадров, если эти два конструктивных ограничения остаются в силе. Это говорит, что мощности Galaxy Nexus хватит чтобы сравнится по плавности работы с первым iPhone трехлетней давности.
Остальное — по ссылке (перевод там достаточно косноязычен, но читабелен)
Здравствуйте, Mamut, Вы писали:
M>Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале: M>— Рендеринг интерфейса происходит на главном потоке приложения;
Неверно. Автор — мудаг, креатив — отстой.
Автора уже поправили, что в iOS рисование точно так же происходит в основном потоке. В специальном потоке рисуются только стандартные анимации и выполняется композиция.
Ровно как и в Андроиде — финальной композицией окон занимается системный процесс. Проблема в том, что стандартные анимации в Андроиде хотя и ускорены аппаратно и их рисованием занимается отдельный процесс, они управляются из основного потока. Так что если цикл событий не справляется, то получаются задержки.
M>— Рендеринг интерфейса происходит с нормальным приоритетом;
И что? Процессора должно хватать на всё.
M>>Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале: M>>— Рендеринг интерфейса происходит на главном потоке приложения; C>Неверно. Автор — мудаг, креатив — отстой.
C>Тут вот от инженера из Гугла: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s C>С коррекциями сама статья: https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
C>Автора уже поправили, что в iOS рисование точно так же происходит в основном потоке. В специальном потоке рисуются только стандартные анимации и выполняется композиция.
C>Ровно как и в Андроиде — финальной композицией окон занимается системный процесс. Проблема в том, что стандартные анимации в Андроиде хотя и ускорены аппаратно и их рисованием занимается отдельный процесс, они управляются из основного потока. Так что если цикл событий не справляется, то получаются задержки.
Это интересно. Просто как по мне, так интерфейс андроида реально не такой плавный (а на Wildifre еще и лагает).
M>>— Рендеринг интерфейса происходит с нормальным приоритетом; C>И что? Процессора должно хватать на всё.
Агага. Но не хватает. Может поэтому Андроид так активно лезет на двух-нцатиядерные процессоры?
Здравствуйте, Mamut, Вы писали:
M>>>Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале:
M>Агага. Но не хватает. Может поэтому Андроид так активно лезет на двух-нцатиядерные процессоры? :)
ну выпустят версию 4.1 и сделают плавным если жалобы имееются
все равно Apple это титаник с пробитым бортом фигли тут спорить
Здравствуйте, Mamut, Вы писали:
C>>Ровно как и в Андроиде — финальной композицией окон занимается системный процесс. Проблема в том, что стандартные анимации в Андроиде хотя и ускорены аппаратно и их рисованием занимается отдельный процесс, они управляются из основного потока. Так что если цикл событий не справляется, то получаются задержки. M>Это интересно. Просто как по мне, так интерфейс андроида реально не такой плавный (а на Wildifre еще и лагает).
Я не замечаю особой лаговатости в самом UI. Проблема именно в анимациях — на iOS они "зачитены" так, что всегда плавные, даже если само приложение тормозит. А так как ощущения — это всё, то и весь UI кажется плавным.
Следующий вопрос — как всё-таки сделать интерфейс более отзывчивым. Самый простой и тупой способ — взять побольше процессора и не мучаться. Более сложные способы — это изобрести что-то типа WPF с отделением визуальной модели от логической. А потом рендерить визуальную модель независимо от логической.
M>>>— Рендеринг интерфейса происходит с нормальным приоритетом; C>>И что? Процессора должно хватать на всё. M>Агага. Но не хватает. Может поэтому Андроид так активно лезет на двух-нцатиядерные процессоры?
Дело в том, что если процессор перегружен, то игры с приоритетами могут сделать только хуже.
C>>>Ровно как и в Андроиде — финальной композицией окон занимается системный процесс. Проблема в том, что стандартные анимации в Андроиде хотя и ускорены аппаратно и их рисованием занимается отдельный процесс, они управляются из основного потока. Так что если цикл событий не справляется, то получаются задержки. M>>Это интересно. Просто как по мне, так интерфейс андроида реально не такой плавный (а на Wildifre еще и лагает). C>Я не замечаю особой лаговатости в самом UI. Проблема именно в анимациях — на iOS они "зачитены" так, что всегда плавные, даже если само приложение тормозит. А так как ощущения — это всё, то и весь UI кажется плавным.
Ну, это самое главное — восприятие
M>>>>— Рендеринг интерфейса происходит с нормальным приоритетом; C>>>И что? Процессора должно хватать на всё. M>>Агага. Но не хватает. Может поэтому Андроид так активно лезет на двух-нцатиядерные процессоры? C>Дело в том, что если процессор перегружен, то игры с приоритетами могут сделать только хуже.
Ну, андроид тоже вроде приложения в суспенд кладет, так что это не должно быть проблемой. А когда игра на главном фоне — там, вроде уже не должно быть проблем с анимацией и т.п.
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
Полечили заикание методом усечения Манагед такой манагед... Слава нативу!
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
H>Полечили заикание методом усечения Манагед такой манагед... Слава нативу!
Там же написано, что, в частности, это из-за молодости самогго Dalvik'а. Потому что realtime GC для JVM существуют
Здравствуйте, Mamut, Вы писали:
H>>Полечили заикание методом усечения :))) Манагед такой манагед... Слава нативу!
M>Там же написано, что, в частности, это из-за молодости самогго Dalvik'а. Потому что realtime GC для JVM существуют
смеются. не знают еще что им жить совсем немного осталось (с)
Ты этут статью уже который раз пихаешь. Только вот не все так ужасно в реальной жизни с дедлоками на десктопе, чай не серверное приложение с кучей юзверей. Да и методы борьбы есть.
C>Более сложные способы — это изобрести что-то типа WPF с отделением визуальной модели от логической.
Этого не достаточно. Все равно упрешься в отклик прикладного кода. Нужно еще так выкрутить руки разработчикам, чтобы шансов пожрать процессор нечаянно было не очень много.
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Выделение кода UI в отдельный поток — это вообще давняя проблема, которая нормально не решается в общем случае. Классический пост на эту тему: http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html НС>Ты этут статью уже который раз пихаешь.
Ну так она правдой не меньше становится.
НС>Только вот не все так ужасно в реальной жизни с дедлоками на десктопе, чай не серверное приложение с кучей юзверей. Да и методы борьбы есть.
Если бы. Логика блокирования получается ничуть не проще, даже сложнее. На серверах нынче всё просто — запросы друг от друга обычно изолированы так или иначе. А в UI мы работаем с достаточно сложной разделяемой моделью.
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
НС> Только вот WP7 GC почему то не мешает.
Ну как бы вот:
Во-вторых, я на стажировке в команде Windows Phone, начиная с января
и далее
Интересно отметить, что Windows Phone 7 в основной пользовательский интерфейс построен на нативном коде, хотя первоначальный план был — базироваться полностью на Silverlight. В Microsoft в конце концов решили, что для придания интерфейсу необходимой производительности, код должен быть родным.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>> H>
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
НС>> Только вот WP7 GC почему то не мешает.
H>Ну как бы вот: H>
Во-вторых, я на стажировке в команде Windows Phone, начиная с января
H>и далее H>
Интересно отметить, что Windows Phone 7 в основной пользовательский интерфейс построен на нативном коде, хотя первоначальный план был — базироваться полностью на Silverlight. В Microsoft в конце концов решили, что для придания интерфейсу необходимой производительности, код должен быть родным.
В Silvelight анимация аппаратно-ускоренная и работает в отдельном потоке. И, скорее всего, реализована в нативном коде. Если делать анимацию руками, то лагает очень заметно.
Здравствуйте, Cyberax, Вы писали:
C>Ну так она правдой не меньше становится.
Скажем так, это только часть правды.
C>Если бы. Логика блокирования получается ничуть не проще, даже сложнее.
С какой стати? В серверном софте куча параллельных активностей одних и тех же алгоритмов. Т.е. гарантия пересечения по данным близка к 100%. И то дедлоки не так чтобы совсем смертельная штука — пишут ведь серверный софт как то.
А в десктопе активность как правило разнородная, и прогнозированию поддается лучше. Как следствие, избежать неконтроллируемого шаринга данных проще, всевозможные декларативные подходы к распараллеливанию работают лучше.
Здравствуйте, hattab, Вы писали:
H>Ну как бы вот: H>
Во-вторых, я на стажировке в команде Windows Phone, начиная с января
И?
H>и далее H>
Интересно отметить, что Windows Phone 7 в основной пользовательский интерфейс построен на нативном коде, хотя первоначальный план был — базироваться полностью на Silverlight. В Microsoft в конце концов решили, что для придания интерфейсу необходимой производительности, код должен быть родным.
Только вот весь прикладной код, включая UI, там managed. И GC работает в полный рост.
В Андроиде, кстати, отрисовка тоже нативная, если что. Только яйца почему то все равно мешают.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Если бы. Логика блокирования получается ничуть не проще, даже сложнее. НС>С какой стати? В серверном софте куча параллельных активностей одних и тех же алгоритмов. Т.е. гарантия пересечения по данным близка к 100%. И то дедлоки не так чтобы совсем смертельная штука — пишут ведь серверный софт как то.
В некоторых БД дедлоков не бывает в принципе...
В серверных приложениях, тем не менее, многопоточность очень хорошо разграничивается и вся сложность сегрегируется в отдельные модули: базы данных, кэщи и т.п.
НС>А в десктопе активность как правило разнородная, и прогнозированию поддается лучше. Как следствие, избежать неконтроллируемого шаринга данных проще, всевозможные декларативные подходы к распараллеливанию работают лучше.
Сложно. Дерево контролов по своей сути расшарено между ВСЕМИ. Причём нетривиально.
К примеру, я вставляю из одного потока элемент в графический список. Его можно просто перерисовать, да?
А вот фигушки, нельзя. Почему?
Из-за того, что вставка нового элемента привела к увеличению горизонтального размера контрола, что потребовало выполнить пересчёт layout'а для остальных элементов. Что заблокировалось из-за того, что другой поток сейчас занимается мутирование состояния совершенно не относящейся к этому списку таблицы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> H>Ну как бы вот: НС> H>
Во-вторых, я на стажировке в команде Windows Phone, начиная с января
НС> И?
На случай сомнений в осведомленности источника.
НС> H>и далее НС> H>
Интересно отметить, что Windows Phone 7 в основной пользовательский интерфейс построен на нативном коде, хотя первоначальный план был — базироваться полностью на Silverlight. В Microsoft в конце концов решили, что для придания интерфейсу необходимой производительности, код должен быть родным.
НС> Только вот весь прикладной код, включая UI, там managed. И GC работает в полный рост. НС> В Андроиде, кстати, отрисовка тоже нативная, если что. Только яйца почему то все равно мешают.
Здравствуйте, Cyberax, Вы писали:
C>В некоторых БД дедлоков не бывает в принципе...
А во всех остальных — бывают.
C>В серверных приложениях, тем не менее, многопоточность очень хорошо разграничивается и вся сложность сегрегируется в отдельные модули: базы данных, кэщи и т.п.
Хоть обсегрегируйся. Если по задаче нужны расшариваемые данные, то то дедлоки потенциально будут. Есть в коде блокировки (а они в серверном коде есть и в немалых количествах), значит есть и опасность дедлоков.
Под серверным, разумеется, я не веб странички понимаю.
C>И таких неявных связей тонны.
Остальное — по ссылке (перевод там достаточно косноязычен, но читабелен)
Манагед такой манагед... Слава нативу!
