Comments 6
Спасибо, понятная и простая статья. Ради разнообразия скажу, что ещё вот таким образом можно изменить не используя context:
MediaQuery(
data: MediaQueryData.fromWindow(
WidgetsBinding.instance.window
).copyWith(textScaleFactor: 1),
child: ...,
),
Всё это сразу можно положить туда, где у вас маршрутизация.
clamp стоит использовать только когда есть запас по производительности.
В чем проблема clamp? это же обычная функция для типа num, и имеет достаточно тривиальную логику, которая не должна сказаться на производительности всего приложения.
Спасибо за комментарий! Я лично не знал про такой способ задания textScaleFactor.
Это не совсем обычная функция и проблемы с производительностью действительно имеют место быть. Ознакомьтесь с данным issue:
make sure that int.clamp and double.clamp are optimised in AOT
В целом, да, вы правы у clamp есть проблемы в текущей реализации, но у меня возникают сомнения, что они настолько серьезны, чтобы отказываться от использования этой функции в участках кода которые нечасто вызываются. В случае же когда у нас есть анимация, то это действительно может оказаться заметной проблемой.
Но опять же, этот issue решает проблему с производительностью на уровне sdk языка и на мой взгляд, оно оказывается существенным в случае производительности например всего flutter, в случае же одного вызова разница в производительности будет на грани погрешности (а так и будет, так как textScaleFactor очень редко меняется).
Как не «сломать» вёрстку Flutter-приложения из-за textScaleFactor