Как стать автором
Обновить

Комментарии 15

А разве proguard не делает тоже самое?
Даже если он делает всё вышеперечисленное, использовать локальные переменные вместо полей — хорошая практика (если что, в поиске таких мест может помочь IDEA).
Опять же помечать поля как final, если они неизменяемые, тоже хорошая идея. Например, у меня в IDEA по умолчанию и в результате Bind constructor arguments to fields, и в Extract variable, и наверняка где-то ещё, стоит галочка «Make final». Теоретически и компилятор Java, и виртуальные машины, и мало ли кто ещё — могут оптимизировать такие вещи. Но зачем надеяться на них, если сама среда разработки может делать код таким :). Каши не просит, времени не отнимает.
Не везде это может оказаться полезным, как минимум в методе onDraw так делать не нужно.
Не совсем понял, где может не оказаться полезным, когда программист метит неизменяемые поля как final?
Или то, что сообщает, что метод не может быть переопределён в наследнике и надо вызывать именно метод из класса A?
Я не программист на Android, но насколько я понимаю, onDraw — это метод, который выполняется ну просто очень-очень-очень много раз, нет? Соответственно, все эти вещи наоборот, должны помочь ускорить выполнение, но не замедлить его.

Правда,
class A {
  final int v = 42;
}

думаю, было бы лучше поменять на
class A {
  public static final int V = 42;
}

Ибо кто его знает, сколько экземпляров класса A создадут.
Я писал в контексте
использовать локальные переменные вместо полей
Метод onDraw вызывается каждый кадр, потому будет нагрузка на GC.
Понятно, спасибо. Да, так понятно. Мы в своё время на Java архиватор портировали с C и наступали на эти грабли.
А причём тут GC? Локальные-то переменные отношения к GC не имеют.
Извините, но кто же так abs находит:
public static final int abs(int a) {
    int b;
    if (a < 0) 
      b = a;
    else
      b = -a;
    return b;
}

Зачем лишнюю переменную создавать? Почему бы не так:
public static final int abs(int a) {
    return a < 0 ? -a : a;
}
Потому автор и написал, что не нужно изобретать велосипед, а использовать по возможности стандартные возможности.
как у вас получилось улучшить код тернарным оператором, но не заметить ошибку в логике? хотя в своем примере, вы этой ошбики не допустили :)
В том-то и суть. Рад, что еще кто-то заметил.
Под android, к сожалению, нет такой мощного инструмента для написания тестов на производительность как есть для hotspot — JMH openjdk.java.net/projects/code-tools/jmh
Интересная подача диаграмм!!! Один раз красный столбик это хорошо, другой раз красный столбик плохо… Путаница какая-то.
Красный столбик везде обозначает Android 5, какие проблемы?
скиншот с пустой неэффективной областью на 80% не очень уместен в статье про оптимизацию
Зарегистрируйтесь на Хабре, чтобы оставить комментарий