Porównuję niektóre z naszych kodów na urządzeniu OPO, które zwykle są dość szybkie i widzę wiele dziwnych dziwactw wydajności. Zanim zagłębiłem się w natywny kod Androida, pomyślałem, że zapytam tutaj.Dlaczego setColor jest tak wolny na Androidzie
Co ja widzę, że wezwanie do paint.setColor(argbInt) trwa około 5 razy dłużej niż wykonanie następujących połączeń:
paint.setStyle(Paint.Style.FILL);
paint.setAntiAlias(false);
canvas.drawRect(x, y, x + w, y + h, paint);
paint.setAntiAlias(antialias);
Teraz wyciągnąć rect dzieje się na GPU więc zgaduję, że nie zobacz jakikolwiek narzut na to. Ale dlaczego miałabym dostać się do koloru farby?
A jak naturalna kontynuacja, w jaki sposób zmniejszyć wspomniane obciążenie?
Widzę również sporo napięć dla canvas.restore() (około 4 razy wolniej niż powyższy kod), ale wydaje mi się, że to ma sens, ponieważ może to być skomplikowana operacja. Po prostu nie rozumiem, dlaczego setColor byłby powolny?
Dla celów testu testowałem wydajność OPO z System.nanoTime() i było to całkiem spójne pod względem wydajności (nie nagła fluktuacja GC czy coś takiego).
Domyślam się, że setColor wyzwala pewne zdarzenia, które wymagają czasu. Jeśli w twojej farbie i/lub jej podskładnikach znajduje się dowolna niestandardowa grafika, wtedy wyświetlacz powinien zostać ponownie obliczony. Powtarzam: domyślam się, ponieważ nie jestem programistą Androida :) –
Czy próbowałeś stworzyć instancję koloru, by ją zastosować? –
"bo prawdopodobnie w setColor procesor pętli nad wszystkimi pikselami farby, podczas gdy inne ustawia pewną zmienną, a GPU wykonuje resztę ciężkiej pracy – Gavriel