W przypadku wydarzeń z Androidem, dlaczego instrukcje przełączników są częstsze niż w przypadku łańcuchów -inus?

Question

Podczas opracowywania systemu Android jest bardziej efektywny niż w łańcuchu if-else? Instrukcja switch pobiera więcej linii kodu, ale przeglądanie anegdotycznych danych wydaje się być częściej używane w aplikacjach systemu Android.

Poniższe przykłady ilustrują tę samą konstrukcję programistyczną z instrukcją case i łańcuchem if-else. Instrukcja switch wymaga 10 linii, podczas gdy łańcuch if-else wymaga 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 łańcuch

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(); 
} 

Dlaczego przełączyć być bardziej powszechne niż łańcuch if-else? Czy instrukcje przełączające oferują lepszą wydajność w porównaniu do łańcuchów if-else?

Answer 1

Powodem, dla którego języki mają instrukcje switch, jest umożliwienie kompilatorowi wygenerowania tabeli skoku, która jest szybka, jeśli jest duża, ponieważ w czasie wykonywania może uzyskać żądany kod w O (1) zamiast O (N) czas.

Pomocna jest tylko prędkość, jeśli istnieje wiele przypadków, a kod do wykonania w każdym przypadku nie zajmuje dużo czasu, a program poświęca w tym kodzie dużo czasu.

Poza tym jest to wyłącznie kwestia gustu.

Brak zależności między liczbą linii kodu i prędkością. Liczy się rodzaj generowanego kodu języka asemblerowego, do którego zachęcam do zapoznania się.

Answer 2

O ile wasza sekwencja przypadków/przypadków nie jest naprawdę rozległa, nie sądzę, by miało to znaczenie. Dzięki instrukcji switch jest bardziej jasne, co się dzieje. Jedynym minusem są wszystkie instrukcje break i możliwość ich pominięcia, ale statyczny analizator powinien to wykryć.

Najlepiej byłoby mapę wprowadzonego przez id lub jakiegoś sprytnego wykorzystania podklasy

Answer 3

Pytałeś: Czy oświadczenie przełącznik naprawdę bardziej wydajny?

Ktoś, kto twierdzi, że ma ostateczną i ogólną odpowiedź na to pytanie, mówi nonsens. Jest dokładnie jeden sposób, aby dowiedzieć się, który z nich jest szybszy w twoim przypadku: użyj odpowiedniego mikrokanczytowego standardu na docelowej platformie z pełnym oprogramowaniem, a nie uproszczonym przykładem. Jeśli to ujawni mierzalną i statystycznie istotną różnicę, byłbym zainteresowany usłyszeniem o tym. Wątpię, żebyś znalazł jakąkolwiek mierzalną różnicę dla prawdziwego programu.

W związku z tym ściśle przestrzegałbym czytelności.

Answer 4

"Bardziej efektywne" jest pojęciem niejasnym, ponieważ istnieje wiele sposobów jego pomiaru. Przypuszczam, że większość ludzi myśli o czasie wykonania. Z drugiej strony większość ludzi nie myśli o wydajności pamięci. Instrukcja switch z szeroko rozstawionymi wartościami testowymi może być okropnym trybem pamięci, chyba że kompilator jest wystarczająco inteligentny, aby ponownie zinterpretować go jako łańcuch if-else.

Można również wiele powiedzieć na temat wydajności programowania, w tym konserwacji i czytelności. Jak zauważyli sblundy, instrukcja switch może bardziej wyjaśniać intencje programisty niż łańcuch if-else. Komentarze mogą to zrównoważyć, ale to wymaga więcej pracy dla programisty i istnieje również ryzyko, że komentarze i kod nie pasują do siebie (szczególnie po kilku cyklach konserwacji).

Wyobrażam sobie, że większość ludzi podąża za stylem, którego nauczono (lub kazano im podążać), nie myśląc o tym za dużo. Resztę czasu, myślę, że większość decyzji dotyczących zmiany w stosunku do if-else opiera się na tym, który najlepiej pasuje do myślenia programisty w momencie generowania kodu.

Answer 5

Skoro już jesteśmy w tej sprawie, nikt nie wspomniał, że należy zawsze mieć linię w instrukcji switch default. Zwykle chcesz rzucić wyjątek, ale przynajmniej powinieneś potwierdzić i/lub zarejestrować błąd.

To tylko dobre podstawowe programowanie defensywne. Ostrzeże Cię, że masz błąd w programowaniu, jeśli później dodasz inny przycisk (w tym przypadku).