Overdraw dans les applications mobiles : ce que c'est, causes et optimisation

Qu'est-ce que l'Overdraw dans les graphiques mobiles ?

Overdraw est une situation où le même pixel d'écran est redessiné plusieurs fois dans une seule image de rendu. Dans un scénario idéal, chaque pixel devrait être écrit exactement une fois, mais dans les interfaces réelles, en raison des vues imbriquées, des images d'arrière-plan et des couches transparentes, le GPU effectue des écritures répétées.

Chaque redessin supplémentaire augmente le temps de rendu de l'image. À un taux standard de 60 FPS, chaque image dispose d'environ 16,6 ms. Si l'overdraw fait dépasser cette limite, la fréquence d'images chute à 30 FPS ou moins, ce qui dégrade sensiblement la fluidité de l'interface.

Selon Android Performance Patterns de Google, une application avec un facteur d'overdraw de 3x passe trois fois plus de temps sur le shader de fragments qu'une application avec un overdraw de 1x. Sur les appareils GPU peu performants, cela entraîne des ralentissements notables lors du défilement et de l'animation.

Pour les développeurs mobiles, comprendre l'overdraw est d'une importance cruciale : ce facteur est la cause la plus fréquente de défilement saccadé et de faibles fréquences d'images sur des écrans apparemment simples avec un grand nombre d'éléments imbriqués.

Comment l'Overdraw affecte les performances du GPU

Le pipeline GPU se compose de plusieurs étapes : shader de sommets, pixellisation et shader de fragments. Le shader de fragments est la partie la plus coûteuse car il s'exécute pour chaque pixel de chaque primitive. Avec un overdraw 2x, le shader de fragments traite deux fois plus de pixels, ce qui augmente directement le temps d'image.

Les GPU mobiles modernes tels que Qualcomm Adreno et Apple GPU disposent de mécanismes de test Early-Z et de suppression de surface cachée qui compensent partiellement l'overdraw. Cependant, ces optimisations ne fonctionnent que dans certaines conditions et il ne faut pas se fier uniquement à l'accélération matérielle.

Par exemple, lors du rendu d'éléments semi-transparents, l'Early-Z matériel est inefficace et chaque pixel est traité complètement — l'overdraw dans de tels scénarios peut atteindre 5x ou plus.

Principales causes du redessin excessif

Les arrière-plans multicouches sont l'une des principales causes d'overdraw dans les applications mobiles. Lorsqu'une Activity ou un ViewController définit une couleur d'arrière-plan, chaque vue imbriquée peut ajouter son propre arrière-plan, et le pixel est redessiné à chaque niveau de la hiérarchie.

Une étude d'Uber Engineering a montré que la suppression des arrière-plans excessifs dans leur application Android réduisait l'overdraw de 32% et le temps de rendu de l'écran de 25%. Une situation similaire existe sous iOS : définir opaque = true pour les vues non transparentes élimine le mélange alpha et évite les écritures multiples de pixels.

• Superpositions transparentes — les éléments avec canal alpha au-dessus d'autres éléments provoquent toujours de l'overdraw.
• ClipChildren=false — la désactivation du découpage des éléments enfants entraîne le rendu de zones invisibles.
• Utiliser ShapeDrawable au lieu de couleurs simples augmente la charge sur le shader de fragments.
• Imbrication excessive — chaque niveau de hiérarchie de vue ajoute une couche potentielle de redessin.

Sur la plateforme iOS, l'overdraw se produit souvent en raison de l'utilisation de UIStackView transparents, de CALayer avec shouldRasterize et de UIBlurEffect superposés. Apple recommande de vérifier l'overdraw via l'outil Core Animation dans XCode — il montre les zones de redessin sous forme de superposition rouge.

Comment diagnostiquer l'Overdraw : outils et méthodes

Debug GPU Overdraw est un outil intégré d'Android qui colore l'écran de différentes couleurs selon le facteur d'overdraw. Le violet signifie 1x, le bleu — 2x, le vert — 3x, le rose — 4x, le rouge — 5x ou plus. Un écran idéal devrait être majoritairement violet.

Sous iOS, un diagnostic similaire est effectué par l'outil Core Animation dans XCode Instruments. Il visualise les zones de redessin et montre le nombre exact d'écritures de pixels en mode Color Blended Layers. Les couches vertes sont opaques (optimales), les rouges contiennent de la transparence et provoquent de l'overdraw.

• Profile GPU Rendering sous Android montre un histogramme du temps de rendu. Les barres vertes hautes indiquent des problèmes d'overdraw.
• Renderscript est un outil plus avancé pour analyser le pipeline de rendu sur les appareils Android 10+.
• Metal Debugger dans XCode permet d'analyser chaque passe de rendu et de voir le nombre exact d'appels au shader de fragments.

Après le diagnostic, il est important de mesurer les FPS avant et après l'optimisation. Une différence de 10–15 FPS lors de la correction de l'overdraw est un résultat normal pour un écran complexe avec des listes et des animations.

Techniques d'optimisation de l'Overdraw dans les applications mobiles

Supprimer les arrière-plans excessifs est la méthode la plus simple et la plus efficace. Sous Android, définissez android:windowBackground uniquement pour l'Activity ou le thème, pas pour chaque vue. Sous iOS, opaque = true pour tous les UIView non transparents réduit l'overdraw à presque zéro pour ces éléments.

Selon Google I/O 2019, l'optimisation de l'overdraw dans Google Maps a permis de réduire le temps de rendu d'image de 40% grâce à la fusion de calques et à l'utilisation de ClipRect pour limiter la zone de dessin. Pour les développeurs Android, Google recommande les pratiques suivantes :

• ClipRect — limite la zone de dessin du Canvas. S'il n'y a rien en dehors de la zone visible, le GPU ne gaspille pas de ressources.
• ViewStub — pour les éléments rarement utilisés ou invisibles au chargement initial. Le composant ne rend que lorsque inflate est appelé.
• merge et include — réduisent la profondeur de la hiérarchie des vues, ce qui diminue le nombre de passes de rendu.
• Tampons plats — remplacer les mises en page imbriquées par un seul ConstraintLayout ou RelativeLayout.

Sous iOS, l'optimisation est obtenue via la configuration de CALayer : définir masksToBounds = true coupe le contenu au-delà des limites de la couche, et shouldRasterize active la mise en cache du bitmap pour les couches statiques.

Exemples de code : élimination de l'Overdraw sous Android et iOS

Voyons des exemples pratiques en Kotlin et Swift illustrant des scénarios typiques d'élimination de l'overdraw. Le premier exemple montre l'optimisation via ClipRect sous Android :

class OptimizedView@JvmOverloads constructor(
    context: Context, attrs: AttributeSet? = null
) : View(context, attrs) {

    override fun onDraw(canvas: Canvas) {
        canvas.clipRect(
            paddingLeft.toFloat(), paddingTop.toFloat(),
            width - paddingRight.toFloat(), height - paddingBottom.toFloat()
        )
        // Draw content only within clipped area
        super.onDraw(canvas)
    }
}

Le deuxième exemple en Swift montre comment désactiver la transparence d'un calque si l'élément ne doit pas être semi-transparent :

class OpaqueLabel: UILabel {
    override var isOpaque: Bool {
        get { true }
        set { }
    }

    override func draw(_ rect: CGRect) {
        backgroundColor?.setFill()
        UIRectFill(rect)
        super.draw(rect)
    }
}

Le troisième exemple montre l'utilisation de ViewStub pour le chargement différé d'une carte sous Android. ViewStub ne rend pas jusqu'à ce qu'il devienne visible, ce qui élimine l'overdraw au stade de l'initialisation de l'écran :

<!-- layout/activity_main.xml -->
<ViewStub
    android:id="@+id/map_stub"
    android:layout_width="match_parent"
    android:layout_height="200dp"
    android:inflatedId="@+id/map_container"
    android:layout="@layout/map_fragment" />

// Inflate on demand
ViewStub stub = findViewById(R.id.map_stub)
stub?.inflate()