1) Перед тем, как начать проект, определите, сколько памяти вы используете, предпочтительно для каждого компонента. Таким образом, каждый раз, когда вы вносите изменения, вы можете видеть их влияние на использование памяти. Вы не можете оптимизировать то, что не можете измерить.
2) Если проект уже завершен и достигает пределов памяти (или перенесен на устройство с меньшим объемом памяти), выясните, для чего вы уже используете память.
Мой опыт показывает, что почти все существенные оптимизации при исправлении приложения большого размера происходят из-за небольшого количества изменений: уменьшение размеров кэша, удаление некоторых текстур (конечно, это функциональное изменение, требующее соглашения с заинтересованными сторонами, то есть собраний). (поэтому может оказаться неэффективным с точки зрения вашего времени), повторно сэмплируйте звук, уменьшите предварительный размер выделенных пользователем куч, найдите способы освободить ресурсы, которые используются только временно, и перезагрузите их при необходимости снова. Иногда вы можете найти структуру размером 64 байта, которая может быть уменьшена до 16, или что-то в этом роде, но это редко самый низко висящий фрукт. Однако, если вы знаете, какие самые большие списки и массивы в приложении, тогда вы знаете, какие структуры следует искать вначале.
О да: найдите и исправьте утечки памяти. Любое воспоминание, которое вы можете восстановить, не жертвуя производительностью, является отличным началом.
В прошлом я потратил лот времени, беспокоясь о размере кода. Основные соображения (кроме: убедитесь, что вы измерили его во время сборки, чтобы вы могли видеть его изменение):
1) Узнайте, на какой код ссылаются и на что. Если вы обнаружите, что вся библиотека XML связана с вашим приложением просто для анализа двухэлементного файла конфигурации, рассмотрите возможность изменения формата файла конфигурации и / или написания своего собственного тривиального анализатора. Если вы можете, используйте исходный или бинарный анализ, чтобы нарисовать большой граф зависимостей, и ищите большие компоненты только с небольшим числом пользователей: может быть возможно вычеркнуть их только с незначительными переписываниями кода. Будьте готовы играть дипломатом: если два разных компонента в вашем приложении используют XML, и вы хотите сократить его, то вам нужно убедить двух людей в преимуществах ручного запуска чего-то, что в настоящее время является надежной готовой библиотекой. .
2) Возиться с опциями компилятора. Обратитесь к документации для вашей платформы. Например, вы можете уменьшить допустимое увеличение размера кода по умолчанию из-за встраивания, и, по крайней мере, в GCC вы можете указать компилятору только применять оптимизацию, которая обычно не увеличивает размер кода.
3) По возможности используйте библиотеки уже на целевой платформе (ах), даже если это означает написание слоя адаптера. В приведенном выше примере XML вы можете обнаружить, что на вашей целевой платформе в любом случае всегда есть в памяти библиотека XML, потому что ОС использует ее, и в этом случае ссылка на нее динамическая.
4) Как уже упоминалось, режим большого пальца может помочь в ARM. Если вы используете его только для кода, который не критичен по производительности, и оставляете критические подпрограммы в ARM, то вы не заметите разницу.
Наконец, могут быть хитрые трюки, которые вы можете играть, если у вас есть достаточный контроль над устройством. Пользовательский интерфейс позволяет запускать одновременно только одно приложение? Выгрузите все драйверы и сервисы, которые не нужны вашему приложению. Экран с двойной буферизацией, но ваше приложение синхронизировано с циклом обновления? Вы можете восстановить весь экранный буфер.