Стандартный компилятор Java выполняет некоторые оптимизации, но оставляет большинство из них для JIT.
JIT знает, на каком процессоре в точности работает программа, а также имеет доступ к информации времени выполнения, и поэтому он может выполнять больше оптимизаций, чем компилятор Java мог бы сделать заранее. Кроме того, предварительная оптимизация может несколько «запутать» байтовый код, затрудняя его оптимизацию в JIT.
Я не знаю, что делает компилятор Google, когда он переводит ваш байт-код Java в код Dalvik - возможно, он выполняет более обширные оптимизации.
Может быть, этот инструмент будет вам полезен: Оптимизация и проверка Dalvik с помощью dexopt
Кстати, упомянутый вами пример не всегда верен; преобразование a / 4
в a >> 2
не гарантирует, что ваша программа будет работать быстрее на любом процессоре. Однажды я где-то читал статью (извините, не могу найти ее прямо сейчас ...), в которой объясняется, что на современных современных процессорах x86 (я думаю) a >> 2
может быть даже медленнее, чем a / 4
.
В любом случае, не выполняйте преждевременную оптимизацию, такую как ручное преобразование a / 4
в a >> 2
в своем исходном коде, если только у вас нет реальных доказательств (из измерений производительности), что это стоит делать.