如何在 Flutter 上優雅地序列化一個物件

摘要： 序列化一個物件才是正經事 物件的 序列化 和 反序列化 是我們日常編碼中一個非常基礎的需求，尤其是對一個物件的json encode/decode操作。每一個平臺都會有相關的庫來幫助開發者方便得進行這兩個操作，比如Java平臺上赫赫有名的 GSON ，阿...

而在Flutter上，藉助官方提供的 JsonCodec ，只能對 primitive / Map / List 這三種類型進行json的encode/decode操作，對於複雜型別， JsonCodec 提供了receiver/toEncodable兩個函式讓使用者手動“打包”和“解包”。

顯然， JsonCodec 提供的功能看起來相當的原始，在閒魚app中存在著大量複雜物件序列化需求，如果使用這個類，就會出現集體“帶薪序列化”的盛況，而且還無法保證正確性。

關於如何使用 json_serializable 網上已經有很多文章了，這裡只簡單提一些步驟：

• Step 1 建立一個實體類。

• Step 2 生成程式碼:

讓 build runner 生成序列化程式碼。執行完成後資料夾下會出現一個 xxx.g.dart 檔案，這個檔案就是生成後的檔案。

• Step 3 代理實現:

把 fromJson 和 toJson 操作代理給上面生成出來的類。

我們為什麼不用它實現？

json_serializable 完美實現了需求，但它也有不滿足需求的一面:

• 使用起來有些繁瑣，多引入了一個類

• 很重要的一點是，大量的使用 "as" 會給效能和最終產物大小產生不小的影響。實際上閒魚內部的《flutter編碼規範》中，是不建議使用 "as" 的。(對包大小的影響可以參見三笠同學的文章，同時dart linter也對as的效能影響有所描述）

1 需要實現的功能

我們首先來梳理一下，一個序列化庫需要用到：

1. 獲取可序列化物件的所有field以及它們的型別資訊

2. 能夠構造出一個可序列化物件，並對它裡面的fields賦值，且型別正確

3. 支援自定義型別

4. 最好能夠解決泛型的問題，這會讓使用更加方便

5. 最好能夠輕鬆得在不同的序列化/反序列化方式中切換，例如json和protobuf。

2 困難在哪

1. flutter禁用了 dart:mirrors ，反射API無法使用，也就無法通過反射的方式new一個instance、掃描class的fields。

2. 泛型的問題由於dart不進行型別擦出，可以獲取，但泛型巢狀後依然無法解開。

3 Let's rock

無法使用 dart:mirrors 是個“硬”問題，沒有反射的支援，類的內容就是一個黑盒。於是我們在邁出第一步的時候就卡殼了- -!

這個時候筆者腦子裡閃過了很多畫面，白駒過隙，烏飛兔走，啊，不是...是c++，c++作為一種無法使用反射的語言，它是如何實現物件的 序列化/反序列化 操作的呢？

一頓搜尋猛如虎之後，發現大神們使用 建立類物件的回撥函式 配合 巨集 的方式來實現c++中類似反射這樣的操作。

這個時候，筆者又想到了曾經朝夕相處的Android(現在已經變成了flutter)，Android中的 Parcelable 序列化協議就是一個很好的參照，它通過writeXXX APIs將類的資料寫入一箇中間儲存進行序列化，再通過readXXX APIs進行反序列化，這就解決了我們上面提到的第一個問題，既如何將一個類的“黑盒子”開啟。

同時，Parcelable協議中還需要使用者提供一個叫做 Creator 的靜態內部類，用來在反序列化的時候反射建立一個該類的物件或物件陣列，對於沒有反射可用的我們來說，用c++的那種回撥函式的方式就可以完美解決反序列化中物件建立的問題。

於是最終我們的基本設計就是：

• ValueHolder

• FishSerializable

• JsonSerializer

以上，我們已經基本做好了一個flutter上支援物件序列化/反序列化操作的庫的基本架構設計，物件的序列化過程可以簡化為:

由於ValueHolder中間儲存的存在，我們可以很方便得切換 序列化/反序列器，比如現有的JsonSerializer 用來實現json的encode/decode，如果有類似protobuf的需求，我們則可以使用ProtoBufSerializer 來將 ValueHolder 中的內容轉換成我們需要的格式。

困難是不存在的

1 如何匹配型別

為了能支援泛型容器的解析，我們需要類似下面這樣的邏輯：

在Java中，可以使用Class#isAssignableFrom，而在flutter中，我們沒有發現類似功能的API提供。而且，如果做下面這個測試，你還會發現一些很有意思的細節：

輸出的結果是：

可以看到，對於List這樣的容器型別，函式的type argument與instance的runtimeType無法比較，當然如果使用 t is T ，是可以返回正確的值的，但需要構造大量的物件。所以基本上，我們無法進行型別匹配然後做型別轉換。

2 如何解析泛型巢狀

接下去就是如何分解泛型容器巢狀的問題，考慮如下場景：

readMap中得到的value type是一個 List<int> ，而我們沒有API去切割這個type argument。 所以我們採用了一種比較“笨”也相對實用的方式。我們使用字串切割了type argument，比如：

然後在內部展開List或Map的時候，使用字串匹配的方式匹配型別，在目前的使用中，完美得支援了標準 List 和 Map 容器互相巢狀。但目前無法支援標準 List 和 Map之 外的其他容器型別。

What's more

1 IDE外掛輔助

寫過Android的Parcelable的同學應該有種很深刻的體會，Parcelable協議中有大量的“機械”程式碼需要寫，類似設計的 fish-serializable 也一樣。

為了不被老闆和使用庫的同學打死，同時開發了 fish-serializable-intelij-plugin 來自動生成這些“機械”程式碼。

2 與json_serializable的對比

• fish-serializable 在使用上配合IDE外掛，減少了大量的 "as" 操作符的使用，同時在步驟上也更加簡短方便。

• 相比於  json_annotation 生成的程式碼，  fish-serializable 生成的程式碼也更具可讀性，方便手動修改一些程式碼實現。

• fish-serializable 可以通過手動接管 序列化/反序列化 過程的方式完美相容  json_annotation 等其他方案。

目前閒魚app中已經開始大量使用。

3 開源計劃

fish-serializable和 fish-serializable-intelij-plugin 都在開源計劃中，相信不久就可以與大家見面，盡請持續關注我們的公眾號~