在上一篇文章中，我們之前對(duì)BarChart.lerp的定義并不是高效的，我們正在創(chuàng)建的Bar實(shí)例，僅作為Bar.lerp的參數(shù)給出，并且針對(duì)動(dòng)畫參數(shù)t的每個(gè)值重復(fù)出現(xiàn)。每秒60幀，這意味著可能很多Bar實(shí)例被送到垃圾收集器，即使是相對(duì)較短的動(dòng)畫。

我們可以采用以下三種解決方案：

• Bar實(shí)例可以通過在Bar類中僅創(chuàng)建一次而不是每次調(diào)用collapsed來重復(fù)使用，但這種方法不適合我們的應(yīng)用程序。
• 重用可以通過BarChartTween來處理，通過使其構(gòu)造函數(shù)創(chuàng)建一個(gè)列表_tween的BarTween實(shí)例，在創(chuàng)建補(bǔ)間條形圖時(shí)使用(i) => _tweens[i].lerp(t)。這種方法破壞了使用靜態(tài)方法lerp的慣例，靜態(tài)BarChart.lerp中沒有涉及到任何對(duì)象，用于在動(dòng)畫持續(xù)時(shí)間內(nèi)存儲(chǔ)補(bǔ)間列表。相反，BarChartTween對(duì)象完全適合這一點(diǎn)。
• 假設(shè)Bar.lerp中有合適的條件邏輯，可以使用null來表示折疊條，這種方法是非常高效的，但是需要注意避免引用或誤解null。null常用在Flutter SDK中，其中靜態(tài)方法lerp會(huì)將null視為動(dòng)畫終點(diǎn)，通常將其解釋為某種不可見元素，比如完全透明的顏色或零尺寸的圖形元素。在我們的代碼中，lerpDouble將null視為零，除非兩個(gè)動(dòng)畫結(jié)束點(diǎn)都為null。

綜合考慮之下，我們使用最后一種解決方案，首先我們需要更新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)
  );
 }
}

現(xiàn)在我們的應(yīng)用程序里，如何將使用折疊的條形作為不可見元素的判斷，寫在Bar.lerp的條件邏輯中，實(shí)現(xiàn)我們想要的高效率。換一個(gè)角度來看，不知道大家有沒有發(fā)現(xiàn)，現(xiàn)在代碼的可維護(hù)性已經(jīng)不如上一個(gè)版本了。這就是為什么之前選擇看起來效率較低的解決方案。在性能與可維護(hù)性之間選擇，需要通過衡量之后再作出決定。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論