Scrittura pulita, codice performante per l'iPhone

Question

Ho sviluppato su iPhone con Objective-C per alcuni mesi e ho applicato le best practice apprese e perfezionate durante lo sviluppo di applicazioni con Java. Questi includono: la progettazione di classi che hanno una sola responsabilità, l'applicazione di modelli di progettazione, se del caso, e la scrittura di short methods che fanno una cosa sola. Per me queste pratiche sono entrambe positive da una prospettiva clean-code e sono in gran parte indipendenti dal dominio.

Sono stato abbastanza soddisfatto dei risultati. Tuttavia, alcuni sviluppatori di iPhone mi hanno consigliato in modo indipendente contro questo, perché dicono che scrivo troppe classi e troppi metodi. In vari momenti sono stato messo in guardia:

• Lo stack soffierà
• Troppi classi rallenterà l'iPhone verso il basso (cioè percepibile dall'utente)
• chiamate di metodo nidificati farà male le prestazioni (cioè percepibile dal utente)

In pratica non ho riscontrato questi problemi. Guardando superficialmente ad alcuni iPhone performance metrics mi sembra che le chiamate extra al metodo e il sovraccarico del ciclo di vita degli oggetti richiesti per implementare modelli comuni e metodi brevi non creino probabilmente ritardi percepibili dall'utente. Tuttavia, il consiglio di altri sviluppatori iPhone mi ha spaventato un po '.

Mi piacerebbe continuare ad apprendere e perfezionare le pratiche di programmazione agnostica del dominio che mi hanno servito bene in passato, ma quando si sviluppa su iPhone non desidero percorrere una rotta che finirà nel dolore!

Quindi, per quanto riguarda questa piattaforma, dovrei abbandonare alcune best practice comuni ed essere più consapevole dell'ottimizzazione dei costi generali di chiamata di metodo e ciclo di vita degli oggetti? O devo continuare a seguire Knuth's consiglio:

ottimizzazione prematura è la radice di ogni male (o almeno la maggior parte di esso) in programmazione

Answer 1

Per me lo fa davvero venire giù a manutenibilità. con un codice di buona qualità è possibile mantenere il sistema molto più semplice.

Ho sviluppatori che lavorano con me e quando suggerisco loro di prendere scorciatoie per far funzionare un sistema, mi disprezzano e consegnano il progetto in ritardo. e ha pagato a lungo andare ogni volta !!!

se si tratta di un'app intensa, utilizzando opebGL e quali no, le prestazioni potrebbero diventare un problema. se è solo una semplice utility o un'app di dati. ti consiglierei di seguire le migliori pratiche di codice che conosci e poi continuare ad apprenderle perché sono inestimabili. La maggior parte dei modelli è indipendente dal dominio e vantaggiosa in tutti i linguaggi di programmazione fundemental.

E se fai saltare in aria lo stack, quindi riduci alcuni di quei metodi/classi in chiamate singole (almeno sai che potrebbe accadere e lo noterai non appena succede) E se non lo fa, allora sei fantastico codice per mantenere quello che è facilmente leggibile da qualsiasi scimmia di codice mezzo cotto che deve guardare quest'ultimo.

Answer 2

L'intero problema delle app OO che rallentano è semplicemente che l'oggetto può sfuggire a un controllo più facilmente rispetto agli stili di programmazione strutturati. C'era una volta, prima che le ottimizzazioni delle chiamate al metodo fossero migliorate, questo poteva fare la differenza, specialmente quando venivano fatte chiamate indirette (cioè virtuali).

Se i tuoi oggetti sono utilizzati molto e hai alcuni oggetti di livello inferiore che chiami spesso, allora potresti ottenere un successo in termini di prestazioni dal loro utilizzo - ma sto parlando di milioni di chiamate (ho visto un codice orribile nel mio tempo, sia non strutturato, strutturato e OO!). Otterrai anche più di un risultato in termini di prestazioni se assegni e cancelli continuamente lotti di oggetti (LOTS).

L'unica risposta, in realtà, è dare un'occhiata. Se hai un oggetto che viene assegnato, eliminato in rapida successione, quindi ottimizzalo (anche se sembra meno elegante), se hai un oggetto che chiami i suoi metodi migliaia di volte, quindi ottimizza anche quello. (ma una volta eseguita questa misurazione, avrai misurato le sue prestazioni e perfezionerai i bit lenti!)

C'è un compromesso tra codice "elegante" e codice che funziona in modo semplice e rapido, don andare ad entrambi gli estremi e si dovrebbe andare bene.

Answer 3

Ho avuto un'esperienza simile nello sviluppo di un'applicazione Blackberry piuttosto complicata. Mi è stato detto anche di evitare frequenti allocazioni di oggetti, classi interne, ecc. L'applicazione originale che avevamo era un disordine irraggiungibile. Recentemente ho riscritto l'applicazione concentrandomi su un buon design OO (modelli dove necessario, molti oggetti a scelta singola e spesso immutabili, ecc.). In molti luoghi, ho violato il consiglio di evitare certi costrutti "costosi" e le assegnazioni di oggetti. L'applicazione risultante non era solo più facile da mantenere, ma era anche più piccola. Se le allocazioni extra degli oggetti creavano un sovraccarico, di certo non me ne accorgevo. Penso che la lezione qui sia esattamente ciò che ha detto Knuth. Concentrati prima su un buon design, poi ottimizza se necessario. Inoltre, questi dispositivi mobili al giorno d'oggi hanno abbastanza memoria per cui questo consiglio si spera cadrà in disgrazia ...

Answer 4

In generale: non preoccuparti. L'unico caso in cui l'utilizzo di oggetti e messaggi potrebbe essere un potenziale problema di prestazioni è dove si stanno facendo centinaia o migliaia di allocazioni contemporaneamente, o facendo migliaia di messaggi inviati ogni pochi ms. Non vorrai usare oggetti Obj-C per rappresentare migliaia di vettori 3D in una simulazione fisica.

Anche nel caso in cui si stiano eseguendo molti messaggi in un ciclo, è possibile ottenere prestazioni migliori memorizzando un puntatore a funzione sul metodo appropriato prima del ciclo.