公司有團隊最近在做一個語音房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使用效率等等。
作者
共田君 |