Android, объектно-ориентированное программирование против проектирования для повышения производительности

Question

Я полный нуб на андроид, но я давно программирую на c #.Я пишу приложение для Android и дошел до того, что программист на c # хочет, чтобы я начал создавать слабосвязанный дизайн и перемещал код в разные слои, используя интерфейсы и т. Д.

Но потом я наткнулся на Руководство по проектированию для производительности говорит мне избегать создания объекта , а затем оно также оптимизирует в судебном порядке .

Должен ли я просто строить на основе хорошего дизайна, а затем решать проблемы с производительностью по мере их появления?

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

Спасибо

Answer 1

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

В документе «Проектирование для работы» я бы выделил следующее утверждение:

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

Примером этого может быть создание системы частиц. Хороший способ смоделировать это - иметь объект ParticleSystem, который содержит коллекцию объектов Particle ... может быть, эти Particles реализуют интерфейс Particle ... это не место, чтобы избежать создания объекта. Однако по соображениям производительности вы захотите оптимизировать ParticleSystem для перезапуска объектов Particle, а не создавать их с нуля каждый раз, когда вы создаете один из них.

Лично я не считаю, что производительность является значительным ограничивающим фактором, но я полагаю, что это действительно будет зависеть от того, какой тип приложения вы создаете.

Мое мнение состоит в том, чтобы сначала создать подходящий дизайн, протестировать производительность и оптимизировать его.

Answer 2

Обратите больше внимания на цитату Дональда Кнута, приведенную в той же статье:

«Мы должны забыть о маленьком эффективность, скажем, около 97% время: преждевременная оптимизация корень всего зла. корень всего зла. "

Тогда, если вы имеете дело с другими 3%, вы увидите ...

Answer 3

Как правило, нужно сделать структуру данных максимально простой и нормализованной.Например, не просто добавлять структуры данных хеш-таблиц только потому, что их легко получить.Знать, как выполнять профилирование (, вот мой метод ), и если у вас есть реальная проблема с производительностью, то исправьте ее.Иначе, чем проще, тем лучше, даже если это означает простые массивы, списки и циклы O (N).

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

Другая проблема с ненормализованной структурой данных состоит в том, что она может создавать и уничтожать множество объектов.Это также может привести к снижению производительности, хотя вы можете улучшить его с помощью техники пула.