Для событий Android почему операторы switch более распространены, чем цепочки if-else? - PullRequest
Новая
       23

Для событий Android почему операторы switch более распространены, чем цепочки if-else?

6 голосов
/ 21 января 2011

При разработке для Android оператор переключения более эффективен, чем цепочка if-else?Оператор switch занимает больше строк кода, но, похоже, что в приложениях Android чаще всего используются отдельные примеры.

Приведенные ниже примеры иллюстрируют ту же программную конструкцию с оператором case и цепочкой if-else.Оператору switch требуется 10 строк, в то время как цепочке if-else требуется 7.

Оператору case 

public void onClickWithSwitch(View v) {
   switch(v.getId()) {
       case R.id.buttonA:
           buttonA();
           break;
       case R.id.buttonB:
           buttonB();
           break;
       case R.id.buttonC:
           buttonC();
   }
}

Цепочка If-else 

public void onClickWithIf(View v) {
   int id = v.getId();
   if(id == R.id.buttonA)
       buttonA();
   else if (id == R.id.buttonB)
       buttonB();
   else if (id == R.id.buttonC)
       buttonC();
}

Почему переключение встречается чаще, чем цепочка if-else?Действительно ли операторы переключения обеспечивают лучшую производительность по сравнению с цепями if-else?

Ответы [ 5 ]

9 голосов
/ 21 января 2011

Причина, по которой языки имеют операторы switch, заключается в том, что компилятор может генерировать таблицу переходов, которая является быстрой, если она большая, поскольку во время выполнения он может получить нужный код в O (1), а не в O (N) время.

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

Кроме того, это просто вопрос вкуса.

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

5 голосов
/ 21 января 2011

Если ваша последовательность случаев / случаев действительно обширна, я не думаю, что это имеет значение. С оператором switch становится понятнее, что происходит. Единственный недостаток - все операторы break и возможность их пропустить, но статический анализатор должен это уловить.

Лучше всего будет карта с идентификатором или какое-то умное использование подклассов

3 голосов
/ 21 января 2011

«Более эффективный» - это расплывчатое понятие, потому что существует множество способов его измерить. Я полагаю, что большинство людей думают о времени выполнения. С другой стороны, большинство людей не думают об эффективности памяти. Оператор switch с широко расположенными тестовыми значениями может быть ужасным бременем памяти, если компилятор не достаточно умен, чтобы интерпретировать его как цепочку if-else.

Многое можно сказать и об эффективности программирования, включая поддержку и удобочитаемость. Как отметил sblundy, оператор switch может быть более понятным о намерениях программиста, чем цепочка if-else. Комментарии могут уравновесить это, но это требует больше работы для программиста, а также существует риск того, что комментарии и код не будут совпадать (особенно после нескольких циклов обслуживания).

Я полагаю, что большинство людей следуют тому стилю, которому их учили (или говорят следовать), не слишком задумываясь об этом. В остальное время, я думаю, большинство решений о переключении по сравнению с if-else основаны на том, какой из них лучше всего соответствует мышлению программиста в момент генерации кода.

2 голосов
/ 21 января 2011

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

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

2 голосов
/ 21 января 2011

Вы спросили: действительно ли оператор switch более эффективен?

Любой, утверждающий, что имеет окончательный и общий ответ на этот вопрос, говорит глупости.Существует только один способ выяснить, что быстрее в вашем случае: используйте подходящую платформу микропроцессорного тестирования на вашей целевой платформе с полным программным обеспечением, а не в упрощенном примере.Если это покажет ощутимую и статистически значимую разницу, мне было бы интересно услышать об этом.Я сомневаюсь, что вы найдете какую-то ощутимую разницу для настоящей программы.

Поэтому я бы строго пошел на удобочитаемость.

...