UIView/CALayer: Trasforma trigger layoutSubviews in superview

Question

Quando si modificano alcune proprietà per UIView si attiva layoutSubviews nella supestione . Non riesco a trovare alcuna affermazione a riguardo nei documenti.

Queste proprietà trigger di layout in superview e auto

• telaio
• limiti

Queste proprietà innesca layout in superview solo

• trasformare
• layer.transform

Queste proprietà trigger layout in sé solo

• nessuno

Queste proprietà non si innescherà qualsiasi layout

• centro
• layer.anchorPoint
• strato . posizione
• alfa

Trovo molto confuso che trasformano sta provocando il layout e che la posizione e AnchorPoint non lo fa.

Codice Esempio: https://github.com/hfossli/LayoutSubviewsInconsistency

---

Voglio sapere:

• perché sto vedendo questo comportamento
• se questo è davvero incoerenza o se sono equivoci alcuni concetti chiave
• come evitare supervi ew to layoutSubviews ogni volta che sto cambiando transform

Non riesco a trovare nulla su questo nei documenti, né i file di intestazione. Il problema è significativo quando si utilizza UIDynamics o simili.

Answer 1

Apple mi ha risposto via TSI (io personalmente penso che questo è spazzatura):

Parte 1

Perché vedo questo comportamento? è questa incoerenza o sto fraintendendo alcuni concetti chiave?

Una vista verrà contrassegnata per il layout ogni volta che il sistema avverte che qualcosa è cambiato che richiede la vista per ricalcolare i fotogrammi delle sue sottoview. Ciò può verificarsi più spesso di quanto ci si aspetterebbe e esattamente quando il sistema sceglie di contrassegnare una vista in quanto richiede che il layout sia un dettaglio di implementazione.

perché fa a cascata verso l'alto la gerarchia della vista?

In generale, modificare una proprietà geometrica di una vista (o strato) attiverà una cascata di layout di invalidazione della gerarchia vista, perché viste padre possono avere vincoli di layout automatico che coinvolgono il bambino modificata. Si noti che il layout automatico è attivo in qualche modo indipendentemente dal fatto che sia stato abilitato esplicitamente.

Come posso evitare di visualizzare superview per layoutView ogni volta che cambio la trasformazione?

Non esiste alcun modo per aggirare questo comportamento. Fa parte della contabilità interna di UIKit necessaria per mantenere coerente la gerarchia della vista.

Parte 2

Hi Håvard,

Ma se questo è vero non riesco proprio a capire perché questo non si applica alle 'layer.anchorPoint' e 'centro'/'layer .posizione'.

In questo caso, possiamo essere più prudenti. Le opinioni dei genitori non devono preoccuparsi della posizione dei loro figli, tranne quando viene coinvolto il layout automatico. E se il layout automatico fosse coinvolto, avresti bisogno di modificare i vincoli direttamente per produrre comunque una regolazione duratura nella posizione.

Questa trasformazione attiva il layout di Sessioni che ricade nuovamente verso l'alto.

È la mia comprensione che un cambiamento alla sola trasformare invalida la disposizione del padre immediato della vista (a meno che non si hanno vincoli di impostazione alla vista cambiato, allora diventa più complicato). Inoltre, le invalidazioni del layout vengono raggruppate in modo tale che il metodo di visualizzazione secondaria del layout del genitore debba essere chiamato una sola volta per transazione (frame). Tuttavia, posso capire che questo potrebbe causare problemi di prestazioni se la tua logica di layout è complicata.

Qualche idea?

Avvolgere il contenuto della cella in una vista intermedia. Quando modifichi la trasformazione di questa vista intermedia, solo il layout della cella deve essere invalidato, quindi il tuo costoso metodo di layout non verrà chiamato.

Se ciò non funziona, creare un meccanismo per segnalare al metodo di layout costoso quando effettivamente (o non) deve fare il lavoro. Questa potrebbe essere una proprietà che imposti quando le uniche modifiche apportate sono alle trasformazioni.