Perché i dispositivi di sviluppo ti offrono più risorse di un dispositivo tipico?

Ho creato un'app che funziona sul mio iPod Touch di quarta generazione e sull'iPod touch di quinta generazione della mia azienda.

Stavamo per rilasciare, quando abbiamo riscontrato un arresto anomalo che si verifica dopo che un dispositivo non sviluppatore esegue l'app *.

L'idea è che un dispositivo registrato come "dispositivo sviluppatore" fornisce alla tua app più risorse da utilizzare. Questo non mi sembra giusto, dal momento che non riuscivo a pensare a nessuna ragione che potesse esistere - penso che sia più probabile un problema con la creazione o la creazione di profili.

Tuttavia, ciò ha spinto una discussione. Perché in primo luogo esistono dispositivi come kit di sviluppo per console di gioco, dispositivi che hanno più capacità rispetto alla piattaforma di destinazione? Ovviamente è bello stressare un programma, ma una rappresentazione più accurata della piattaforma target avrebbe più senso?

TL; DR - Perché i kit di sviluppo hanno più risorse rispetto alle piattaforme target?

* Con un dispositivo non sviluppatore qualsiasi> terza generazione. Dispositivo iOS che scarica l'app dal nostro server, non direttamente da un computer con l'app e l'xcode installati.

_{Nota che c'è un'altra domanda che sembra simile, ma in realtà è diversa, perché quell'altra domanda si pone sul simulatore e capisco che ci sono enormi differenze tra l'uso di un simulatore e un dispositivo reale.}

L'ambiente di sviluppo (per qualsiasi cosa, che si tratti di un'applicazione Java autonoma, di un ambiente mobile o di un dispositivo incorporato) in genere ha la capacità di eseguire il debug remoto, la registrazione avanzata e altri tipi di introspezione dell'ambiente (in genere non si desidera per aggiungere tutti i ganci per un analizzatore logico su un dispositivo incorporato di produzione).

Queste cose aggiuntive richiedono risorse aggiuntive. L'apertura di un debugger remoto contro un VM o un altro ambiente remoto richiede alcune risorse dall'altra parte. Nel regno fortemente limitato del mobile, è possibile che queste risorse aggiuntive lo superino il limite concesso a un'applicazione standard. Pertanto, vengono fornite più risorse all'ambiente di sviluppo in modo che non raggiunga il limite delle risorse quando inizia a eseguire ulteriori log o debug.

Questo va oltre al punto che è sempre necessario testare qualcosa in un mirror dell'ambiente di produzione. Fidarsi che funzioni sui computer degli sviluppatori con tutte le loro modifiche e variabili diverse non è sufficiente per verificare che funzioni correttamente nella produzione.

Ti consente di creare una bozza di concetto avida di risorse che puoi successivamente ottimizzare.

Non ha senso arrestare in modo anomalo un'app perché è di 5 byte oltre il limite di memoria (che può essere risolto impostando l'ottimizzatore per risparmiare spazio nella versione ma si sta eseguendo una versione di debug),

avere un avviso pop-up nel registro quando si supera il limite del consumatore durante il test sarà bello qui.

In parte è una questione di "fiducia". Si presume che gli sviluppatori sappiano cosa stanno facendo e quindi hanno accesso illimitato al dispositivo e a tutte le sue risorse. Questo può essere di grande aiuto per le piccole aziende e i team di sviluppo, dove le risorse non utilizzate sono risorse sprecate.

In un ambiente aziendale più ampio, o in particolare il pubblico in generale, questo tipo di accesso diventa una responsabilità, a causa di problemi di sicurezza e della necessità di giocare bene con altre applicazioni che necessitano anche di risorse.

Questa non è davvero una nuova idea. Ho due macchine al lavoro. Sul mio computer sviluppatore ho accesso amministrativo, ma è isolato da Internet. L'altra mia macchina, che utilizzo per la posta elettronica, Office e l'accesso a Internet, non mi dà nemmeno la possibilità di installare programmi.

Questo è il motivo per cui devi testare la tua applicazione su un dispositivo non sviluppatore prima di distribuirla, per assicurarti che sia ben educata. :)

Con iOS, un dispositivo abilitato per lo sviluppo ti consente di eseguire direttamente build di debug, che potrebbero contenere un set diverso di bug del compilatore rispetto a una build di rilascio, nonché eseguire app in un nub di debug, che potrebbe cambiare in modo sottile i tempi dei thread e l'utilizzo della memoria, che può anche mostrare / nascondere vari problemi di threading e perdite di memoria.

Un dispositivo di sviluppo non sarebbe molto utile senza una funzionalità di debug e un dispositivo utente con funzionalità di debug presenterebbe un (più) grave problema di sicurezza dei dati di app e app.