Domanda

La domanda principale è " quanti UIViewController puoi spingere nello stack di navigazione? " senza causare avvisi di memoria o guadagnare la chiusura di un watchdog.

Supponiamo che io abbia un'applicazione che è fondamentalmente un database per tre entità in cui ciascuna può avere una relazione con qualche altra entità, e la relazione è mostrata su un UIViewController. Gli utenti possono seguire queste relazioni e ognuno fa apparire un nuovo controller - Se le entità sono A, B e C e A- > B- > C- > B- > C- > A, allora ogni tipo di vista è in pila due volte. Capisco come eseguire il push e il pop, come eseguire il push su un determinato controller e penso che piuttosto che estendere indefinitamente lo stack di navigazione, potrebbe essere meglio riutilizzare un controller di visualizzazione nello stack di navigazione.

Per fare ciò, ogni volta che volevo un FirstEntityViewController, potevo scansionare lo stack di navigazione per trovare un oggetto in cui [self isKindOfClass: [classe FirstEntityViewController]]; e quindi chiamare i metodi progettati per rievocare quella vista per quello che attualmente voglio vedere - semplicemente aggiornando i dati nello stesso modo in cui fai quando riutilizzi un UITableViewCell.

Questo va bene tranne per l'effetto che potrebbe avere sul NavigationController. Se uso UINavigationController: popToViewController: animato: penso che eliminerà tutto sopra la vista a cui sto saltando, inclusa la vista che l'utente si aspetta di trovare toccando " Indietro " nella barra di navigazione. Quindi l'utente tocca una relazione, torna indietro e va " huh? & Quot;

Se rimuovo il controller corrispondente dallo stack di navigazione e poi lo inserisco nella parte superiore dello stack, il comportamento indietro rimane OK fino a quando l'utente non torna indietro fino all'istanza di FirstEntityViewController che è stata spostata o altrimenti la navigazione sembrerà incoerente.

È la soluzione giusta per rimuovere il controller dallo stack e in qualche modo mantenere un posto nello stack in modo che quando il controller riutilizzato viene espulso possa essere sostituito di nuovo da dove proviene? Devo mantenere il mio elenco di tipi di visualizzazione e visualizzazione dei dati in modo che, quando apro, posso sostituire la vista sotto la vista che sta per comparire, rimanendo un passo avanti rispetto alla navigazione indietro?

O sta diventando troppo complicato? Non è nemmeno necessario preoccuparsi di questa situazione perché il sistema operativo riutilizza gran parte dei controller di visualizzazione allo stesso modo in cui UITableViewCells viene riutilizzato e non vi è alcun impatto reale sulla memoria o sulle prestazioni nell'avere uno stack di navigazione a 50 profondità?

È stato utile?

Soluzione

Le istanze di ViewController rimangono nello stack di UINavigationController, ma qualsiasi vista ad eccezione della vista superiore può essere scaricata in qualsiasi momento (il controller della vista viene notificato tramite il messaggio viewDidUnload ).

In altre parole, le viste sotto la vista superiore non si bloccano e alla fine verranno scaricate in condizioni di memoria insufficiente, quindi non è necessario tentare di riutilizzare i controller di visualizzazione.

Altri suggerimenti

L'ultima volta che ho verificato non è possibile reinserire nuovamente un viewcontroller che è già su uno stack di navcontroller. Dovrai creare un nuovo viewcontroller e spingerlo nello stack e ogni pulsante indietro lo farà uscire dallo stack. Il meglio che puoi fare è creare una cache di controller di visualizzazione e distribuirli quando necessario - purché siano saltati fuori dallo stack del navcontroller. Ma probabilmente non ti comprerà molto per risparmiare memoria.

UITableViews è un po 'diverso in quanto c'è solo un numero relativamente piccolo di celle in vista in un dato momento e non appena la cella esce dallo schermo viene rimossa e restituita nel pool. Se puoi garantire che il maxdepth della tua catena sia fisso, puoi tirare uno schema di finestre simile. In caso contrario, potresti dover continuare ad approfondire ed essere vigile sul rilascio della memoria il prima possibile.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top