Какой метод недействительности использовать

Question

Я немного смущен, о том, какой метод invalidate использовать и когда его использовать. Мне нужно изменить й и у компонента, и в этом случае следует вызвать метод недействительности для оптимизации, но я не знаю, какой из них и когда именно

target.addElement(node); 
node.x = 100 + target.horizontalScrollPosition; 
node.y = 100 + target.verticalScrollPosition; 

узел и цель являются группами

Answer 1

Это зависит от компонента и, возможно, вам вообще не нужно звонить. Из данного фрагмента кода я бы сказал, что это invalidateSize(). Но контейнеры обычно делают хорошую работу по измерению их свойств размеров. invalidateDisplayList может быть хорошим вызовом, если вам нужно изменить способ отображения компонента.

Так что, вообще говоря, это зависит от компонента (супер тип и т. Д.), Который вы реализуете.

Редактировать: Поскольку оба экземпляра представляют собой группы, вы не должны называть какие-либо методы недействительности вообще. Вы будете использовать вызовы только при реализации пользовательского компонента с дополнительными свойствами. В случае с группами все заранее сделано для вас. Компонентный живой цикл реализован, и различные макеты обеспечивают удобный уровень косвенности.

Когда вы расширяете группу (или любой другой компонент), вы должны быть знакомы с жизненным циклом компонента.

Правило тумб:

1. игнорировать недействительности вызовы в чистом MXML, как это делается с помощью MXML компилятора и самих компонентов.
2. использовать вызовы недействительности в переопределенных сеттерах, которые мутируют состояние компонента (даже в MXML). Это обычно приводит к чистой, но простой конструкции компонентов, если сеттеры используются повсюду - даже внутри частных методов компонентов.
3. использовать validateSize, validateNow и т. Д., Так как это простые синхронные ярлыки, исключающие живой цикл компонента.

Текущие циклы недействительности основаны на эластичной гоночной дорожке вспышек, которая делит рендеринг и обработку данных в разных аспектах обработки кода.

Дальнейшие показания относительно идеи позади недействительности называет: Обновлено эластичная беговая дорожка [1] и Упругие ипподром [2]

1. [1]: http://www.craftymind.com/updated-elastic-racetrack-for-flash-9-and-avm2/
2. [2]: http://tedpatrick.com/2005/07/19/flash-player-mental-model-the-elastic-racetrack/