Overdraw sa mga mobile app: ano ito, mga sanhi at pag-optimize

Ano ang Overdraw sa mobile graphics?

Overdraw — ay ang sitwasyon kung saan ang parehong pixel ng screen ay nire-redraw nang maraming beses sa loob ng isang rendering frame. Sa ideal na scenario, ang bawat pixel ay dapat na isulat nang eksaktong isang beses, ngunit sa totoong mga interface dahil sa nested Views, background na mga imahe at transparent na layer, ang GPU ay nagsasagawa ng paulit-ulit na pagsulat.

Ang bawat karagdagang pag-redraw ay nagpapataas ng oras ng rendering ng frame. Sa standard na frequency na 60 FPS, humigit-kumulang 16.6 ms ang inilalaan para sa pagproseso ng isang frame. Kung ang overdraw ay nagdudulot ng paglampas sa limitasyong ito, ang frame rate ay bumababa sa 30 FPS o mas mababa, na kapansin-pansing nagpapalala sa kinis ng interface.

Ayon sa Android Performance Patterns mula sa Google, ang isang app na may overdraw coefficient na 3x ay gumugugol ng tatlong beses na mas maraming oras sa fragment shader kaysa sa isang app na may overdraw 1x. Sa mga device na may mababang pagganap ng GPU, ito ay humahantong sa kapansin-pansing lag sa pag-scroll at animation.

Para sa mga mobile developer, ang pag-unawa sa overdraw ay napakahalaga: ito mismo ang factor na kadalasang nagdudulot ng maalog na pag-scroll at mababang frame rate sa tila simpleng mga screen na may maraming nested na elemento.

Paano nakakaapekto ang Overdraw sa pagganap ng GPU

Ang GPU pipeline ay binubuo ng ilang yugto: vertex shader, rasterization at fragment shader. Fragment shader — ang pinakamahal na bahagi, dahil ito ay isinasagawa para sa bawat pixel ng bawat primitive. Sa overdraw x2, ang fragment shader ay nagpoproseso ng dalawang beses na mas maraming pixel, na direktang nagpapataas ng oras ng frame.

Ang mga modernong mobile GPU tulad ng Qualcomm Adreno at Apple GPU ay may mga mekanismong Early-Z Test at Hidden Surface Removal na bahagyang nagko-compensate ng overdraw. Gayunpaman, ang mga optimization na ito ay gumagana lamang sa ilalim ng ilang mga kundisyon at hindi dapat umasa lamang sa hardware acceleration.

Halimbawa, sa pag-render ng semi-transparent na mga elemento, ang hardware Early-Z ay hindi epektibo at ang bawat pixel ay ganap na pinoproseso — ang overdraw sa ganitong mga scenario ay maaaring umabot ng 5x at higit pa.

Mga pangunahing sanhi ng labis na pag-redraw

Multi-layer na background — isa sa mga pangunahing sanhi ng overdraw sa mga mobile app. Kapag ang Activity o ViewController ay nagtatakda ng kulay ng background, ang bawat nested View ay maaaring magdagdag ng sarili nitong background, at ang pixel ay nire-redraw sa bawat antas ng hierarchy.

Ang pananaliksik ng Uber Engineering ay nagpakita na ang pag-alis ng mga labis na background sa kanilang Android app ay nagbawas ng overdraw ng 32%, at ang oras ng rendering ng screen — ng 25%. Katulad na sitwasyon sa iOS: ang pagtatakda ng opaque = true para sa opaque na Views ay nag-aalis ng alpha blending at pumipigil sa maramihang pagsulat ng mga pixel.

• Transparent na overlay — ang mga elemento na may alpha channel sa ibabaw ng iba pang elemento ay palaging nagdudulot ng overdraw.
• ClipChildren=false — ang pag-disable ng pag-clip ng child elements ay humahantong sa pag-render ng hindi nakikitang mga lugar.
• Paggamit ng ShapeDrawable sa halip na simpleng kulay ay nagpapataas ng karga ng fragment shader.
• Labis na nesting — bawat antas ng View hierarchy ay nagdaragdag ng potensyal na layer ng pag-redraw.

Sa platform na iOS, ang overdraw ay madalas na lumilitaw dahil sa paggamit ng transparent na UIStackView, CALayer na may shouldRasterize at magkakapatong na UIBlurEffect. Inirerekomenda ng Apple na suriin ang overdraw sa pamamagitan ng Core Animation tool sa XCode — ipinapakita nito ang mga zone ng pag-redraw bilang isang pulang overlay.

Paano i-diagnose ang Overdraw: mga tool at paraan

Debug GPU Overdraw — ang built-in na tool ng Android na nagkukulay ng screen sa iba't ibang kulay depende sa multiplicity ng overdraw. Ang kulay purple ay nangangahulugang 1x, asul — 2x, berde — 3x, pink — 4x, pula — 5x at higit pa. Ang ideal na screen ay dapat na nakararami purple.

Sa iOS, ang katulad na diagnosis ay ginagawa ng Core Animation tool sa XCode Instruments. Ito ay nagvi-visualize ng mga zone ng pag-redraw at nagpapakita ng eksaktong bilang ng mga pagsulat bawat pixel sa Color Blended Layers mode. Ang mga berdeng layer — opaque (optimal), pula — naglalaman ng transparency at nagdudulot ng overdraw.

• Profile GPU Rendering sa Android ay nagpapakita ng histogram ng oras ng rendering. Ang matataas na berdeng bar ay nagpapahiwatig ng mga problema sa overdraw.
• Renderscript — isang mas advanced na tool para sa pagsusuri ng rendering pipeline sa mga device na may Android 10+.
• Metal Debugger sa XCode ay nagbibigay-daan sa pagsusuri ng bawat rendering pass at pagtingin sa eksaktong bilang ng mga tawag sa fragment shader.

Pagkatapos ng diagnosis, mahalagang sukatin ang FPS bago at pagkatapos ng optimization. Ang pagkakaiba ng 10–15 FPS sa pag-aayos ng overdraw ay normal na resulta para sa isang kumplikadong screen na may mga listahan at animation.

Mga teknik sa pag-optimize ng Overdraw sa mga mobile app

Pag-alis ng labis na background — ang pinakasimple at pinakaepektibong paraan. Sa Android, sapat na itakda ang android:windowBackground para lamang sa Activity o tema, hindi para sa bawat View. Sa iOS, ang opaque = true para sa lahat ng opaque na UIView ay nagbabawas ng overdraw halos sa zero para sa mga elementong ito.

Ayon sa Google I/O 2019, ang pag-optimize ng overdraw sa Google Maps ay nagpababa ng oras ng rendering ng frame ng 40% sa pamamagitan ng pagsasama ng mga layer at paggamit ng ClipRect upang limitahan ang lugar ng pag-draw. Inirerekomenda ng Google ang mga sumusunod na praktika para sa mga Android developer:

• ClipRect — nililimitahan ang lugar ng pag-draw ng Canvas. Kung walang anuman sa labas ng nakikitang lugar — hindi gumagamit ng resources ang GPU.
• ViewStub — para sa mga elementong bihirang gamitin o hindi nakikita sa pag-load. Ang component ay nire-render lamang kapag tinawag ang inflate.
• merge at include — nagbabawas ng lalim ng View hierarchy, na nagpapababa ng bilang ng rendering passes.
• Flat buffers — pagpapalit ng nested Layouts ng isang ConstraintLayout o RelativeLayout.

Sa iOS, ang optimization ay nakakamit sa pamamagitan ng configuration ng CALayer: ang pagtatakda ng masksToBounds = true ay pumuputol ng nilalaman sa labas ng mga hangganan ng layer, at ang shouldRasterize ay nag-a-activate ng caching ng raster representation para sa static na mga layer.

Mga halimbawa ng code: pag-alis ng Overdraw sa Android at iOS

Tingnan natin ang mga praktikal na halimbawa sa Kotlin at Swift na nagpapakita ng tipikal na mga scenario ng pag-alis ng overdraw. Ang unang halimbawa ay nagpapakita ng optimization sa pamamagitan ng ClipRect sa 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()
        )
        // Gumuhit ng nilalaman lamang sa loob ng na-clip na lugar
        super.onDraw(canvas)
    }
}

Ang pangalawang halimbawa — sa Swift, nagpapakita ng pag-disable ng transparency para sa layer kung ang elemento ay hindi dapat semi-transparent:

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

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

Ang pangatlong halimbawa — paggamit ng ViewStub para sa naantalang pag-load ng mapa sa Android. Ang ViewStub ay hindi nire-render hanggang sa ito ay maging nakikita, na nag-aalis ng overdraw sa yugto ng pagsisimula ng screen:

<!-- 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" />

// Palawakin kapag kinakailangan
ViewStub stub = findViewById(R.id.map_stub)
stub?.inflate()