Tre approcci per ottenere versioni di dimensioni diverse di un'immagine dal server

Naviga le tue risposte
0

La mia app per Android ha bisogno di versioni di immagini di dimensioni diverse per scopi diversi e per la conservazione della larghezza di banda.

Approccio 1:

  • quando l'utente carica il proprio avatar o un'altra immagine, il mio script php crea 4 versioni di quell'immagine: mini_200, medium_300, big_400 e originale. questi percorsi vengono quindi acquisiti e archiviati nel database. Quindi, quando ho bisogno dell'immagine più piccola, la carica da http://myserver.com/item_images/200_mini_27304lkewsjfimage.jpg

Approccio 2:

  • come approccio a uno, ma invece di aggiungere prefissi ai nomi dei file, li memorizzo in cartelle diverse - grandi, medie, mini. e nella mia app ho appena passato un parametro per la cartella in cui cercare

Approccio tre:

  • quando l'utente carica il proprio avatar o un'altra immagine, memorizzo solo l'originale. Quindi, quando ho bisogno dell'immagine più piccola, la carica in questo modo: http://myserver.com/image_resizer.php?image="93_iosdfj0sd9fj.jpg"&new_width=200&new_height=200

Quale è meglio e perché? Ho voglia di reinventare la ruota qui, perché questo argomento è troppo ampio e non so dove leggerlo a riguardo

    
posta J. K. 10.02.2014 - 20:28
fonte

3 risposte

4

Le tue prime due opzioni sono simili. Nella tua seconda soluzione, poiché potresti avere due file con lo stesso nome in cartelle diverse, ti consiglio di utilizzare la dimensione come suffisso nel nome del file come images/mini/user_image_1482823_mini.jpg , images/large/user_image_1482823_large.jpg .

Il tuo terzo approccio ha un vantaggio in quanto utilizza meno spazio su disco rispetto agli altri due e non ha bisogno di gestire set di file e varianti per tutte le immagini, ma deve ridimensionare le immagini al volo. Questo ha il potenziale di causare problemi di prestazioni se le immagini di origine sono molto grandi e ci sono molte richieste in arrivo per molte immagini diverse di dimensioni diverse. È possibile gestirlo memorizzando nella cache le immagini richieste più frequentemente in diverse dimensioni. Ciò potrebbe aggiungere un po 'di complessità all'architettura generale del sistema, ma potrebbe essere un'ottima soluzione se implementata correttamente.

Dal momento che tutta questa attività si sarebbe verificata sul lato server, non riduco l'impatto sulla tua app troppo. La tua app invierà sempre un'immagine e riceverà un'immagine. Giusto?

    
risposta data 10.02.2014 - 20:37
fonte
3

Non vuoi memorizzare immagini statiche all'interno di una query GET (ad esempio un URL con un "?"), poiché la maggior parte delle cache HTTP non manterrà i risultati.

Un miglioramento dell'opzione 3 sarebbe utilizzare il routing personalizzato in modo che un percorso come "/images/large/foo.gif" venga interpretato sul server come qualcosa di simile a "/resize_image?size=large&name=foo.gif "(vedi il tuo linguaggio di programmazione specifico, il framework della libreria e il server web per i dettagli).

Un altro vantaggio di questo meccanismo è che ora utilizzi una normale struttura di percorsi che è facilmente condivisa tra le opzioni 2 e 3: l'unica differenza è la configurazione lato server. Ciò ti dà la possibilità di scambiare spazio di archiviazione e tempo della CPU per ottenere il miglior bilanciamento possibile per la tua applicazione.

    
risposta data 10.02.2014 - 20:54
fonte
1

Sembra che la terza opzione sia la più semplice e richieda il minimo spazio di archiviazione, ma è potenzialmente anche la più lenta poiché il server finirà per generare più e più volte gli stessi file. Inizia con quel metodo, ma preparati a passare alla prima o alla seconda opzione se e quando trovi che il server diventa tassato.

    
risposta data 10.02.2014 - 20:37
fonte

Leggi altre domande sui tag

E 'necessario memorizzare ogni riga di codice quando si tratta di sviluppo del gioco? [chiuso] Progettazione fallita [duplicato]