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程序也运行起来了,工具显示效果如下:
红色的柱子表示内存泄露了。怎么通过这个工具看到在哪泄露了呢?
![技术分享](https://images0.cnblogs.com/blog2015/554962/201506/281224136276922.png)
这时候右下角的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一次,这时候内存泄露的具体代码找到了,下面的红色框框里指定了那个方法出现了内存泄露。
![技术分享](https://images0.cnblogs.com/blog2015/554962/201506/281316177209325.png)
![技术分享](https://images0.cnblogs.com/blog2015/554962/201506/281321006277331.png)
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 阅读(246) 评论(0) 编辑 收藏 举报