问题的出现

iOS 项目中使用了MJRefresh,在 xcode6中使用 objc_msgSend 会报错Too many arguments to function call…

解决方案

在 Building Setting 下Apple LLVM 6.1 – Preprogressing下的Enable Strict Checking of objc_msgSend Calls设置成No

吐槽

苹果每次升级 xcode/iOS 都会出现一堆不兼容,然后你又可以通过设置某个值再去兼容,简直是 x 裤子放 y,像 arc 的编译参数之类的,自动判断一下啊… 恩 吐槽好了就舒服了

  1. BBUncrustifyPlugin
    https://github.com/benoitsan/BBUncrustifyPlugin-Xcode
    一个代码格式化插件,从eclipse的java一键格式化过来,发现xcode代码格式化真蛋疼,还好发现这个插件
  2. VVDocumenter
    https://github.com/onevcat/VVDocumenter-Xcode
    一个生成规范化注释的插件,java里习惯用javadoc的形式注释方法,xcode下也有,用"///"触发
  3. FuzzyAutocomplete
    https://github.com/chendo/FuzzyAutocompletePlugin
    都知道sublime的模糊匹配很好用,但是xcode默认是从头匹配,有这个插件就好了
  4. ColorSense
    https://github.com/omz/ColorSense-for-Xcode
    有这个插件就可以可视化的看到颜色具体是什么样子的了
  5. KSImageNamed
    https://github.com/ksuther/KSImageNamed-Xcode
    有这个插件,直接输入"[UIImage imageNamed:",就可以直接选图片了,还可以看见图片的预览

 

以上插件通用安装方式,git clone,build,有些是会自己复制到安装目录,如果没有的话,请将编译好的文件拷贝到~/Library/Application Support/Developer/Shared/Xcode/Plug-ins下,没有可以新建一个,装完插件记得重启xcode

在做quick-x的应用程序时,自建了一个Resources的文件夹,然后加入到Xcode中

真机调试时报错"Could not inspect the application package"

由于添加之前跑过一次没问题,所以怀疑是文件夹名字"Resources"的问题

于是把"Resources"重命名成"AppRes",并重新添加,然后Product->Clean重新运行

没想到还是报这个错,google之,发现这样并不能深度Clean

需要按住Mac上Option,这样Product->Clean会变成Product->Clean Build Folder

再次运行后,问题消失

 

quick-cocos2d-x 2.2.1

xcode 5.0.2

os x 10.9.1

 

工程上线后,总会有几个崩溃,有的是操作问题,有的是程序bug,下面就是如何通过崩溃日志找到程序bug的过程

  1. 先弄到设备上APP的crash日志
    参照(这篇日志),我的日志是从报错平台上得到的,这步跳过
  2. 打开报错日志(这里只保留了有用信息,不过你拿得到报错机器的话…直接看8.)
  3. 分析
    gcld开头的应该就是引起崩溃的地方,不过完全看不懂
    a) 创建一个crash文件夹
    b) 把报错日志重命名成app.crash 放进crash文件夹
    c) 问开发要xcarchive,从xcarchive里找到app.app和app.app.dSYM 放进crash文件夹
    d) 复制/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash 放进crash文件夹
    e) 打开Terminal

    f) 我们看到了"got symbolicator for /Users/superyyl/Desktop/crash/app.app/app, base address 4000"这种日志
  4. 打开gcld-kuaiyong-symbol.crash文件
    发现Thread 0的地方已经变样子了

  5. 找到C代码​
    打开LuaCocos2d.cpp,找到21969行,看到C代码

  6. 根据日志判断崩溃原因
    错误类型是SIGSEGV,从signal.h文件中得知
    ​​

  7. 分析用户的行为日志
    such as:最近收发的数据包,最近调用的接口,进入的场景名
    来跟踪lua代码可能出错的地方

  8. 既然拿得到设备…
    a) 找开发要到当时版本的xcarchive,导入到xcode中
    b) 连接设备
    c) 从xcode里的Organizer-Devices里找到Device Logs
    d) 找到崩溃的日志,左键单击
    e) 开始的2秒,崩溃日志还是内存地址,但是2秒解析过后,就能找到具体行了

  9. 最后
    这个方法能找到大部分的报错原因,但有时候拿到crash并非完全有效,比如你可能拿到大量例子中的"___lldb_unnamed_function6269"就无从下手

附录1:

Apple Hardware Model

附录2: 

signal.h defines