deks
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору sergionn Ну - его впречателния частично повторяют мои. Он тоже отметил, что старт приложения довольно долгий. Также заметные лаги в интерфейсе - это тоже ожидаемая фигня, так как нативный интерфейс iOS сильно оптимизирован, а FMX - нет. Нужно отметить, что 1,5Ghz мобильный ARM-процессор и даже Intel Atom - это сильно разные по производительности устройства. Так что, то что хоть как то канает на десктопах, совсем малоюзабельное на ARM. Наких оптимизаций нехватает FMX. Рассмотрим на примере собственных оптимизаций iOS. Во-первых, однажды прорисованный обьект живет в видеопамяти в виде bmp, что позволяет не обращаться к медленному Objective-C runtme (он там сильно динамический, поэтому несмотря на нативную компиляцию, не самый быстрый). А вот bmp живут прямо в ядре операционки, поэтому выводятся довольно быстро, спасибо железячной поддержке OpenGL с первых версий iOS. FMX стоит тоже кэшировать обьекты, Bitmap styles - шаг в нужном направлении, но нужно идти быстрее. при этом, стоит следить за потреблением памяти - и оперативно убивать ненужные bitmaps. Во-вторых, нужно оптимизировать создание объектов итерфейса. например, в iOS очень распространен объект список. На его основе сделаны все менюшки, гриды (списки), и даже просмотр фоток. Но у этого объекта довольно хитрое управление памятью. Для каждого видимого элемента списка да, создается объект. Но всего в списке определенное количество обьектов (сколько видно на экране + небольшой запас), которые собраны в пул. Если обьект уходит из зоны видимости, он не уничтожается, а заполняется новыми данными для элемента, который может быть отображен в ближайшее время. Так iOS экономит на отработке конструкторов/менеджеров памяти и деструкторах. В третьих, все анимации - они hardware accelerated и выполняются не над объектами, а над bitmap, через OpenGL. Ну и я не вижу смысла все это повторять в коде FMX. Почему бы не взять нативные контролья, которые уже очень оптимизированы и тп, и не делать бы форму из них. Край, можно их стилизовать (a la Pixate). А в дизайнере дельфи показывать те самые эмулированные контролья! Такого дизайнера ни у кого не будет)) А приложение будет шустрым. Ну и последнее. Не думаю, что быдет много iOS контрольев под Delphi. А вот нативных iOS контрольев - куча, причем большинство free/open source. Зацените на cocoacontrols. Ну и на github зацентие сколько objective-c кода. Дык - почему бы не сделать таки нативный interop с ObjC кодом и классам, и не заюзать эти все контролья? Oxygene же может? Да и в XE4 есть тот же LLVM... Не понимаю.. П.С. Зацените, сколько open-source контрольев используют топовые приложения - _https://www.cocoacontrols.com/apps Что, ЭМРО хочет быть умнее всех?) | Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 10:32 27-04-2013 | Исправлено: deks, 10:37 27-04-2013 |
|