問題：崩潰是在獲取數(shù)據(jù)的DATA（Hessian框架里面），我第一反應肯定不是第三方的問題，是服務器的問題
實際情況：
在請求同樣的接口的時候，傳參3個成功并展示數(shù)據(jù)在tableView上，最后一個參數(shù)有14個，崩潰了
想法：1.多半是這個參數(shù)反參的問題，我在公司內部的網(wǎng)絡接口的測試界面（PC端）測試這個參數(shù)請求，但是能展示所有的數(shù)據(jù)（注：公司的后臺數(shù)據(jù)是使用實體寫的，每個實體有40-50條數(shù)據(jù)，很多為null，或者0，或者<>...</p>的標簽：這里是有一條是作為富文本，需要給PC端做一個H5界面使用，移動端不使用該數(shù)據(jù)）
解決方式：
1.我們先做斷點，發(fā)現(xiàn)錯誤一直停留在data部分，一步步測試，是在跳了無數(shù)次內存部分了之后蹦在了data部分，顯示是內存錯誤的常見紅BUG
1.1.查資料，發(fā)現(xiàn)是提前釋放了未知對象（我們判斷是內存野指針問題）
1.2.也就是說數(shù)據(jù)在獲取中出現(xiàn)了野指針情況
2.我們做了數(shù)據(jù)測試
2.1把服務器端該數(shù)據(jù)的參數(shù)請求做了獲取數(shù)據(jù)只有1條，測試，成功；
2.2把服務器端數(shù)據(jù)獲取改為5條，成功；
2.3 同理10條，失敗；
2.4倒數(shù)9 8 7 6 都失敗了
2.5但是在6出現(xiàn)了不同情況，data獲取到了6條數(shù)據(jù)，但是沒有展示出來，出現(xiàn)了野指針報錯
3.我們做了裸數(shù)據(jù)測試
3.1把每個實體的46條數(shù)據(jù)里面的參全部為空，iOS端不做數(shù)據(jù)展示，只打印數(shù)據(jù)包，成功
3.2測試是否因為content（標簽參）的原因，去掉后仍然失敗
4.我們推測問題是不是出在了獲取的另外的多余的數(shù)據(jù)參數(shù)空指針太多（null，服務器用MySQL，沒有參默認為null）
4.1在Hessian的iOS框架代碼部分，沒有對數(shù)據(jù)中null做處理
解決方法：
1.在服務器部分單獨寫一個類（最優(yōu)解決方式），做該請求的時候，獲取的數(shù)據(jù)參全部是我當前界面需要的參數(shù)（即展示數(shù)據(jù)部分參數(shù)與關聯(lián)界面id相關參數(shù)），這樣我請求到的數(shù)據(jù)有3個好處：
1.1數(shù)據(jù)過于臃腫的46個參數(shù)，不需要在前端來做數(shù)據(jù)清理，大大減小了前端的內存消耗
1.2由于數(shù)據(jù)清理再倒入當前視圖的dataArray，所以這樣可以減少頁面請求數(shù)據(jù)展示的總時間
1.3避開了所有的數(shù)據(jù)null，以及可能存在的未知錯誤。
2.在iOS端做數(shù)據(jù)null判斷，需要iOS端程序員和服務器端總工程師合作，對null字段進行修正判斷處理，改為空字符串，或移除該字段
2.1數(shù)據(jù)處理，雖然是走了Hessian框架的內部，但是依然是吧問題留在了前端來處理
2.2需要的架構封裝底層知識不少，主要是針對data做數(shù)據(jù)判斷循環(huán)處理過，處理后的數(shù)據(jù)包可能存在數(shù)據(jù)個數(shù)不等的情況， 甚至可能某些當前界面需要的數(shù)據(jù)為null時被置空，當然，也可以將該null參改為空字符串。
版權歸簡書jackDay所有，轉載請說明出處
文中有不足之處，敬請斧正，不勝感激，也希望和仍然使用Hessian做服務器的公司iOS員工交流
