哈嘍，我是老劉

最近在知乎上看到這樣一個問題

我們先來解釋一下問題中碰到的幾個現(xiàn)象的可能原因，然后聊聊跨平臺的最優(yōu)解問題

問題解釋

1、跟手、絲滑問題

這個問題其實很多人是有誤解的，覺得原生的就絲滑跟手
其實不是這樣的
我在做Flutter開發(fā)之前，已經(jīng)做了好幾年的Android開發(fā)
那時候我日常工作中時不時會出現(xiàn)的一項任務(wù)就是優(yōu)化某個頁面的性能
所以即使是原生也經(jīng)常出現(xiàn)頁面卡頓的情況

為什么會這樣呢？
其實這和客戶端的運行原理有關(guān)
在客戶端開發(fā)中，不管是原生還是Flutter，都會給開發(fā)者提供最大程度的可控性
比如如果你實現(xiàn)一個列表頁，如果列表中的每一行都只是一行簡單的文字
那不管原生還是Flutter，甚至RN、網(wǎng)頁都可以很流暢
但是如果你希望隨著列表頁的上下滑動，其中的每個行都基于它在屏幕中的位置展示不同的顏色、大小等外觀
那么就需要列表頁每向上或者向下滑動一個像素，都能調(diào)用一次你寫的代碼，來重新根據(jù)當前位置計算這一行的大小和顏色等屬性
原生和Flutter在如何設(shè)置及調(diào)用這個處理方法的細節(jié)上不同，但是基本流程都是一樣的
那么如果你的計算方法很復(fù)雜，耗時300ms
就相對于頁面每移動一個像素，就要等你的回調(diào)運算300ms
用戶體驗自然就是卡頓，不流暢
而我們開發(fā)人員進行性能優(yōu)化，有很大一部分就是減少這種每一幀的運算耗時

所以很多用戶看到的卡頓其實不是平臺或者框架的問題，而是開發(fā)者有沒有優(yōu)化到位的問題

當然，在某些極端性能要求的場景下，Flutter的性能確實比原生是要差一點的
這種問題隨著Impeller引擎的替換，會逐步得到解決
而且這種情況大多數(shù)頁面里用戶是感覺不到的

2、不同頁面狀態(tài)不一致

后面提出的開始下載了下載頁面沒有顯示，以及聊天通知到了但是頁面沒有看到
我統(tǒng)一歸類為不同頁面狀態(tài)不一致問題

我們拿下載功能為例，來看一下這個功能大約是怎么實現(xiàn)的
首先我們要實現(xiàn)一個后臺的下載模塊
功能是完成文件下載到本地、下載的暫停續(xù)傳、下載狀態(tài)維護、下載進度等狀態(tài)變化對外通知
注意這個功能是完全的后臺功能，用戶是看不到的

然后我們來實現(xiàn)用戶的UI
這里會實現(xiàn)兩個和下載相關(guān)的頁面：
一個是文件列表頁，有下載按鈕，點擊后啟動下載
第二個是下載頁面，顯示正在下載的資源的下載狀態(tài)，比如下載進度
在第一個頁面中，我們點擊下載按鈕，就會通知下載模塊開始一個下載任務(wù)

那么具體如何開始下載任務(wù)呢
通常是這樣的過程
a、調(diào)用服務(wù)端的接口，根據(jù)選擇的文件id，獲取下載該文件的cdn地址
b、和cdn服務(wù)器建立連接
c、開始從cdn服務(wù)器下載資源

我們可以看到，從第一步開始就需要網(wǎng)絡(luò)傳輸
所以在真正開始下載文件之前，也是有網(wǎng)絡(luò)傳輸?shù)?#xff0c;只不過這個數(shù)據(jù)量不會很大
而且如果下載模塊實現(xiàn)的不是很嚴謹
當文件真正開始下載之前，下載模塊沒有把這個下載任務(wù)添加到正在下載的任務(wù)列表中
就會出現(xiàn)前面提到的網(wǎng)絡(luò)已經(jīng)在跑但是下載列表中看不到的場景

那么大家覺得這種情況是開發(fā)框架的問題還是代碼實現(xiàn)的問題呢？

好了，前面的說明只是想告訴大家
很多時候我們看到一個軟件的bug或者說缺陷
不一定是軟件使用的框架不好，也有可能是軟件的實現(xiàn)不太好或者優(yōu)化不到位
那么接下來我們來說說跨平臺的最優(yōu)解

跨平臺的最優(yōu)解

首先我認為這個是偽命題

有人認為Flutter是跨平臺開發(fā)的最優(yōu)解，但這種觀點往往忽略了不同應(yīng)用場景下的具體需求。
事實上，并沒有一種“一刀切”的解決方案，每種框架都有其適用的場景和優(yōu)勢。
不同的應(yīng)用場景對技術(shù)的需求是多樣化的。
例如，在需要高度動態(tài)化的應(yīng)用場景中，用戶無需升級App即可體驗新功能，這時React Native（RN）可能因其熱更新特性而成為更好的選擇。

Flutter的最佳適用場景

那么，哪些場景下Flutter是最佳選擇呢？
我覺得是以下兩個主要的場景：
1、對性能有較高要求：
Flutter通過編譯成原生代碼，能夠提供接近原生應(yīng)用的性能。對于那些對響應(yīng)速度和流暢度有嚴格要求的應(yīng)用，如游戲或需要復(fù)雜圖形渲染的應(yīng)用，Flutter無疑是一個優(yōu)秀的選擇。
2、對兩端一致性有較高要求：
Flutter提供了統(tǒng)一的UI組件庫，這有助于開發(fā)者在iOS和Android平臺上實現(xiàn)一致的用戶體驗。對于那些追求在不同平臺上提供統(tǒng)一界面和體驗的應(yīng)用，Flutter的這一特性顯得尤為重要。

特定條件下的最優(yōu)選擇

我們不應(yīng)該認為Flutter是完美無缺的。
實際上，在滿足特定條件的情況下，Flutter可以是目前能找到的最優(yōu)選擇。
這并不是因為Flutter在所有方面都是最好的，而是因為它在特定場景下能夠提供最佳的性能、一致性和開發(fā)效率。

總結(jié)

技術(shù)選型是一個需要根據(jù)具體情況權(quán)衡利弊的過程。
開發(fā)者應(yīng)該深入了解不同技術(shù)的優(yōu)勢和局限性，并結(jié)合項目的實際需求來做出最合適的決策。
無論是Flutter、React Native還是其他技術(shù)，它們都只是在特定條件下的最優(yōu)選擇，而不是放之四海而皆準的解決方案。

如果看到這里的同學有學習Flutter的興趣，歡迎聯(lián)系老劉，我們互相學習。
點擊免費領(lǐng)老劉整理的《Flutter開發(fā)手冊》，覆蓋90%應(yīng)用開發(fā)場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發(fā)場景的《Flutter開發(fā)手冊》https://mp.weixin.qq.com/s?__biz=MzkxMDMzNTM0Mw==&mid=2247483665&idx=1&sn=56aec9504da3ffad5797e703c12c51f6&chksm=c12c4d11f65bc40767956e534bd4b6fa71cbc2b8f8980294b6db7582672809c966e13cbbed25#rd