问题：崩溃是在获取数据的DATA（Hessian框架里面），我第一反应肯定不是第三方的问题，是服务器的问题
实际情况：
在请求同样的接口的时候，传参3个成功并展示数据在tableView上，最后一个参数有14个，崩溃了
想法：1.多半是这个参数反参的问题，我在公司内部的网络接口的测试界面（PC端）测试这个参数请求，但是能展示所有的数据（注：公司的后台数据是使用实体写的，每个实体有40-50条数据，很多为null，或者0，或者<>...</p>的标签：这里是有一条是作为富文本，需要给PC端做一个H5界面使用，移动端不使用该数据）
解决方式：
1.我们先做断点，发现错误一直停留在data部分，一步步测试，是在跳了无数次内存部分了之后蹦在了data部分，显示是内存错误的常见红BUG
1.1.查资料，发现是提前释放了未知对象（我们判断是内存野指针问题）
1.2.也就是说数据在获取中出现了野指针情况
2.我们做了数据测试
2.1把服务器端该数据的参数请求做了获取数据只有1条，测试，成功；
2.2把服务器端数据获取改为5条，成功；
2.3 同理10条，失败；
2.4倒数9 8 7 6 都失败了
2.5但是在6出现了不同情况，data获取到了6条数据，但是没有展示出来，出现了野指针报错
3.我们做了裸数据测试
3.1把每个实体的46条数据里面的参全部为空，iOS端不做数据展示，只打印数据包，成功
3.2测试是否因为content（标签参）的原因，去掉后仍然失败
4.我们推测问题是不是出在了获取的另外的多余的数据参数空指针太多（null，服务器用MySQL，没有参默认为null）
4.1在Hessian的iOS框架代码部分，没有对数据中null做处理
解决方法：
1.在服务器部分单独写一个类（最优解决方式），做该请求的时候，获取的数据参全部是我当前界面需要的参数（即展示数据部分参数与关联界面id相关参数），这样我请求到的数据有3个好处：
1.1数据过于臃肿的46个参数，不需要在前端来做数据清理，大大减小了前端的内存消耗
1.2由于数据清理再倒入当前视图的dataArray，所以这样可以减少页面请求数据展示的总时间
1.3避开了所有的数据null，以及可能存在的未知错误。
2.在iOS端做数据null判断，需要iOS端程序员和服务器端总工程师合作，对null字段进行修正判断处理，改为空字符串，或移除该字段
2.1数据处理，虽然是走了Hessian框架的内部，但是依然是吧问题留在了前端来处理
2.2需要的架构封装底层知识不少，主要是针对data做数据判断循环处理过，处理后的数据包可能存在数据个数不等的情况， 甚至可能某些当前界面需要的数据为null时被置空，当然，也可以将该null参改为空字符串。
版权归简书jackDay所有，转载请说明出处
文中有不足之处，敬请斧正，不胜感激，也希望和仍然使用Hessian做服务器的公司iOS员工交流
