Влияет ли Log.i () на производительность приложений Android?

Я старый школьный разработчик (хорошо, мне 20, я не старая школа, мне просто нужно распечатать его, а не использовать пошаговый отладчик: P), и у меня много Log.i () В приложении Android. Мне было интересно, повлияет ли это на производительность приложения?

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

Спасибо за вашу помощь!

Я не думаю, что журнал повлияет на производительность приложения, потому что при выпуске приложения вы отключите его в Android Manifest, установив debuggable :

 <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="false"> 

Я все еще смотрю на Android-кодирование, но я из того, что я видел до сих пор, я бы предположил, что ведение журнала Android страдает от тех же проблем, с которыми страдают большинство механизмов регистрации Java (примечательным исключением является SLF4J), а именно:

  • Ведение журнала влияет на производительность, потому что:
    1. Это означает вызовы дополнительных методов. (Не проблема для 99% приложений).
    2. Это часто означает, что строковая сборка (большое воздействие)
    3. Он задействует дополнительный IO (большой удар)

Разработчики обычно справляются с этим, добавляя блоки защиты

 if (log.isDebugEnabled()) { log.debug("..."); } 

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

SFL4J BTW, не требует защитных блоков, потому что он использовал вызовы типа C, которые задерживают сборку String до тех пор, пока она не понадобится. К сожалению, похоже, что Android не пошел по этому пути. У iOS нет этой проблемы либо потому, что у нее есть предварительный компилятор. Что-то, что я часто желаю, чтобы Java хранилось.

Во всяком случае, я бы не стал отстаивать удаление журнала в пользу отладчика. ИМХО они используют две разные цели. Ведение журнала Я считаю очень полезным (если все сделано правильно) в понимании потока приложения. Я часто обнаружил проблемы, просматривая журналы, которые я бы не нашел в отладчике. То есть. Ненужное выполнение кода для нескольких классов (особенно в классах пользовательского интерфейса), нечетные проблемы с данными, которые не приводят к ошибкам на самом деле и т. Д. В этих ситуациях использование отладчика будет напоминать попытку заложить бетон ложкой. Отладчики, с другой стороны, идеально подходят для анализа тонких деталей проблемы, выделенной журналом.

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

UPDATE: просто прочитайте Удалить все сообщения об ошибках отладки перед публикацией: есть ли инструменты для этого? В котором рассказывается о том, как вы можете использовать ProGuard для записи журнала из кода выпуска. Отличная идея, означает, что вы не можете беспокоиться о блокирах блокировки при входе в систему и ставить столько, сколько хотите, но все равно будьте уверены, что ваш код выпуска будет быстрым.

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

Да, у него есть штраф за производительность. Проверьте это: Log.d и влияние на производительность

Ответ и да и нет.

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

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

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