Differenza tra SurfaceView e View?


211

Quando è necessario, o meglio usare un SurfaceViewinvece di un View?

Risposte:


210

Le viste sono tutte disegnate sullo stesso thread della GUI che viene utilizzato anche per tutte le interazioni dell'utente.

Pertanto, se è necessario aggiornare la GUI rapidamente o se il rendering richiede troppo tempo e influisce sull'esperienza utente, utilizzare SurfaceView.


2
Controlla la risposta di Pierr che contiene maggiori dettagli.
Helin Wang,


Non è più così semplice. Controlla la risposta di Pierr; ha un collegamento al documento dettagliato sull'architettura ( source.android.com/devices/graphics/architecture.html ) e spiega perché l'accelerazione hardware del rendering su Canvas può rendere le viste personalizzate una scelta migliore.
fadden,

1
Quando utilizzare FrameLayout per impilare le viste anziché SurfaceView?
IgorGanapolsky,

103

Alcune cose che ho notato:

  • SurfaceViews contiene un meccanismo di rendering che consente ai thread di aggiornare il contenuto della superficie senza utilizzare un gestore (ottimo per l'animazione).
  • Le SurfView non possono essere trasparenti, possono apparire solo dietro altri elementi nella gerarchia delle visualizzazioni.
  • Ho scoperto che sono molto più veloci per l'animazione rispetto al rendering in una vista.

Per ulteriori informazioni (e un ottimo esempio di utilizzo) consultare il progetto LunarLander nella sezione degli esempi dell'SDK.


36
Cordiali saluti ... A SurfaceView ora può essere trasparente: stackoverflow.com/questions/5391089/…
Steve

@Ralphleon: cosa intendi con Surface Views non può essere trasparente? Le altre viste possono sovrapporsi alla vista Surface? Ad esempio, posso visualizzare temporaneamente un ListView su una vista Surface?
Ashwin,

78

aggiornato il 05/09/2014

OK. Abbiamo un documento ufficiale ora. Ha parlato di tutto ciò che ho menzionato, in un modo migliore.


Leggi più dettagliati qui .

Sì, la differenza principale è che SurfaceView può essere aggiornato sul thread in background. Tuttavia, ci sono molte altre che potrebbero interessarti.

  • surfaceView ha un buffer di superficie dedicato mentre tutta la vista condivide un buffer di superficie allocato da ViewRoot. In altre parole, surfaceView costa più risorse.

  • surfaceView non può essere accelerato dall'hardware (a partire da JB4.2) mentre le operazioni del 95% nella visualizzazione normale sono accelerate HW usando openGL ES.

  • Dovresti fare più lavoro per creare il tuo SurfaceView personalizzato. Devi ascoltare l'evento surfaceCreated / Destroy, creare un thread di rendering e, soprattutto, sincronizzare il thread di rendering e il thread principale. Tuttavia, per personalizzare la vista, tutto ciò che devi fare è sostituire il onDrawmetodo.

  • I tempi per l'aggiornamento sono diversi. Il normale meccanismo di aggiornamento della vista è vincolato o controllato dal framework: si chiama view.invalidatenel thread dell'interfaccia utente o view.postInvalidin un altro thread per indicare al framework che la vista deve essere aggiornata. Tuttavia, la vista non verrà aggiornata immediatamente ma attendere fino all'arrivo del prossimo evento VSYNC. L'approccio semplice per comprendere VSYNC è considerare che è come un timer che si accende ogni 16 ms per uno schermo a 60 fps. In Android, tutto il normale aggiornamento della vista (e visualizzato effettivamente ma non lo parlerò oggi), è sincronizzato con VSYNC per ottenere una migliore scorrevolezza. Ora, tornando a SurfaceView, puoi renderizzarlo quando vuoi. Tuttavia, non riesco a capire se sia un vantaggio, poiché il display è anche sincronizzato con VSYNC, come affermato in precedenza.

2
Dalla tua risposta ho la sensazione che sia meglio usare una classe derivata da View piuttosto che SurfaceView. O sto sbagliando qualcosa? Ciò sarebbe contrario alla maggior parte dei tutorial di sviluppo di giochi 2D.
Tempesta

2
@Storm qualcosa da prendere in considerazione è che un SurfaceView di progettazione non dovrebbe bloccare il thread dell'interfaccia utente in cui una vista può essere modificata solo dal thread dell'interfaccia utente. Con la maggior parte dei giochi, SurfaceViews eseguirà un buon rendering che bloccherebbe il thread dell'interfaccia utente con una vista semplice. Questo è il vantaggio principale, dal mio punto di vista, di un SurfaceView.
zgc7009,

Cosa intendi per creare un thread di rendering . Dobbiamo crearlo manualmente ogni volta?
IgorGanapolsky,

44

La differenza principale è che SurfaceViewpossono essere disegnati dai thead di sfondo ma Viewsnon possono. SurfaceViewsusa più risorse, quindi non vuoi usarle a meno che non sia necessario.


"Usano più risorse, quindi non vuoi usarle a meno che tu non debba." - Chi utilizza più risorse? Visualizzazioni o SurfaceViews?
Dror,

6
Surfaceview utilizza più risorse che visualizzazioni
Ritesh Gune,

1
@RiteshGune quanto?
Alex Sifuentes,

Quando ci dobbiamo ?
IgorGanapolsky,

12

A SurfaceViewè una vista personalizzata in Android che può essere utilizzata per disegnare al suo interno.

La differenza principale tra a Viewe a SurfaceViewè che viene disegnata una vista in UI Thread, che viene utilizzata per tutte le interazioni dell'utente.

Se desideri aggiornare l'interfaccia utente abbastanza rapidamente e visualizzare una buona quantità di informazioni al suo interno, SurfaceView è la scelta migliore.

Ma ci sono alcuni aspetti tecnici di SurfaceView:

1. Non sono accelerati dall'hardware.

2. Le viste normali vengono visualizzate quando si chiamano i metodi invalidateo postInvalidate(), ma ciò non significa che la vista verrà immediatamente aggiornata ( VSYNCverrà inviato A e il sistema operativo deciderà quando verrà aggiornato. Il SurfaceViewpuò essere immediatamente aggiornato.

3. Un SurfaceView ha un allocato surface buffer, quindi è più costoso


Perché è importante accelerare l'hardware ?
IgorGanapolsky,

8

Una delle principali differenze tra surfaceview e view è che per aggiornare lo schermo per una visualizzazione normale dobbiamo chiamare il metodo invalidato dallo stesso thread in cui è definita la vista. Ma anche se chiamiamo invalidato, l'aggiornamento non avviene immediatamente. Si verifica solo dopo il prossimo arrivo del segnale VSYNC. Il segnale VSYNC è un segnale generato dal kernel che si verifica ogni 16,6 ms o questo è anche noto come 60 frame al secondo. Quindi, se vogliamo un maggiore controllo sull'aggiornamento dello schermo (ad esempio per l'animazione in movimento molto veloce), non dovremmo usare la normale classe di visualizzazione.

D'altra parte, nel caso di Surfaceview, possiamo aggiornare lo schermo il più velocemente possibile e possiamo farlo da un thread in background. Quindi l'aggiornamento del Surfaceview in realtà non dipende da VSYNC, e questo è molto utile se vogliamo fare un'animazione ad alta velocità. Ho alcuni video di formazione e applicazioni di esempio che spiegano bene tutte queste cose. Dai un'occhiata ai seguenti video di formazione.

https://youtu.be/kRqsoApOr9U

https://youtu.be/Ji84HJ85FIQ

https://youtu.be/U8igPoyrUf8


0

Perché usare SurfaceView e non la classica classe View ...

Uno dei motivi principali è che SurfaceView può eseguire rapidamente il rendering dello schermo.

In parole semplici, un SV è più in grado di gestire i tempi e il rendering delle animazioni.

Per comprendere meglio cos'è un SurfaceView dobbiamo confrontarlo con la classe View.

Qual è la differenza ... controlla questa semplice spiegazione nel video

https://m.youtube.com/watch?feature=youtu.be&v=eltlqsHSG30

Bene con il View abbiamo un grosso problema .... i tempi di rendering delle animazioni.

Normalmente onDraw () viene chiamato dal sistema runtime di Android.

Quindi, quando il sistema runtime di Android chiama onDraw (), l'applicazione non può controllare

i tempi di visualizzazione, e questo è importante per l'animazione. Abbiamo un intervallo di tempo

tra l'applicazione (il nostro gioco) e il sistema di runtime Android.

L'SV può chiamare onDraw () da un thread dedicato.

Pertanto: l'applicazione controlla i tempi. Quindi possiamo visualizzare l'immagine bitmap successiva dell'animazione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.