在上一篇文章中，我們之前對BarChart.lerp的定義并不是高效的，我們正在創(chuàng)建的Bar實(shí)例，僅作為Bar.lerp的參數(shù)給出，并且針對動(dòng)畫參數(shù)t的每個(gè)值重復(fù)出現(xiàn)。每秒60幀，這意味著可能很多Bar實(shí)例被送到垃圾收集器，即使是相對較短的動(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中沒有涉及到任何對象，用于在動(dòng)畫持續(xù)時(shí)間內(nèi)存儲補(bǔ)間列表。相反，BarChartTween對象完全適合這一點(diǎn)。
• 假設(shè)Bar.lerp中有合適的條件邏輯，可以使用null來表示折疊條，這種方法是非常高效的，但是需要注意避免引用或誤解null。null常用在Flutter SDK中，其中靜態(tài)方法lerp會將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)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持VEVB武林網(wǎng)。