Оптимизация Java android. Нестатический или статический метод?

Question

У меня есть статический класс с методом в нем, который я запускаю несколько сотен раз. В настоящее время каждый раз, когда выполняется этот метод, он создает два разных объекта стека. Если бы я должен был сделать этот класс нестационарным, чтобы я мог создать два стека при построении, а затем повторно использовать их, очистив их, было бы быстрее? Я полагаю, что ответ зависит от создания нового объекта стека и очистки существующего (что, скорее всего, пустого), и если коэффициент усиления производительности (если он есть) от его очистки больше, чем потеря производительности при использовании нестатического метода.

Я пробовал профилировать два, и он никогда не работает, но это другой вопрос.

Answer 1

Это зависит от того, как вы используете статические переменные и методы в своем коде.

Переменные экземпляра и объекты хранятся в куче. Локальные переменные хранятся в стеке.

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

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

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

Вы можете анализировать использование памяти объектами с помощью инструмента MAT Analyzer. В приведенном ниже видео рассказывается об управлении памятью и о том, как обнаружить и устранить утечки памяти.

http://www.youtube.com/watch?v=_CruQY55HOk.

MemoryInfo mi = new MemoryInfo();// current memory usage 
    ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE); 
    activityManager.getMemoryInfo(mi); 
    long availableMegs = mi.availMem/1048576L; 

http://developer.android.com/training/articles/perf-tips.html. Взгляните на эту ссылку для советов по производительности, особенно в разделе ниже Предпочитайте статический виртуальный.

Доступность памяти является одним из критериев, которые следует учитывать при использовании статических переменных и методов для повышения производительности и предотвращения утечек памяти.

Answer 2

Это действительно вопрос о попытке повторного использования объектов. Вы можете повторно использовать объекты в методе static, если вы объявите член static. Отдельно: да, возможно, лучше спроектировать это без static ничего.

В любом случае, для повторного использования рекомендуется избегать создания объекта. Вы по-прежнему платите некоторую стоимость «очистки» состояния объекта. Или же вы рискуете утечками памяти в случае чего-то вроде Stack.

Существует текущая проблема обслуживания: вы добавляете новое состояние к объекту и не помните, чтобы обновить метод, который очищает его?

Вам также необходимо обратиться к этому методу synchronize или иным образом предотвратить одновременное использование двух потоков. Это может стать узким местом, так как потоки не могут выполнять метод одновременно.

Вы также всегда оплачиваете стоимость памяти этого объекта, проживающего в памяти на протяжении всего времени работы.

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

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