在上一篇文章中,我们之前对BarChart.lerp的定义并不是高效的,我们正在创建的Bar实例,仅作为Bar.lerp的参数给出,并且针对动画参数t的每个值重复出现。每秒60帧,这意味着可能很多Bar实例被送到垃圾收集器,即使是相对较短的动画。
我们可以采用以下三种解决方案:
综合考虑之下,我们使用最后一种解决方案,首先我们需要更新BarChart的部分代码。
class BarChart {
// ...
static BarChart lerp(BarChart begin, BarChart end, double t) {
final barCount = max(begin.bars.length, end.bars.length);
final bars = new List.generate(
barCount,
(i) => Bar.lerp(begin._barOrNull(i), end._barOrNull(i), t)
);
return new BarChart(bars);
}
// ...
}
然后我们还需要更新一下Bar的条件逻辑。
class Bar {
Bar(this.x, this.width, this.height, this.color);
final double x;
final double width;
final double height;
final Color color;
static Bar lerp(Bar begin, Bar end, double t) {
if(begin == null && end == null)
return null;
return new Bar(
lerpDouble((begin??end).x, (end??begin).x, t),
// ?:变量可以为null
lerpDouble(begin?.width, end?.width, t),
lerpDouble(begin?.height, end?.height, t),
Color.lerp((begin??end).color, (end??begin).color, t)
);
}
}
现在我们的应用程序里,如何将使用折叠的条形作为不可见元素的判断,写在Bar.lerp的条件逻辑中,实现我们想要的高效率。换一个角度来看,不知道大家有没有发现,现在代码的可维护性已经不如上一个版本了。这就是为什么之前选择看起来效率较低的解决方案。在性能与可维护性之间选择,需要通过衡量之后再作出决定。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。