ios 開發中總會用到各種 json 模型轉換庫，這篇文章將會對常見的幾個開源庫進行一下評測。評測的內容主要集中在效能、功能、容錯性這幾個方面。
manually
手動進行 json/model 轉換，不用任何開源庫，可以進行高效、自由的轉換，但手寫**非常繁瑣，而且容易出錯。
yymodel
我造的乙個新輪子，比較輕量（算上 .h 只有 5 個檔案），支援自動的 json/model 轉換，支援定義對映過程。api 簡潔，功能也比較簡單。
yalantis 開發的乙個 json 模型轉換庫，可以自定義詳細的 model 對映過程，支援 coredata。使用者較少。
jsonmodel
乙個 json 模型轉換庫，有著比較簡潔的介面。model 需要繼承自 jsonmodel。
mantle
github 官方團隊開發的 json 模型轉換庫，model 需要繼承自 mtlmodel。功能豐富，文件完善，使用廣泛。
mjextension
國內開發者"小碼哥"開發的 json 模型庫，號稱效能超過 jsonmodel 和 mantle，使用簡單無侵入。國內有大量使用者。
所有開源庫**更新至 2015-09-18，以 release 方式編譯，執行在 iphone 6 上。
用例1：githubuser
從 獲取的一條 user 資料，去除 nsdate 屬性。
該 json 有 30 行，大部分屬性是 string，少量是 number。這個用例主要是測試最基礎的 model 相關操作。
每次測試執行 10000 次，統計耗時毫秒數。
用例2: weibostatus
測試結果如下：
mantle 在各個測試中，效能都是最差的
jsonmodel 和 mjextension 效能相差不多，但都比 mantle 效能高。
yymodel 效能高出其他幾個庫乙個數量級，接近手寫**的效率。
容錯性主要是測試在預設情況下，當 json 格式錯誤時，model 框架是否會產生錯誤結果或造成 crash。
用例yymodel
jsonmodel
mantle
mjextension
json 屬性是 numbermodel 屬性是 nsstring
✅ nsstring
�� nsnumber
✅ nsstring
⚠️ model nil
✅ nsstring
json 屬性是 string "100"model 屬性是 int
✅ 100
�� crash
�� crash
⚠️ model nil
✅ 100
json 屬性是 string "2009-04-02t03:35:22z"model 屬性是 nsdate
✅ nsdate
�� nsstring
�� nsdate
⚠️ model nil
�� nsstring
json 屬性是 stringmodel 屬性是 nsvalue
✅ nil
�� nsstring
�� crash
⚠️ model nil
�� nsstring
yymodel 和 mantle 都會進行物件型別檢查，避免將錯誤的物件型別賦值到屬性，以避免潛在的 crash 問題。不同的是 yymodel 會嘗試自動轉換，轉換失敗時留空；而 mantle 遇到型別不匹配時，直接把錯誤向上返回，從而終止了整個轉換過程。
mjextension 會對部分物件進行自動轉換（比如 nsstring 和 nsnumber 之間的轉換），但當自動轉換不能完成時，它會直接把 json 物件賦值給型別不匹配的 model 屬性。這樣的結果會導致稍後 model 在使用時，造成潛在的 crash 風險。
功能yymodel
jsonmodel
mantle
mjextension
相同屬性名自動對映✅��
✅��✅自定義屬性轉換方式��✅
��✅��nscoding✅��
✅✅✅hash/equal✅��
✅✅��coredata��✅
����✅
就功能來說，mantle 的可定製性最高，功能相對比較豐富。
yymodel、jsonmodel、mjextension 使用比較簡單，但功能相對 mantle 稍弱。
mantle 和 jsonmodel 都需要 model 繼承自某個基類，靈活性稍差，但功能豐富。
yymodel、mjextension 都是採用 category 方式為實現的功能，比較靈活，無侵入。但注意 mjextension 為 nsobject/nsstring 新增了大量沒有字首的方法，且方法命名比較通用，極易和乙個工程內的其他類造成衝突。
如果需要乙個穩定、功能強大的 model 框架，mantle 是最佳選擇，它唯一的缺點就是效能比較差。如果對功能要求並不多，但對效能有更高要求時，可以試試我的 yymodel。
jsonmodel 由於沒有型別檢測，可能會產生潛在的問題，這裡不推薦使用。mjextension 也缺乏某些必要的型別檢測，同時會帶來大量 category 命名汙染，這裡也不推薦使用。
swift 相關的幾個庫效能都比較差，所以非 swift 專案不推薦使用。
1. 快取model json 轉換過程中需要很多類的元資料，如果資料足夠小，則全部快取到記憶體中。
2. 查表當遇到多項選擇的條件時，要盡量使用查表法實現，比如 switch/case，c array，如果查表條件是物件，則可以用 nsdictionary 來實現。
3. 避免 kvckey-value coding 使用起來非常方便，但效能上要差於直接呼叫 getter/setter，所以如果能避免 kvc 而用 getter/setter 代替，效能會有較大提公升。
4. 避免 getter/setter 呼叫如果能直接訪問 ivar，則盡量使用 ivar 而不要使用 getter/setter 這樣也能節省一部分開銷。
5. 避免多餘的記憶體管理方法在 arc 條件下，預設宣告的物件是 __strong 型別的，賦值時有可能會產生 retain/release 呼叫，如果乙個變數在其生命週期內不會被釋放，則使用 __unsafe_unretained 會節省很大的開銷。
訪問具有 __weak 屬性的變數時，實際上會呼叫 objc_loadweak() 和 objc_storeweak() 來完成，這也會帶來很大的開銷，所以要避免使用 __weak 屬性。
建立和使用物件時，要盡量避免物件進入 autoreleasepool，以避免額外的資源開銷。
7. 盡量用純 c 函式、內聯函式使用純 c 函式可以避免 objc 的訊息傳送帶來的開銷。如果 c 函式比較小，使用 inline 可以避免一部分壓棧彈棧等函式呼叫的開銷。
8. 減少遍歷的迴圈次數在 json 和 model 轉換前，model 的屬性個數和 json 的屬性個數都是已知的，這時選擇數量較少的那一方進行遍歷，會節省很多時間。
iOS JSON 模型轉換庫評測
ios 開發中總會用到各種 json 模型轉換庫，這篇文章將會對常見的幾個開源庫進行一下評測。評測的內容主要集中在效能 功能 容錯性這幾個方面。manually 手動進行 json model 轉換，不用任何開源庫，可以進行高效 自由的轉換，但手寫 非常繁瑣，而且容易出錯。yymodel 我造的乙個...
iOS json格式轉換
nsstring str nil 字串 nsmutablestring string nsmutablestring alloc init str string jsonstring nslog str1 nsstring stringwithstring str 陣列 nsarray array ...
iOS JSON字典轉模型model
ios開發中，經常會用到字典轉模型，咱們平常常用的是mjexstend框架，該框架功能完善，但是在咱們用的時候基本上只是在資料解析的時候會用到json字典轉模型，僅此乙個功能，你們龐大的一套框架，是不是有些浪費啦，所以咱們自己寫乙個小的分類，運用一點點知識點就可以搞定，下面直接上 該分類有三個功能 ...