對於一個技術框架的生態來說,三方庫是非常非常重要的。Flutter 的朋友都知道 pub 作為官方的倉庫,有海量的三方類庫供開發者使用。FlutterUnit 作為 Flutter 技術的前沿營地,打算推出一個新的模組:
三方包 : 在應用中,提供插件的推薦、搜索、分類、評價、國際化等,拓寬開發者接觸插件的形式。讓好的類庫不被埋沒。

之前的留言板功能被放在了 我的 中,主介面的黃金地段增加了 三方庫 一欄,目前收錄了一百多個常用的三方類庫。並將這些資料收集到了我的後端,並提供了分類展示和評論兩大功能,這樣可以給大家一個討論類庫的場地,聊聊你對插件的看法、用途等。
| 包首頁 | 包詳情 |
|---|---|
![]() |
![]() |
另外,還提供了推薦插件的入口,使用者可以在這裡推薦一下目前沒有收錄,但你覺得很不錯的插件。歡迎在這裡和大家共享 ~
另外支持根據下載量、喜歡數、發佈時間進行排序。
| 推薦創建 | 排序方式 |
|---|---|
![]() |
![]() |
本次最大的亮點當屬評論了,支持二級評論,大於兩條的評論會展示查看更多評論。如果詳情頁評論總數大於 10 ,底部會有查看全部的評論,支持分頁加載:
| 詳情頁評論 | 評論詳情頁 |
|---|---|
![]() |
![]() |
目前後台基於 Rust 做的服務,也基本完成了模組化開發。package 模組負責當前功能相關的所有服務接口。支持獨立測試。分模組最大的好處是功能隔離,這樣 AI 可以更有效率地輔助編碼,而且可以參考一個模組的功能,去開發別的模組。三方庫相關的接口 95% 是由 AI 獨立完成的:

不得不說,自從換上了 rust 服務,我的 2G 記憶體的小伺服器也更能打一些了。之前使用 Java 的 Springboot 做的服務,上來就小幾百兆,現在 rust 運行很久,也就 16 M.

和 AI 討論數據表的創建,也讓我收益頗豐。特別是對於多語言的處理,分離出了 t_pkg_translations 表,可以在不侵入原表結構的情況下,增加字段級別的翻譯映射關係。更利於其他字段、其他語言的支持:


為了方便管理數據,我還讓 AI 基於 VUE 順手寫了個後端管理系統 ~

前端也採用模組化開發,pkg_player 模組負責該功能的所有邏輯實現,另外它是一個可以獨立運行的模組,這可以讓它可以獨立於 FlutterUnit 進行開發,開發階段只需要運行 exsample 即可,可以讓 AI 更聚焦於每個模組,減少其他資訊的干擾。當完成開發,進行組裝到 FlutterUnit 即可。

這種可插拔的模組化,可以最大程度重用模組。比如未來我有一個 編程營地 的應用,只需要引入pkg_player 模組,然後拼裝一下,編程營地就有了當前的三方庫的展示和交流能力。
由於引入了 AI 編程,我希望像流水線一樣,AI 可以根據我的程式碼組織結構,進行程式碼的產出。使用我設計了三層的 MVVM 應用架構,其中:

我約定一般情況下 view 和 repository 之間不直接依賴,另外 repository 中的程式碼需要支持 脫離視圖層 也可以獨立運行,這樣便於單元測試。
前端的程式碼大概 80% 也是由 AI 完成的,但這並不代表開發者什麼都不要幹。我的角色是從敲程式碼的,變成了指揮 AI 敲程式碼的。如何設計整體的功能、互動的細節、資料的結果,還是需要花費心力的。
註: AI 的程式碼品質可以說中規中矩,還是有些需要優化的地方。良好的結構,可以讓 AI 的洪水不至於肆意蔓延。約束它,引導它,受用於你。
希望模組化的開發結構,可以在 AI 的浪潮下,讓你的 Flutter 應用更加內聚,符合單一職責原則、合成重用原則。目前正在根據實踐經驗,設計 fx 通用應用架構,敬請期待~
為了便於包支持模組化,我寫了一個 dart 腳本,可以分析統計模組中字串,使用的非英文字符,以及在程式碼中的具體位置。

最後還會統計所有不同的字串:

你可以把這些丟給 AI ,讓它生成 arb 文件,然後根據中文,再得到英文翻譯:

最終就會得到可用的資源:

這樣在資料層面和本地資源,都支持了國際化:
| 英文 | 中文 |
|---|---|
![]() |
![]() |
文章裡就不說詳細的程式碼實現了,FlutterUnit 是一個開源專案,大家可以自己去運行體驗。最後,FlutterUnit3.4 版本,三方庫功能已經上線,大家可以在 github 上更新最新版的軟體包體驗,歡迎多多交流,為你喜歡的三方庫打 call ~
更多文章和視頻知識資訊,大家可以關注我的公眾號、掘金和 B 站 。讓我們一起成長,變得更強。我們下次再見~