Mam ten prosty pogląd:Auto Layout: animowanie zmiany NSLayoutConstraint za mnożnik
- (void)viewDidLoad
{
[super viewDidLoad];
redBox = [[UIView alloc] init];
[redBox setBackgroundColor:[UIColor redColor]];
[redBox setTranslatesAutoresizingMaskIntoConstraints:NO];
[self.view addSubview:redBox];
//H:
widthConstraint = [NSLayoutConstraint constraintWithItem:redBox
attribute:NSLayoutAttributeWidth
relatedBy:NSLayoutRelationEqual
toItem:self.view
attribute:NSLayoutAttributeWidth
multiplier:0.5
constant:0.0];
[self.view addConstraint:widthConstraint];
//More constraints...
}
chciałbym ożywić wzrost szerokości RedBox za.
Próbowałem to:
widthConstraint.constant = 100;
[UIView animateWithDuration:1
animations:^{
[self.view layoutIfNeeded];
}
];
zwiększa szerokość widoku poprzez 100 i ożywia go, ale trzeba ją zwiększyć o kwotę proporcjonalny do szerokości Superview za swojego. Innymi słowy, chciałbym ustawić widthConstraint
's multiplier
na 0.8
.
Ale NSLayoutConstraint
’s multiplier
is readonly! Czy to oznacza, że muszę usunąć, zmodyfikować i ponownie dodać widthConstraint
za każdym razem, gdy chcę animować zmianę na jej multiplier
, czy jest lepszy sposób?
Jest dobry powód, że jest to tylko do odczytu; zmiana jest kosztowna i wymaga ponownego obliczenia układu; Z drugiej strony zmiana stałej jest tania. Tak więc, jeśli możesz, na przykład, obliczyć poprawną stałą i zmienić ją, jest to znacznie szybsze. Tylko do odczytu jest to zachęcić. –
Dynamiczne przeliczanie zmian układu w czasie wykonywania, czy nie jest to dokładnie to, do czego służy funkcja Auto Layout? – Eric
@Eric - patrz http://floriankugler.com/blog/2013/4/21/auto-layout-performance-on-ios - koszt wydajności rośnie wykładniczo wraz z liczbą wymagań. Za pomocą funkcji Auto Layout można ponownie obliczać zmiany układu w czasie wykonywania (całkowicie zastępując ograniczenie), ale interfejs API jest napisany w taki sposób, aby zachęcić użytkownika do zastosowania wydajnego podejścia. –