ios 报错小节
最近运行APP，发现了这个问题，本着宁可错看，不可放过的原则，上stackoverFlow学习了一下：
链接：http://stackoverflow.com/questions/38458170/ios-10-app-if-were-in-the-real-pre-commit-handler-we-cant-actually-add-any
----- “[App] if we're in the real pre-commit handler we can't actually add any new fences due ”
翻译：
-----“[应用]如果我们在真实预提交处理我们不能添加任何新的围栏，由于CA限购”
才知道这个问题其实是xcode 编译器设置的问题，其实并不影响app使用:
"-------it comes from +[UIWindow _synchronizeDrawingAcrossProcessesOverPort:withPreCommitHandler:] via os_log API. It doesn't depend from another components/frameworks that you are using(only from UIKit) - it reproduces in clean single view application project on changing interface orientation.
This method consists from 2 parts:
adding passed precommit handler to list of handlers;
do some work, that depends on current finite state machine state.
When second part fails (looks like prohibited transition), it prints message above to error log. However, I think that this problem is not fatal: there are 2 additional assert cases in this method, that will lead to crash in debug.---"
翻译：
----它来自+ [ UIWindow _synchronizedrawingacrossprocessesoverport：withprecommithandler：]通过os_log API。它不取决于另一个组件/框架，您使用的是（从UIKit）-再现清洁单视图应用程序项目改变界面取向。
该方法由2部分组成：
并通过预提交处理程序处理程序列表；
做一些工作，这取决于当前的有限状态机状态。
当第二部分失败（看起来像被禁止的过渡）时，它将上面的消息打印到错误日志上。然而，我认为这个问题不是致命的：有2个额外的断言在这种方法的情况下，这将导致崩溃在调试
----------------------------华丽的分割线-------------------------------------
解决方法：
in your Xcode:
- Click on your active scheme name right next to the Stop button
- Click on Edit Scheme....
- in Run (Debug) select the Arguments tab
- in Environment Variables click +
- add variable: OS_ACTIVITY_MODE = disable
其实这好像是老版xcode 的，
其实点击Xcode的product就可以找到（OS_ACTIVITY_MODE是name,disable 是值）
（特别注意：标注为disable失效后，程序可能会运行失败！）
---------------
xcode 只给出 一句
linker command failed with exit code 1 好多人觉得不好下手
其实 xcode 还给了你 其他的信息。 举个栗子 ，如下:
ld: warning: ignoring file /Volumes/Xcode/Xcode.app/Contents/Developer/Library/Frameworks/SenTestingKit.framework/SenTestingKit, missing required architecture armv7 in file
ld: duplicate symbol _OBJC_METACLASS_$_MMApiRegister in /Users/wangbin/Desktop/00_ios/hezi_ios08/WXSDK/libWeChatSDK.a(WeChatRegister.o) and /Users/wangbin/Desktop/00_ios/hezi_ios08/WXSDK/libWeChatSDK.a(WeChatRegister.o) for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
主要解决思路如下:
* 这个就需要 定位 这个 的 上面的内容 missing required architecture armv7 in file 中文意思 是 少了 architecture armv7 。也就是说 arm 7 没有 添加 或者 是 新引入的静态库 出了问题。 这样一来 不就 很好解决了。
* 还有的是因为 文件 没有加载全 ， Build settings->Linking->Other Linker Flags，将此属性修改成-all_load
* 有时候 Other Linker Flags下的配置 写的与工程里面的代码 或者 第三方库 冲突了 也会引起这种问题。 将Other Linker Flags下 不必要的配置删除（多人工程容易出现这种情况）
* 工程中文件名重复了 也会出现同样的错误 看看是不是有新添加的文件跟之前文件同名
* 在将文件引入工程时 由于粗心 没有勾选 Copy items if neded 这个选项.
* ”Build Settings”->”Enable Bitcode”设置为NO 因为有些SDK不支持Bitcode
* 引入文件时引入的是.m文件 在引用的时候 可能写的是#import "XXXXX.m" ，如果是改为#import "XXXXX.h"
* .a用SVN没有下载下来，用SVN的低版本容易出这个错误
* 有时候在模拟器上运行报这种类似的错误 ，是因为你加入的这个.a文件不支持模拟器，只有真机运行才可以，到官网上下载一个更全面的替换掉就可以啦
* 在post -> Build Settings -> Architectures -> Build Active Architecture Only 把Yes改成No
* 错误信息中出现了某个类的名字，去原文件中看看#import了哪些第三方库，把这些库挨个注释排除，找到出错的那个库，然后按照官方提供的步骤重新添加一遍。
* SVN或git忽略了某些文件，如.o 等文件没能update下来，查看.o文件可能是红色的，可以重新添加或者修改SVN(git)的忽略设置
* 把.a文件删除再重新拖到项目中解决问题
* 可能重复添加了文件建议删除后重新添加
* 一个类中自定义创建的父类没有implementation部分，在此基础上继承的子类就报这样的错误了
* 在不同的地方命名了相同的静态变量，不过这个真机调试不报错，模拟器运行的时候报错了
* 将旧版本xcode环境下 开发的工程移动到最新xcode 有时 可能造成不兼容 而 引发问题，需要在终端下 将 xcode7 的 工程里 移除 一个 文件，具体 记不清了。 有遇到的 直接 搜索 关键字 就会 出来 解决方案
虽然造成这种问题 不好定位，但是 还是有迹可循的。 自己的工程自己最清楚 ，自己 改动了 哪里 后 出现的这种情况 ，就重点排查 最近的改动 ，一准跑不了，哈哈
这篇文章 写得 也很好 链接 如下 http://blog.csdn.net/u012847940/article/details/51333285
===========================
iOS 5.0之后apple引入了Xcode编译器特性ARC（Automatic Reference Counting，自动引用计数）来帮助开发者管理内存，但为了追求app的高性能与减少安装包大小，工作中很多时候需要我们手动管理内存。再牛的开发者也不能保证自己写的code 100%没有内存泄露，出现内存泄露不可怕，可怕的是我们时间与精力花了大把，但内存泄露依旧没解决,即影响了工作效率也影响自己的心情。
下面就讲解xcode中的内存调试神器---Instruments Leak ，不管是ios开发菜鸟，还是有经验的开发者，使用Instruments Leak调试内存泄露是必备技能之一。
废话少说，下面开始摊大饼了！！!
step1:
创建一个基于ARC的测试demo,部分测试代码如下：
以上几行代码作为app代理入口method，IOS开发者应该是最熟悉不过了，由于创建的是手动管理内存工程，内存泄露的code line一眼就可以定位。
step2：
使用Leaks开始动态分析，点击XCode的Product菜单Profile启动Instruments：
点击Profile Button编译，呵呵，报错了，如果你遇到这种情况也不要紧张，先看下报错信息:
MyViewController与MyNavigationController是我在.pch预编译文件中定义的宏：
为什么正常编译就没问题，在Profile 中就编译通不过了，其实这里并不是你的代码写的有问题，问题出在Profile的一个编译选项上：
打开工程的Edit Scheme选项
选择Profile，将Build Configuration设置为Debug,这样在.pch文件中，#ifdef DEBUG 编译条件下定义的宏就生效 了。
再次选择Profile building，OK， Success ！！！
step3:
进入Instruments主页面，选择Leak Logo
step4:
这时Demo程序也运行起来了,工具显示效果如下：
红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?
这时候右下角的Call Tree的可选项可以选了。选中Invert Call Tree 和Hide System Libraries,显示如下：
看到这里，你最想知道的应该是项目中哪里的code内存泄漏了，ok, 下面我们就来定位内存泄漏的code line .
step5:
看上图中红色框中的Symbol Name 列，如果你猜想0xedc00与0xedbda是内存地址，那么已经很接近正确答案了，可是这东西对我来说有卵用。其实玄机就隐藏在这里，Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，关于dSYM更多的细节，我将在后面的blog中说明。回到上面的问题，显示0xedc00与0xedbda是因为我们的工程build settings 的问题，没有生成dSYM 文件，也就无法解析debug symbols。下面我们就来正确设置dSYM选项：
设置好之后，重新 profile build一次，这时候内存泄露的具体代码找到了，下面的红色框框里指定了那个方法出现了内存泄露。
step6:
解决内存泄漏问题，将创建的vc对象release掉就OK了，再用Instruments Leak工具分析看看，这时候再怎么操作，都没有内存泄露了。表明内存泄露被堵住了。
附上《Instruments 用户指南》有兴趣的同学可以研究一下Instruments中其他工具的用法。
==================
有个同事问我，他工程运行时就会有如下提示，但是不影响功能：You've implemented -[<UIApplicationDelegate> application:didReceiveRemoteNotification:fetchCompletionHandler:], but you still need to add "remote-notification" to the list of your supported UIBackgroundModes in your Info.plist.
该如何解决，如下：
capablilties->background modes->remote notifications
==================
最近工程遇到了这个，
The request was denied by service delegate (SBMainWorkspace) for reason: Security ("Entitlement "com.apple.frontboard.debugapplications" required to launch applications for debugging").
解决方案：重启模拟器
posted on 2015-12-10 22:06 🌞Bob 阅读(247) 评论(0) 编辑 收藏 举报
