扒虫篇-Bug日志 Ⅰ

总有一些报错是你不愿意看见的,可是还是应该昂首挺胸去面对吧!

很多莫名其妙的Bug都是自己隐蔽的设置引起的,没有把整个流程理一遍是无法发现的。没有莫名其妙的Bug,只有未理清的思路。(持续更新中.......)**


1.缺少系统类库的支撑而报的 64位模拟器不兼容

扒虫篇-Bug日志 Ⅰ_第1张图片
Snip20160928_1.png

之前在集成调试 AsReader的时候,遇到的bug,是一家日本企业生产的产品,官方文档比较简单而且还不写清楚,表面上看是报的不兼容 64位模拟器的错误,我用真机调试还是报相同的错误。最后发现少了系统的类库

解决方法:导入ExternalAccessory.FrameWork,

 Communicate with accessories connected to a device by the Apple Lightning connector, or connected wirelessly through Bluetooth.
 与由苹果闪电连接器连接到设备,或通过蓝牙无线连接配件进行通信。

添加后错误少了依然有报错:

扒虫篇-Bug日志 Ⅰ_第2张图片
Snip20160929_1.png

“undefined symbol: __gxx_personality_v0” 是比较常见的一种报错,是因为在linux下编译C++程序,如果使用gcc命令进行编译,gcc无法连接到c++库,所以会出现错误。

解决方法:导入libstdc++.dylib 即可解决。

2.模拟器运行时出现如下提示:

扒虫篇-Bug日志 Ⅰ_第3张图片
Snip20161018_1.png

解决方法:如果 Clean 重新运行;关闭项目,重新打开,Clean重新运行都不解决问题的话,试着 重置一下模拟器吧,那会解决这个问题。

3.Xcode 8 项目在 Xcode7上的模拟器运行时出现如下提示:

扒虫篇-Bug日志 Ⅰ_第4张图片
Snip20161010_2.png

解决方法:在 Main.storyboard 的右边的编辑区设置如下即可:

扒虫篇-Bug日志 Ⅰ_第5张图片
Snip20161011_3.png

4.Xcode 8适配

XIB和Storeboard适配
在Xcode8之前,创建一个XIB或SB文件,都是一个600*600的方块XIB文件。在Xcode8之后,创建的XIB文件默认是6s尺寸的大小。
但是Xcode8打开之前旧项目的XIB或SB文件时,会弹出下面的弹框, 这时候一般直接选择Choose Device即可。

扒虫篇-Bug日志 Ⅰ_第6张图片
1477274596935431.png

Choose an initial device view
但是这样有个问题,如果Xcode8打开过这个XIB文件,并选择Choose Device之后。其他的Xcode8以下版本的编译器,将无法再打开这个文件,会报以下错误:
The document “ViewController.xib” requires Xcode 8.0 or later. This version does not support documents saved in the Xcode 8 format. Open this document with Xcode 8.0 or later.

有两种方法解决这个问题:

你同事也升级Xcode8,比较推荐这种方式,应该迎接改变。
右击XIB或SB文件 -> Open as -> Source Code,删除xml文件中下面一行字段。

1477274638709256.png

5.模拟器运行时出现如下报错

扒虫篇-Bug日志 Ⅰ_第7张图片
Snip20161028_1.png

解决方法

扒虫篇-Bug日志 Ⅰ_第8张图片
Snip20161028_2.png

6.C++语音汇编时有时会出现这个 头文件找不到的情况

Snip20161101_1.png

解决办法: 把有C语音的地方 .m 改为 .mm 即可。

7. 大华视屏监控App,由Xcode7 迁移到 Xcode 8 上出现的Bug

Snip20161031_1.png

这个Bug可把我恶心坏了,弄了整整一天,心力交瘁,字面意思上看是 一个 .a 不支持 arm64
我们查看下静态库所支持的架构,打开终端输入查看命令lipo - info xxx.a , (输入.a 的完整路径)结果如下:


扒虫篇-Bug日志 Ⅰ_第9张图片

这样的就可以看到 .a 所支持的架构了,我查出的报错的 .a 根本没问题,而且人家原本的Dome 是可以跑起来的。最后我联想到了工程设置可能是问题的所在,经过反复的比对,最后发现了坑爹的Bug,所在。

扒虫篇-Bug日志 Ⅰ_第10张图片
Snip20161101_6.png

解决办法: Enable Testability 设置为NO,工程新建的时候默认是设置为YES的,就是这个恶心的地方导致的Bug。
这个设置跟单元测试有关,不知道为啥造成了这个Bug。

8.使用 AFNetworking 3.0上传图片出现超时,无法上传等问题

AFHTTPSessionManager *manager = [AFHTTPSessionManager manager]; //下面这句话不写会造成接受的信息nil,造成崩溃 manager.responseSerializer= [AFHTTPResponseSerializer serializer]; manager.responseSerializer.acceptableContentTypes = [NSSet setWithObjects:@"text/html", @"text/plain", @"application/json",nil];

不知道什么情况,自己的浏览器打开一个测试的 链接很慢很慢不出结果,但是打开其他的网页却很快,自己的程序测试接口的时候也是很慢,慢道最后报请求超时,一直以为是服务器那边的问题,以为服务器连不上,自己的POST方法不对,最后发现Andrio那边的速度飞快,很是疑惑。

解决办法
重启电脑,再次打开浏览器 输入测试链接,反应飞快,自己的程序跑起来也是很快,AFNetworking 3.0上传图片 也没有任何问题,Mac系统的问题造成的吗????

9.使用 AFNetworking 3.0上传图片时由于 fileName没有格式后缀造成的一系列debug 过程

使用 AFNetworking 3.0上传图片时,在成功的回调中返回了 responseObject,但是Json化字典后为 nil :
NSDictionary* dics = [NSJSONSerialization JSONObjectWithData:responseObject options:NSJSONReadingAllowFragments error:nil];
但是可以看到 responseObject 是有长度的 二进制流,证明是有返回的,只是不是 Json格式的罢了。
于是转化成字符串打印下:
NSString *jsonStr = [[NSString alloc]initWithData:responseObject encoding:NSUTF8StringEncoding];
发现是 HTML 样式的 字符串,在排查出问题后 发现是由于:

fileName:@"submit"没有设置格式造成的

PS UTF-8有效率的空间使用(仅就西方语言来讲),以及不需要操心字节顺序问题使得 UTF-8 成为存储和交流 Unicode 文本方面的最佳编码。它也已经是文件格式、网络协议以及 Web API 领域里事实上的标准了。

NSString 与 Unicode

解决方法 fileName:@"submit.jpg" 即可 。

10.一个真机测试中出现的讨厌错误提示

扒虫篇-Bug日志 Ⅰ_第11张图片
Snip20161123_1.png

process launch failed 是因为工程证书配置文件设置出错,或者找不到对应的配置文件造成的报错

扒虫篇-Bug日志 Ⅰ_第12张图片
Snip20161123_2.png

解决办法: 修改对应的设置即可。

你可能感兴趣的:(扒虫篇-Bug日志 Ⅰ)