你應該知道的Flutter

公司有團隊最近在作一個語音房app，ui層面使用flutter實現，在初版完成之際作了一次分享。作一下會議筆記，備忘。

文件名命名規範

因爲是第一次作flutter項目，加上團隊小夥伴開發經驗不是很足，在知足需求的同時，對其餘以外的事情考慮的比較少，每一個人在建立dart文件的時候考慮的比較少，固然取名字也是一個很專業的事情，好的名字決定了app的一輩子。

好比登陸頁面，login.dart這樣簡單粗暴，可是要是登陸涉及到一些校驗，須要彈窗，或者輸入驗證碼，或者第三方登陸，或者手機號登陸，密碼登陸，另外又有封禁等，難到這些都懟到一個文件內部嗎，那login就不能知足要求了，須要拆分login的其餘模塊，在這一塊的考慮不是很周全。

內存問題

flutter啓動就有一百兆的內存，業內也有一些解決方案能夠部分下降內存，可是也會有崩潰的風險，這是engine內部實現的問題。

圖片加載內存過大，這是開發不當心把幾張3M+的圖片放進去，內存就暴漲，猜其內部實現沒有對Image的圖片緩存作大小的如今，好比UIImage內部在圖片佔用內存達到100M的時候會自動回收一部份內存，使用方式也能夠根據path加載路徑，這樣加載完就釋放了。這個問題開發其實也是可控的。

包體大小

flutter的engine默認加進來就多10兆+的大小，問題說大不大說小不小，由於是海外項目，國外不少低端機型，這個engine的大小又是不可避免的，至少在領導看來是應該須要解決的。雖然不少開發不情願。

日誌分類

在原生開發的項目到了必定的複雜程度，日誌分析必不可少，然而日誌的產生就是編寫代碼的時候本身加上去的，爲了給往後分析線上問題提供惟一的途徑。

日誌分類在flutter內部幾乎是沒有規劃，尤爲對於小項目。目前flutter的日誌都是和原生的日誌混在一塊兒，若是項目作大，將來跟蹤線上問題確定麻煩事情。 簡單說flutter日誌應該單獨放在一個文件裏面。

格式還和原生格式相似 時間+文件名+行號+方法名+tag+log內容

崩潰收集

flutter崩潰不一樣於原生，不會crash，可是會白屏或者一片紅，致使用戶不得不殺進程才能操做。目前市面有這樣的崩潰分析系統，可是不符合公司標準。公司但願統一一套標準，崩潰自動上報到公司內部崩潰系統，帶上堆棧信息，另外能夠一鍵提bug指定給對應的人。 遊離於公司系統以外，畢竟在項目管理層面來講不是個好消息。

性能問題fps、cpu、gpu、耗電量

都是流暢性，跨平臺是flutter的優勢。

可是也是僅此而已吧，不用太吹噓，這些是陳詞濫調，可是它的cpu，gpu，耗電量對於簡單的app來講固然沒什麼問題，可是涉及到音視頻這些項目，原生來講都是個問題，對於flutter更是問題，問題不在於語言，而在於分析的工具側不完善，performance是個不錯的選擇，可是用慣了原生性能檢測的如instrument這種來講就會以爲flutter的很弱了。

舉一個痛點問題，音頻上麥，在iphonex 半個小時耗電35%，在flutter上麥怎麼查。 雞賊的辦法就是丟給sdk去查了。若是之後這些sdk模塊用flutter寫了，又怎麼查。

事件通知處理方式混亂

eventbus和stream均可以處理事件發送接收問題。每一個人也有本身的方式，這個在以前沒有一個統一的規範寫法，致使混亂。跨模塊問題目前在flutter方向有一些好的解決方案，如閒魚的 fish redux

跨模塊封裝問題

flutter代碼多了，須要考慮重用問題，沉澱一些東西出來，封裝和跨模塊，解耦是終極問題，其實和語言已經不要緊了，借鑑行業經驗，解耦就是須要抽象再抽象，思路不同，寫法不同。插拔模式思路，應該就抽象出組件，提供註冊的方法，提供反註冊的方法，再提供一個取的方法。每一個模塊遵循一些協議。

其餘項目和sdk的flutter計劃

一個音視頻的sdk不必定僅僅是這個sdk，它其實也依賴了其餘的sdk，如日誌，統計，人臉識別，還有其餘第三方的。固然所有要用flutter是不現實的。目前來講，公司是有意願部分通用的慢慢flutter化，可是過程會很漫長效果也不會理想。

然而對於新的app，使用flutter是沒有懸念的事情，從成本上面來講這是個優點，另外一方面性能上面不損失，就至關於花更少的錢辦了一樣的事情。固然樂見其成。

後續計劃

爲了在性能上面不損失，不能依賴flutter作ui這些表層的事情了。必須再深刻下去，減小包體，下降內存，提升cpu使用效率等等。

做者

共田君