平時(shí)我們json解析常用到Gson，fastJson，Moshi等等，但是大家懂得他們?yōu)楹慰梢苑葱蛄谢鱿鄳?yīng)對(duì)象嗎？如果想提示解析性能我們?cè)撊绾蝺?yōu)化？如果對(duì)應(yīng)json的某個(gè)字段是數(shù)組類型，但是接口卻返回了null，我們又該如何處理呢？
問題1：Gson比JsonArray+JsonObject的優(yōu)點(diǎn)是什么？
Gson使用的是通過詞法分析方式，配合json字符的入棧出棧動(dòng)態(tài)載入內(nèi)存，相比較JsonArray+JsonObject而言更省內(nèi)存。
以“{”和“}”為例，在當(dāng)“{”入棧后，只要一直沒匹配到“}”，那么就一直往堆棧壓入json字符，否則就將最近的“{}”以及其中的字段解析成對(duì)應(yīng)的Object，并且這部分出棧，直至解析完畢。反序列化解析效果圖如下：
問題2：為什么會(huì)說Gson反序列化操作是一個(gè)比較消耗性能的操作？
在Gson解析的過程中，所有的解析操作都是通過TypeAdapter來解析的，每一個(gè)屬性以及每個(gè)對(duì)象都對(duì)應(yīng)一個(gè)TypeAdapter。
但是問題來了，Gson只認(rèn)識(shí)基本類型對(duì)應(yīng)的TypeAdapter，但是對(duì)于"{.....}"這整塊對(duì)象對(duì)應(yīng)的TypeAdapter，Gson是不認(rèn)識(shí)的，也沒法認(rèn)識(shí)，對(duì)象千千萬，如果由Gson都來實(shí)現(xiàn)是不切合實(shí)際的。故而Gson在解析到這塊后，發(fā)現(xiàn)不屬于任何已知的基本類型對(duì)應(yīng)的TypeAdapter，便只能通過反射構(gòu)建相應(yīng)的TypeAdapter對(duì)象，每一個(gè)對(duì)象對(duì)應(yīng)一個(gè)適配器，每個(gè)相應(yīng)適配器也只能通過反射方式創(chuàng)建以及填充出相應(yīng)對(duì)象，這便是Gson反序列化消耗性能的原因所在。對(duì)應(yīng)的執(zhí)行反射操作的類為ReflectiveTypeAdapterFactory。
問題3：既然Gson反序列化比較消耗性能，但是某些龐大復(fù)雜json又想高效的去解析，我們又該如何操作呢？
Gson消耗性能的原因在于反射，所以優(yōu)化的目標(biāo)也就是免反射，所有的解析都是通過集成TypeAdapter的類來解析的，所以我們也可以自定義自己的TypeAdapter，在其中實(shí)現(xiàn)自己對(duì)象的序列化以及反序列化的過程即可。
使用示例如下：
問題4：自定義TypeAdapter的局限性
由于自定義的適配器是和當(dāng)前類型是一一對(duì)應(yīng)的，所以但凡涉及到其他類的適配器操作時(shí)，也是要用到同樣方式書寫相應(yīng)的讀寫操作。那么有沒有去掉這一過程的方式呢？想一想，通過動(dòng)態(tài)注解如何？答案是肯定的，并且Square公司早已推出相應(yīng)第三方庫(kù)：Moshi，Square公司出品，必屬精品，牛。答案已經(jīng)說出來了，Moshi正是通過加入注解，編譯期間動(dòng)態(tài)幫我們生成對(duì)應(yīng)的適配器，免去了書寫的麻煩。
可以看出，由于實(shí)現(xiàn)方式的少許不同，注解生成的類繼承的是JsonAdapter，而我們手寫的是集成TypeAdapter。
需要注意的地方是，java bean必須是Kotlin的data class數(shù)據(jù)類，這是實(shí)現(xiàn)決定的，調(diào)用的地方無論java，kotlin都可。
