Здравствуйте, Mamut, Вы писали:
M>Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале: M>— Рендеринг интерфейса происходит на главном потоке приложения;
Неверно. Автор — мудаг, креатив — отстой.
Автора уже поправили, что в iOS рисование точно так же происходит в основном потоке. В специальном потоке рисуются только стандартные анимации и выполняется композиция.
Ровно как и в Андроиде — финальной композицией окон занимается системный процесс. Проблема в том, что стандартные анимации в Андроиде хотя и ускорены аппаратно и их рисованием занимается отдельный процесс, они управляются из основного потока. Так что если цикл событий не справляется, то получаются задержки.
M>— Рендеринг интерфейса происходит с нормальным приоритетом;
И что? Процессора должно хватать на всё.
Android UI никогда не будет совершенно плавным из-за конструктивных ограничений, которые мы обсуждали в самом начале:
— Рендеринг интерфейса происходит на главном потоке приложения;
— Рендеринг интерфейса происходит с нормальным приоритетом;
Даже с Galaxy Nexus, или четырехъядерным процессором EeePad Transformer Prime, нет никакого способа, чтобы гарантировать гладкость и приемлемую частоту кадров, если эти два конструктивных ограничения остаются в силе. Это говорит, что мощности Galaxy Nexus хватит чтобы сравнится по плавности работы с первым iPhone трехлетней давности.
Остальное — по ссылке (перевод там достаточно косноязычен, но читабелен)
Здравствуйте, Mamut, Вы писали:
C>>Ровно как и в Андроиде — финальной композицией окон занимается системный процесс. Проблема в том, что стандартные анимации в Андроиде хотя и ускорены аппаратно и их рисованием занимается отдельный процесс, они управляются из основного потока. Так что если цикл событий не справляется, то получаются задержки. M>Это интересно. Просто как по мне, так интерфейс андроида реально не такой плавный (а на Wildifre еще и лагает).
Я не замечаю особой лаговатости в самом UI. Проблема именно в анимациях — на iOS они "зачитены" так, что всегда плавные, даже если само приложение тормозит. А так как ощущения — это всё, то и весь UI кажется плавным.
Следующий вопрос — как всё-таки сделать интерфейс более отзывчивым. Самый простой и тупой способ — взять побольше процессора и не мучаться. Более сложные способы — это изобрести что-то типа WPF с отделением визуальной модели от логической. А потом рендерить визуальную модель независимо от логической.
M>>>— Рендеринг интерфейса происходит с нормальным приоритетом; C>>И что? Процессора должно хватать на всё. M>Агага. Но не хватает. Может поэтому Андроид так активно лезет на двух-нцатиядерные процессоры?
Дело в том, что если процессор перегружен, то игры с приоритетами могут сделать только хуже.
Во-вторых, вопреки тому что я утверждал ранее, сбор мусора по-прежнему проблема, даже при работе по совместительству с GC в Dalvik. Например, если вы когда-либо использовали приложение фотогалерея в Honeycomb или ICS вы можете удивиться, почему частота кадров такая низкая. Оказывается, частота кадров ограничена числом 30 кадров в секунду, а прокрутка фотографий возможна и при 60 FPS в большинстве случаев, но иногда паузы сборщика мусора приводят к заметному «заиканию». Ограничение частоты кадров до 30 исправляет «заикание» и обеспечивает плавную анимацию все время.
Здравствуйте, hattab, Вы писали:
H>Ты ссылку на мсдн-блог читал? Там весьма доходчиво говорится о паузах из-за GC. К чему ты тут упомянул WPF мне не понятно
Есть в моем посте такое предложение, так и начинается "к чему я это". Поясню еще разок. То, что некоторые, как на Хабре, сразу начинают обвинять во всех бедах GC, не означает, что это действительно так. Это такой совет. Managed — не натив, в нем без серьезного опыта и профайлера далеко не всегда можно делать верные предположения.
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 это титаник с пробитым бортом фигли тут спорить
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 с отделением визуальной модели от логической.
Этого не достаточно. Все равно упрешься в отклик прикладного кода. Нужно еще так выкрутить руки разработчикам, чтобы шансов пожрать процессор нечаянно было не очень много.
Здравствуйте, Ночной Смотрящий, Вы писали:
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>И таких неявных связей тонны.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС> НС>> H>Ну как бы вот: НС> НС>> H>
Во-вторых, я на стажировке в команде Windows Phone, начиная с января
НС> H>На случай сомнений в осведомленности источника.
НС> Осведомленности в чем? То что он там где то стажировался еще не значит, что он понимает что пишет.
В том, что у сервелата бэкенд нативный.
НС> H>Судя по этому, яйца мешают не только андроиду.
НС> Там нет ничего про дерганье анимации. Там только про то, что genGC быстрее.
Не тормози. Это было ответом на слова:
Только вот весь прикладной код, включая UI, там managed. И GC работает в полный рост.
и там, в частности, говорится о:
Existing apps and games even without any changes can expect faster startup, faster level loads and reduction in gameplay stutters due to collection.
ну и предложение попрыгать вокруг GC:
Developers can specifically optimize for the new generational GC to completely remove stutters during animations and game play that came due to these GC pauses.
, что приложение WPF медленно стартует из-за сборщика мусора. Как видишь, профайлер показал ничтожную роль GC во всем этом буйстве Managed-кода. Я к чему: то, что кто-то считает, что тормоза из-за сборщика, далеко не всегда означает, что они (тормоза) действительно из-за него.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>В серверных приложениях, тем не менее, многопоточность очень хорошо разграничивается и вся сложность сегрегируется в отдельные модули: базы данных, кэщи и т.п. НС>Хоть обсегрегируйся. Если по задаче нужны расшариваемые данные, то то дедлоки потенциально будут. Есть в коде блокировки (а они в серверном коде есть и в немалых количествах), значит есть и опасность дедлоков.
Видимо, это тлетворное влияние MSSQL такое. Не помню, чтобы у меня когда-то вообще были проблемы с дедлоками.
C>>И таких неявных связей тонны. НС>В любом параллельном коде таких связей тонны.
Ты пишешь говнопараллельный код, значит.
, что приложение WPF медленно стартует из-за сборщика мусора. Как видишь, профайлер показал ничтожную роль GC во всем этом буйстве Managed-кода. Я к чему: то, что кто-то считает, что тормоза из-за сборщика, далеко не всегда означает, что они (тормоза) действительно из-за него.
Ты ссылку на мсдн-блог читал? Там весьма доходчиво говорится о паузах из-за GC. К чему ты тут упомянул WPF мне не понятно
Здравствуйте, MxMsk, Вы писали:
MM> H>Ты ссылку на мсдн-блог читал? Там весьма доходчиво говорится о паузах из-за GC. К чему ты тут упомянул WPF мне не понятно
MM> Есть в моем посте такое предложение, так и начинается "к чему я это". Поясню еще разок. То, что некоторые, как на Хабре, сразу начинают обвинять во всех бедах GC, не означает, что это действительно так. Это такой совет. Managed — не натив, в нем без серьезного опыта и профайлера далеко не всегда можно делать верные предположения.
I am a developer in the .NET Compact Framework (NETCF) team and work on the execution engine. NETCF is the core runtime behind Windows Phone 7 series, XNA (on Xbox360), Silverlight for Nokia S60 and other Windows CE powered devices.
Ну да, откуда бы ему знать о действительном положении дел с GC Может и мне чего-нибудь тебе посоветовать...
Здравствуйте, hattab, Вы писали:
H>Ну да, откуда бы ему знать о действительном положении дел с GC Может и мне чего-нибудь тебе посоветовать...
Ты прав. Извини, что потратил твое время. Впредь я этого делать не буду.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Видимо, это тлетворное влияние MSSQL такое. НС>При чем тут MSSQL?
Раз про дедлоки говоришь.
C>> Не помню, чтобы у меня когда-то вообще были проблемы с дедлоками. НС>У меня тоже не было. А на десктопе были?
Были, когда интегрировал HTMLayout и SWING — у них две независимые очереди событий.
НС>>>В любом параллельном коде таких связей тонны. C>>Ты пишешь говнопараллельный код, значит. НС>У меня проблем нет, это у тебя проблемы на десктопе. Значит говнокод пишешь ты.
А так же авторы GUI-библиотек. И таки да — он очень непараллельный и непонятно как его нормально сделать таким.
В моём примере — как ты будешь делать так, чтобы код работал нормально без дедлоков?
Здравствуйте, Cyberax, Вы писали:
C>>>Видимо, это тлетворное влияние MSSQL такое. НС>>При чем тут MSSQL? C>Раз про дедлоки говоришь.
Странная логика.
НС>>У меня проблем нет, это у тебя проблемы на десктопе. Значит говнокод пишешь ты. C>А так же авторы GUI-библиотек. И таки да — он очень непараллельный и непонятно как его нормально сделать таким. C>В моём примере — как ты будешь делать так, чтобы код работал нормально без дедлоков?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>У меня проблем нет, это у тебя проблемы на десктопе. Значит говнокод пишешь ты. C>>А так же авторы GUI-библиотек. И таки да — он очень непараллельный и непонятно как его нормально сделать таким. C>>В моём примере — как ты будешь делать так, чтобы код работал нормально без дедлоков? НС>В твоем — без понятия.
Ну вот и все того же мнения.
Пока что многопоточность в GUI используется в очень ограниченных контекстах. В принципе, выполнение заранее подготовленной анимации, которая гарантировано не требует повторного рендеринга или каких-то других взаимодействий с основным потоком — это хороший пример. Но очень ограниченный.
Здравствуйте, Cyberax, Вы писали:
C>Пока что многопоточность в GUI используется в очень ограниченных контекстах.
Ну это у кого как. У меня в одном из проектов, к примеру, применяется очень активно. И ни одного дедлока, что характерно, за много лет и кучи кода, написанного не самыми квалифицированными прикладниками. Зато проблем с однопоточностью гуйных библиотек — хватает.
C> В принципе, выполнение заранее подготовленной анимации, которая гарантировано не требует повторного рендеринга или каких-то других взаимодействий с основным потоком — это хороший пример.
Анимация меня не особо волнует, мне куда больше интересна интеграция всяческих долгоиграющих процессов с UI без танцев с бубном вокруг однопоточного гуя.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>> В принципе, выполнение заранее подготовленной анимации, которая гарантировано не требует повторного рендеринга или каких-то других взаимодействий с основным потоком — это хороший пример. НС>Анимация меня не особо волнует, мне куда больше интересна интеграция всяческих долгоиграющих процессов с UI без танцев с бубном вокруг однопоточного гуя.
Так какие проблемы? Это задача решена сто лет назад уже. Просто постим в очередь GUI сообщений замыкания, обновляющие состояние GUI.
Здравствуйте, Cyberax, Вы писали:
НС>>Анимация меня не особо волнует, мне куда больше интересна интеграция всяческих долгоиграющих процессов с UI без танцев с бубном вокруг однопоточного гуя. C>Так какие проблемы?
С синхронизацией проблемы.
C> Это задача решена сто лет назад уже.
Хорошо эта задача пока не решена. С релизом C#5 кое какие подвижки планируются, будем посмотреть. А пока куча дурного рукопашного кода.
C> Просто постим в очередь GUI сообщений замыкания, обновляющие состояние GUI.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>> Это задача решена сто лет назад уже. НС>Хорошо эта задача пока не решена. С релизом C#5 кое какие подвижки планируются, будем посмотреть. А пока куча дурного рукопашного кода.
Я в SWING уже сто лет делаю так:
SwingUtilities.invokeLater(new Runnable()
{
public void run()
{
updateUIProgress();
}
})
В остальных GUI-фреймворках абсолютно аналогично.
C>> Просто постим в очередь GUI сообщений замыкания, обновляющие состояние GUI. НС>Ага, и засираем этими постингами кучу кода.
С лямбдами? Оверхед в полстрочки.
Здравствуйте, Mamut, Вы писали:
M>Блин, я же знад, что тормоза, которые я ощущаю в Андроиде, не являются воображаемыми:
M>http://habrahabr.ru/blogs/android_development/134172/
M>Android UI никогда не будет совершенно плавным из-за...
Купил тут себе HTC Desire S. Никаких тормозов. Все гладко, красиво и быстро.
Как мне воспроизвести тормоза на моем Desire S? Или услышать от тебя хотя бы раз в жизни фразу "Я был неправ."?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
M>>http://habrahabr.ru/blogs/android_development/134172/ M>>Android UI никогда не будет совершенно плавным из-за... VD>Купил тут себе HTC Desire S. Никаких тормозов. Все гладко, красиво и быстро.
Не такая хорошая плавность по сравнению с iPhone'ом всё-таки заметна, если положить их рядом и нагрузить Android хорошей такой фоновой службой, жрущей процессор.
Здравствуйте, Cyberax, Вы писали:
C>Не такая хорошая плавность по сравнению с iPhone'ом всё-таки заметна, если положить их рядом и нагрузить Android хорошей такой фоновой службой, жрущей процессор.
Меня то не надо уговаривать. У меня телефон в руках. А жрущие процессор службы мне как-то не нужны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Не такая хорошая плавность по сравнению с iPhone'ом всё-таки заметна, если положить их рядом и нагрузить Android хорошей такой фоновой службой, жрущей процессор. VD>Меня то не надо уговаривать. У меня телефон в руках. А жрущие процессор службы мне как-то не нужны.
У меня Galaxy S уже полтора года
M>>Блин, я же знад, что тормоза, которые я ощущаю в Андроиде, не являются воображаемыми:
M>>http://habrahabr.ru/blogs/android_development/134172/
M>>Android UI никогда не будет совершенно плавным из-за...
VD>Купил тут себе HTC Desire S. Никаких тормозов. Все гладко, красиво и быстро.
VD>Как мне воспроизвести тормоза на моем Desire S? Или услышать от тебя хотя бы раз в жизни фразу "Я был неправ."?
Desire S — это из топовых? Ну, у топовых особо проблем не было заметно (по форуму можно ьпоискать, где я хорошо отзываюсь о топовых HTC). Хотя, как заметил Киберакс, в сравнении даже топовые HTC не настолько плавные.
Здравствуйте, Mamut, Вы писали:
M>Desire S — это из топовых? Ну, у топовых особо проблем не было заметно (по форуму можно ьпоискать, где я хорошо отзываюсь о топовых HTC).
Ну, так и говорите о том, что ловэнд с хреновым железом тормозит.
Desire S к топовым вряд ли можно отнести. Цена ~15 000 руб. Это в два раза дешевле похожего по характеристикам Айфона (в Москве).
M>Хотя, как заметил Киберакс, в сравнении даже топовые HTC не настолько плавные.
Не несколько, а практически точно так же как Айфоны. При этом стоят они в двое дешевле.
Короче, хотелось бы услышать признание своей не правоты Кибераксом. Случай ведь более чем очевидный. В Интернете точа авишников на которых сравнивают Айфон 4 и Desire S. Во всех случаях сравнение всегда в пользу последнего. Даже самые фанатичные яблофилы сходятся на том, что Desire S как минимум не медленее Айфона.
ЗЫ
Мне в общем-то плевать на все эти телефоны. Мне больше интересно именно поглядеть как вы тут будете выкручиваться. Вопрос то очевиден. Киберакс просто гонит. Но я уверен, что он никогда не признает своей не правоты явно. Будет юлить, искать обтекаемые формулировки и т.п. Но не скажет, что был не прав.
Вот то прикольно. А телефоны... это дело десятое. Для меня железки никогда не были объектом поклонения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
С ума сойти, просто рокет сайнс. Ты действительно думаешь, что я не в курсе такой тривиальщины? Control.Invoke был в самой первой версии фреймворка. Во 2 версии МС уже догадался, что вообще то код, выполняющий синхронизации, привязывать к кокнретному UI фреймворку скверно и придумал AsyncOperationManager (до 95% программистов это, правда, не дошло, но это уже другой вопрос). Но это, опять же, детский лепет. С усложнением структуры синхронизации сложность этой фигни растет. А усложнение будет обязательно, если ты не единичные моменты кусочно паравллелишь, а обеспечиваешь тотальное вынесение целого слоя в параллельные потоки.
C>>> Просто постим в очередь GUI сообщений замыкания, обновляющие состояние GUI. НС>>Ага, и засираем этими постингами кучу кода. C>С лямбдами?
С лямбдами.
C> Оверхед в полстрочки.
Это если у тебя 1 синхронизация.
C>В общем, придумываете что-то не то.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>С ума сойти, просто рокет сайнс. Ты действительно думаешь, что я не в курсе такой тривиальщины?
Кто тебя знает.
НС>Control.Invoke был в самой первой версии фреймворка. Во 2 версии МС уже догадался, что вообще то код, выполняющий синхронизации, привязывать к кокнретному UI фреймворку скверно и придумал AsyncOperationManager (до 95% программистов это, правда, не дошло, но это уже другой вопрос). Но это, опять же, детский лепет. С усложнением структуры синхронизации сложность этой фигни растет. А усложнение будет обязательно, если ты не единичные моменты кусочно паравллелишь, а обеспечиваешь тотальное вынесение целого слоя в параллельные потоки.
Усложняете. GUI принципиально однопоточен, так что просто готовите нужные стрктуры и отсылаете в основной поток на отрисовку. Прекрасно работает даже для сложнейших приложений.
Основная фича — не заниматься рассчётами в самом GUI-потоке
Здравствуйте, Cyberax, Вы писали:
НС>>С ума сойти, просто рокет сайнс. Ты действительно думаешь, что я не в курсе такой тривиальщины? C>Кто тебя знает.
Остальное — по ссылке (перевод там достаточно косноязычен, но читабелен)
Манагед такой манагед... Слава нативу!
