2015-05-05 3 views
3

Я рекомендую эту книгу: Начало разработки игр для Android 4 от Mario Zechner и Robert Green для начинающих в андроид-игр.Дизайн ООП и производительность на смартфонах

В книге говорится на странице 192:

Method calls have a larger associated cost in Dalvik than in other VMs. Use static methods if you can, as those perform best. Static methods are generally regarded as evil, much like static variables, as they promote bad design, so try to keep your design as clean as possible. Perhaps you should avoid getters and setters as well. Direct field access is about three times faster than method invocations without the JIT, and about seven times faster with the JIT. Nevertheless, think of your design before removing all your getters and setters.

Теперь это имеет огромное влияние в настоящее время? Что действительно лучше всего между производительностью и дизайном? Потому что если im будет иметь статические переменные и методы, он будет находиться в ОЗУ до тех пор, пока приложение не завершится, это будет плохо, если мое приложение слишком велико, и Android 2.3 станет частью рынка.

+1

Есть много вещей, которые идут вразрез с хорошими методами ООП, чтобы оптимизировать производительность, но лично я бы использовал их только в качестве последнего средства. Есть много других вещей, которые вы можете оптимизировать, прежде чем достичь этого этапа. И если вам нужно, речь идет о том, сколько вы хотите торговать качеством кода для производительности. – hidro

+0

Геттеры и сеттеры также подверглись критике за некоторые аспекты. Вы можете заменить их полями 'final', также для отображения O/R. Для остальных: оптимизируйте в конце, что 1%, что очень медленно. –

ответ

2

Производительность - отличный фактор, который следует учитывать при разработке на устройствах с поддержкой Android, поскольку нам также необходимо учитывать устройства с низкой конфигурацией.

Что касается использования статических переменных и методов, то это полностью зависит от того, на какие конкретные устройства, на которые нацелено приложение.

Вы абсолютно правы - статические переменные и методы, будут находиться в оперативной памяти, пока приложение не завершит, но вы видите, это еще не проблема, если ваш Android устройство с питанием с 1+ Гб оперативной памяти, и поверьте мне, если вы ориентированы на 2.3, приложение будет иметь много ANR, так как память, требуемая переменными объектами, будет недоступна.

Лучший выстрел для вас, чтобы сосредоточиться на:

  • Модульная конструкция , предпочтительно MVC с singelton или фабричной модели.
  • Используйте правильную оптимизацию высокого уровня (по коду или с помощью сторонних библиотек, например: используйте джексон для синтаксического анализа вместо традиционного способа или используйте Volley для сетевых подключений).
  • Выполняйте правильное профилирование с использованием таких инструментов, как MAT, DDM.
  • освобождения память, когда интерфейс становится скрыт

Сообщение развития: Проверьте, сколько памяти приложение использует Каждый Android-устройство имеет различное количество оперативной памяти, доступной в систему и, таким образом, обеспечивает различный предел динамической памяти для каждое приложение.

Вы можете вызвать getMemoryClass(), чтобы получить доступную кучу приложения в мегабайтах.

+0

+1 для чего я должен больше сосредоточиться. Хорошая идея указать мне на MVC с одноэлементным или заводским шаблоном. я никогда не думал об одноэлементных и заводских шаблонах. таким образом я могу свести к минимуму использование памяти. Благодарю. – mubuss

4

Что разработчики часто забывают, когда делают микро -optimizations является оптимизация должна быть сделана , не нарушая дизайн. Независимо от того, должно ли поле быть статическим или нестатичным, чисто выбор дизайна. Точно также, имеет ли смысл иметь геттеры и сеттеры, зависит также от того, хотите ли вы сделать поле частным или общественностью.

Итак, как только вы полный вашей фазы проектирования и прийти к стадии реализации, а затем посмотреть на оптимизаций как с помощью StringBuilder над строкой # CONCAT. При входе в фазу реализации, вы бы уже определились, есть ли поле быть личное, имеет ли это быть статическим и т.д.

Теперь, к технической части - на самом деле вызовы статических методов всегда обеспечивают привязку времени компиляции. Поэтому звонки на них дешевле.

Обычно прямой доступ к полям выполняется быстрее, чем при использовании геттера/сеттера (JIT может встроить геттеры/сеттеры, но он по-прежнему дорог, чем прямой доступ).

Итак, книга верна о производительности. Но вы не должны компрометировать дизайн, чтобы повысить производительность..

+1

Теперь это хороший ответ. большой СПАСИБО. – mubuss

Смежные вопросы