Inizializzazione pigra rispetto alla preelaborazione nell'app iOS basata su immagini

Question

Inizializzazione pigra rispetto alla preelaborazione nell'app iOS basata su immagini

#1 da (0 voti)

0

Sto creando un'app per iOS che contiene la galleria del museo: l'utente può consultare le esposizioni e quindi selezionare le informazioni su di esso, ecc Nella schermata mostra ho due ScrollView che sono diverse, ma sono alimentate da una comune fonte di dati. Ogni vista è un insieme di immagini. Due quadrati grigi in alto sono le anteprime e quella in basso (dove puoi vedere l'immagine) è la vista principale. Tutte le immagini a scorrimento sono pigre.
La domanda è: devo trasformare le immagini di anteprima in dimensioni adeguate in movimento, o in qualche modo pre-elaborarle per velocizzare il caricamento e utilizzare le immagini pre-elaborate e ridimensionate nelle anteprime? Il vantaggio dell'inizializzazione pigra qui è un minore spreco di risorse, ma un caricamento più lento rispetto alle immagini pronte. D'altra parte, le immagini pre-elaborate sprecheranno la memoria e la rete (le immagini verranno caricate una sola volta e quindi verranno archiviate localmente). Cosa sarebbe meglio dal punto di vista delle prestazioni, tenendo conto del fatto che l'app deve scorrere uniformemente verso iPhone 4 (la più vecchia con iOS 7)? È una buona idea combinare due metodi e memorizzare nella cache immagini pigre?

iphone ios data lazy-initialization image-manipulation

posta Richard Topchiy 08.08.2014 - 06:07

fonte

1 risposta

Leggi altre domande sui tag iphone ios data lazy-initialization image-manipulation

incorporamento LEFT OUTER JOIN in INNER JOIN Confuso sull'implementazione del modello di modulo javascript

score 0 · Accepted Answer

Sono sicuro che tu abbia familiarità con questa idea, ma mentre stavo leggendo la tua domanda, questa citazione di Donald Knuth Mi è venuto in mente:

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Questo potrebbe essere un caso che rientra nel 3% critico menzionato, ma probabilmente dovresti provare il più semplice degli approcci che hai menzionato e assicurarti. Quindi, se puoi misurare un problema, puoi ottimizzarlo.