ios编译警告

① Xcode编译警告

你可以在otherlink 中加入 -Wl,-no_compact_unwind 去掉该警告，
根据苹果的解释，这个是由于某些地方 c/c++/oc/oc++混用会造成编译警告。一般没有什么伤害。

② iOS 编译报错怎么办

1.编译iPad真机时,选择了 Architetures:Standard(armv6) BaseSDK:iPhoneDevice3.2 TargetDeviceFamily:iPad.

若编译出现如下错误:

Command /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 failed with exit code 1

则修改 GCC4.2CodeGeneral区域中的ComplieForThumb为非选中.

已经有了开发者证书及私钥后,可直接在越狱的手机上调试.

2. 编译链接时, "_OBJC_CLASS_$_xxx", referenced from:可能需要重新建立某个类的文件.

或者:选择项目名,在detail列表中的target列(显示为一个又圆圈),把这个文件的复选选中,或者再次选中.以把它加入到这个target里面来.

3.在sdk4.0及以上使用RegexKitLite报'captureCount' was not declared in this scope错误,是在非.m文件中使用了它的原因.

4.there is no sdk with the name or path.

从网上down的开源代码，结果运行的时候常出现这样的错，并且在deployment中没有iosdeploymenttarget选项.

尝试 Project/Edit Active Target/ 及 Set Active SDK菜单项，来回切换一下Active Configuration。

5. EXEC_BAD_ACCESS，EXC_BAD_INSTRUCTION错误，意味着这个app有内存管理的问题，一般是因为访问野指针对象造成的。

一个和内存相关的崩溃一般很难定位到源代码，因为这个恶魔可能很早就在程序中做了坏事了。假如一段有问题的代码混乱了内存结构，这样产生的蝴蝶效应可能会在之后很久才表现出来，并且总在不同的地方。所以，若有指针类型出现了不可能的变化，很可能就是因为内存结构被野指针调用混乱了。

修复一些警告后，可能就能预防一些内存错误。警告在左边靠近行号的黄色三角指出一个编译警告，你点击那个黄色的三角形，xcode可能会弹出一个“Fix-it”的建议。

EXC_BAD_ACCESS崩溃不像SIGABRT，将不会得到很明朗的错误消息。然而可以使用一个让人看到曙光的调试工具：Zombies！死亡对象工具。打开这个项目的scheme editor，选择Run 选项，然后选择Diagnosics标签。勾上Enable Zombie Objects选项。当这个zombie工具被启用之后，即使这个对象被释放了，这个对象的内存也不会被清理。所以，那块内存将会被标记为“长生不死的”。假如你试着之后又去使用这块内存，这个app能够意识到你的错误操作，并且app将会抛出“messagesent to daellocated instance”错误并且终止运行。

在工程中加入NSZombieEnabled 环境变量，并设为启用，则在 EXC_BAD_ACCESS 发生时，XCode 的 Console 会打印出问题描述中，设置方法：双击Executables 下的 可执行模组,在弹出窗口中，Variables to be set in the environment，添加 NSZombieEnabled，并设定为 YES，点击选中复选框启用此变量。

可以再加入 MallocStackLogging 来启用malloc记录，以获得更多的提示来帮助定位问题。

在gdb窗口输入 (格式: shell malloc_history <id> <address>) shellmalloc_history1436 0x5f7fcf0, 也可以在终端中去运行 就要去掉以上的shell 指令 如 malloc_history <id> <address>

应该仅当需要调试内存时,才设置上述环境变量。

注意一点：不应该一直启用zombie objects。因为这个工具将永远不会释放内存，只是简单标记一下这个内存是不死的，你最终将会在某个时候耗尽所有的内存，因为所有分配过的内存都不会得到重用。因此应该在排查内存相关的错误的时候才开启zombie objects，其他时候应该关闭它。

在xcode4中，To edit environment variables, go to Menu Proct / Edit Scheme…, select the desired configuration (you probably want 'Run') from the left sidebar first and then click on the Arguments tab. Environment variables are configurable there.

6.运行一个IPhone程序时，弹出窗口说“程序运行失败，预置描述文件已过期” 。 解决办法是，在Xcode中， window-> Orgnazier -> 你的iphone －>删除带有红*的该程序之前的Profile 。 然后从Xcode运行该程序.

7.真机编译时报 Code Sign error: The identity doesn't match any valid certificate/private key pair in the default keychain

修改工程和Targets的get infouild 中的code signing identity为空

8.调试打印

CFShow(coreFoundationThingy) will print out a description of coreFoundationThingy to the console. Output looks something like: {value = w:1186.000000 h:687.000000 type = kAXValueCGSizeType}

If NSLog() is printing something out as an NSCFType, try CFShow().

9. 编译时报 Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang failed with exit code 1，修改C/C++ Compiler Version为gcc4.2

10.this class is not key value coding-compliant for the key viewController

可能在创建了一个基于view的工程，而后把生成的viewcontroller删除了，但是在.xib中还有对它的引用，在IB中直接用delete键删除掉它就行了。

11.这台电脑上已经存在一个名为“embedded.mobileprovision”的预置文件，您是否要替换么？

http://blog.sina.com.cn/s/blog_6907b67f0100o2vw.html

12.真机调试时报failed to upload *.app

http://hi..com/%CB%E6%B7%E7_1989/blog/item/9649f49f805f05aec8eaf466.html

http://www.shouyanwang.org/thread-462-1-1.html

13.记的release时，先置delegate为nil。

一个节点不应该保留任何对不属于它的节点的引用。

14.模拟器

将xcode升级到4.3.1以后发现,ipad的模拟器，没有Home键了。Command+Shift+H就可以实现类似点击Home键的效果了。

③ ios 警告itms-90473 怎么解决

网页链接 希望这个地址能够帮助到你.你把主项目和子项目的build的版本号设置成一样的就可以了.我亲自测试过,ok的

④ ios开发 为什么会出现内存警告

好的应用应该在系统内存警告情况下释放一些可以重新创建的资源。在iOS中我们可以在应用程序委托对象、视图控制器以及其它类中获得系统内存警告消息。
1、应用程序委托对象
在应用程序委托对象中接收内存警告消息，需要重写:方法。AppDelegate的代码片段：
- (void):(UIApplication *)application
{
NSLog(@”AppDelegate中调用:”);
}
2、视图控制器
在视图控制器中接收内存警告消息，需要重写didReceiveMemoryWarning方法。ViewController的代码片段：
- (void)didReceiveMemoryWarning
{
NSLog(@”ViewController中didReceiveMemoryWarning调用”);
[super didReceiveMemoryWarning];
//释放成员变量
[_listTeams release];}

注意释放资源代码应该放在[super didReceiveMemoryWarning]语句下面。
3、其它类
在其它类中可以使用通知，在内存警告时候iOS系统会发出 通知，凡是在通知中心注册了通知的类都会接收到内存警告通知。 ViewController的代码片段：
- (void)viewDidLoa
{
[super viewDidLoad];
NSBundle *bundle = [NSBundle mainBundle];
NSString *plistPath = [bundle pathForResource:@"team"
ofType:@"plist"];
//获取属性列表文件中的全部数据
NSArray *array = [[NSArray alloc] initWithContentsOfFile:plistPath];
self.listTeams = array;
[array release];
//接收内存警告通知，调用handleMemoryWarning方法处理
NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
[center addObserver:self
selector:@selector(handleMemoryWarning)
name:
object:nil];
}
//处理内存警告
-(void) handleMemoryWarning
{
NSLog(@”ViewController中handleMemoryWarning调用“);
}
我们在viewDidLoad方法中注册消 息，接收到报警信息调用handleMemoryWarning方法。这些代码完全可以写在其它类中，在ViewController中重写 didReceiveMemoryWarning方法就可以了，本例这是示意性介绍一下 报警消息。
内存警告在设备上出现并不是经常的，一般我们没有办法模拟，但模拟器上有一个功能可以模拟内存警告，启动模拟器，选择模拟器菜单硬件→模拟内存警告，这个时候我们会在输出窗口中看到内存警告发生了。
2012-11-06 16:49:16.419 RespondMemoryWarningSample[38236:c07] Received memory warning.
2012-11-06 16:49:16.422 RespondMemoryWarningSample[38236:c07] AppDelegate中调用:
2012-11-06 16:49:16.422 RespondMemoryWarningSample[38236:c07] ViewController中handleMemoryWarning调用
2012-11-06 16:49:16.423 RespondMemoryWarningSample[38236:c07] ViewController中didReceiveMemoryWarning调用
多看多做多练习是学习语言必须经历的过程，学习不是一朝一夕的事情，只有恒之以衡的坚持才能带来成功。达内希望以上的ios教程能给大家带来帮助。

⑤ IOS 怎样去掉删除.h 和.m文件的警告

在用xcode4开发的时候，删除不用的文件后， 编译的时候会有missing file的警告，原因是由于SVN或git造成的。
有几种方法可以解决。
1.命令行进入missing file目录，然后运行
svn delete nameOfMissingFile

或
git rm nameOfMissingFile

2.删除隐藏的.svn文件
命令行运行
defaults write com.apple.finder AppleShowAllFiles TRUE


killall Finder

开启显示隐藏文件，然后到工程目录下删除.svn文件，然后再恢复
defaults write com.apple.finder AppleShowAllFiles FALSE


killall Finder

3.进入工程目录，运行下面命令删除隐藏文件
find . -name .svn -exec rm -rf { } \;

报警是因为，先在文件夹中删除工程中引用的文件，工程引用的路径还存在，删掉也还会报错，怀疑是bug

⑥ iOS开发如何去掉某种类型的警告

最直接、最一劳永逸、最安全的方式，直接找到警告的那段代码，改为不警告。这个方式最安全。

2. 使用编译器提供的宏来操作。这个方式在我们的工程中会大量的看到：

这种方式的问题,同第一个差不多,也是要修改源代码的实现的,对于第三方,我们肯定是不想改动它的,尤其是一些更新很频繁的第三方,一般警告出现后不久,作者就更新了,我们在此做这样的操作,就显得浪费了.并且在 添加arm64支持的时候,一下出现几百个某种类型的警告,改起来也是相当费时费力的啊!

4.关闭工程中指定 类型的警告。

还有关于我们使用cocoapod引入的第三方,我们可以在podfile文件中 增加一句inhibit_all_warnings! 来要pod的工程不显示任何警告，例如：

还有就是,上面的方法也适合其它类型的警告!!!

⑦ iOS开发中，关于什么时候使用点语法的解答

delegate、notification和KVO的功能比较类似，那么在实际的编程中，如何选择这些方式呢? 在开发ios应用的时候，我们会经常遇到一个常见的问题：在不过分耦合的前提下，controllers间怎么进行通信。在IOS应用不断的出现三种模式来实现这种通信： 1.委托delegation; 2.通知中心Notification Center; 3.键值观察key value observing，KVO 因此，那为什么我们需要这些模式以及什么时候用它以及什么时候不用它。 下面完全根据我的开发经验来讨论这三中模式。我将讨论为什么我觉得某种模式要好于另外一种模式以及为什么我觉得在一定的环境下某中模式比较好。我给出的这 些原因并不是圣经，而仅仅是个人观点。如果你有什么不同的观点或者还可以进行补充的地方，可以联系我，一起讨论。 上面的三种模式是什么? 三种模式都是一个对象传递事件给另外一个对象，并且不要他们有耦合。三种模式都是对象来通知某个事件发生了的方法，或者更准确的说，是允许其他的对象收到 这种事件的方法。这对于一个对象来说，是非常普通而且必须做的任务，因为没有通信，controllers将不能整合到整个应用中。controller 的另外一个目的是尽可能的自包含。我们希望controllers以自己的方式存在，在controllers层面上不能与其他的controllers 进行耦合。Controllers能够穿件其他的controllers而且他们之间可以自由通信，但是我们不希望controller又回接到创建自己 的controller。如果我们耦合了他们，那么我们将不能复用他们，以及完全失去对应用中一个独立的组件的控制。 这三种模式给controllers(也可以是其他的对象)提供通信的方法。下面将描述如何在ios应用中使用这些模式，同样需要注意的他们在其他的地方也会用到，并且确实是存在。 delegation 当我们第一次编写ios应用时，我们注意到不断的在使用“delegate”，并且贯穿于整个SDK。delegation模式不是IOS特有的模式，而是依赖与你过去拥有的编程背景。针对它的优势以及为什么经常使用到，这种模式可能不是很明显的。 delegation的基本特征是，一个controller定义了一个协议(即一系列的方法定义)。该协议描述了一个delegate对象为了能够响应 一个controller的事件而必须做的事情。协议就是delegator说，“如果你想作为我的delegate，那么你就必须实现这些方法”。实现 这些方法就是允许controller在它的delegate能够调用这些方法，而它的delegate知道什么时候调用哪种方法。delegate可以 是任何一种对象类型，因此controller不会与某种对象进行耦合，但是当该对象尝试告诉委托事情时，该对象能确定delegate将响应。 delegate的优势： 1.非常严格的语法。所有将听到的事件必须是在delegate协议中有清晰的定义。 2.如果delegate中的一个方法没有实现那么就会出现编译警告/错误 3.协议必须在controller的作用域范围内定义 4.在一个应用中的控制流程是可跟踪的并且是可识别的; 5.在一个控制器中可以定义定义多个不同的协议，每个协议有不同的delegates 6.没有第三方对象要求保持/监视通信过程。 7.能够接收调用的协议方法的返回值。这意味着delegate能够提供反馈信息给controller 缺点： 1.需要定义很多代码：1.协议定义;2.controller的delegate属性;3.在delegate本身中实现delegate方法定义 2.在释放代理对象时，需要小心的将delegate改为nil。一旦设定失败，那么调用释放对象的方法将会出现内存crash 3.在一个controller中有多个delegate对象，并且delegate是遵守同一个协议，但还是很难告诉多个对象同一个事件，不过有可能。 notification 在IOS应用开发中有一个”Notification Center“的概念。它是一个单例对象，允许当事件发生时通知一些对象。它允许我们在低程度耦合的情况下，满足控制器与一个任意的对象进行通信的目的。 这种模式的基本特征是为了让其他的对象能够接收到在该controller中发生某种事件而产生的消息，controller用一个key(通知名称)。 这样对于controller来说是匿名的，其他的使用同样的key来注册了该通知的对象(即观察者)能够对通知的事件作出反应。 优势： 1.不需要编写多少代码，实现比较简单; 2.对于一个发出的通知，多个对象能够做出反应，即1对多的方式实现简单 3.controller能够传递context对象(dictionary)，context对象携带了关于发送通知的自定义的信息 缺点： 1.在编译期不会检查通知是否能够被观察者正确的处理; 2.在释放注册的对象时，需要在通知中心取消注册; 3.在调试的时候应用的工作以及控制过程难跟踪; 4.需要第三方对喜爱那个来管理controller与观察者对象之间的联系; 5.controller和观察者需要提前知道通知名称、UserInfo dictionary keys。如果这些没有在工作区间定义，那么会出现不同步的情况; 6.通知发出后，controller不能从观察者获得任何的反馈信息。 KVO KVO是一个对象能够观察另外一个对象的属性的值，并且能够发现值的变化。前面两种模式更加适合一个controller与任何其他的对象进行通信，而 KVO更加适合任何类型的对象侦听另外一个任意对象的改变(这里也可以是controller，但一般不是controller)。这是一个对象与另外一 个对象保持同步的一种方法，即当另外一种对象的状态发生改变时，观察对象马上作出反应。它只能用来对属性作出反应，而不会用来对方法或者动作作出反应。 优点： 1.能够提供一种简单的方法实现两个对象间的同步。例如：model和view之间同步; 2.能够对非我们创建的对象，即内部对象的状态改变作出响应，而且不需要改变内部对象(SKD对象)的实现; 3.能够提供观察的属性的最新值以及先前值; 4.用key paths来观察属性，因此也可以观察嵌套对象; 5.完成了对观察对象的抽象，因为不需要额外的代码来允许观察值能够被观察 缺点： 1.我们观察的属性必须使用strings来定义。因此在编译器不会出现警告以及检查; 2.对属性重构将导致我们的观察代码不再可用; 3.复杂的“IF”语句要求对象正在观察多个值。这是因为所有的观察代码通过一个方法来指向; 4.当释放观察者时不需要移除观察者。 总结： 从上面的分析中可以看出3种设计模式都有各自的优点和缺点。其实任何一种事物都是这样，问题是如何在正确的时间正确的环境下选择正确的事物。下面就讲讲如何发挥他们各自的优势，在哪种情况下使用哪种模式。注意使用任何一种模式都没有对和错，只有更适合或者不适合。 每一种模式都给对象提供一种方法来通知一个事件给其他对象，而且前者不需要知道侦听者。在这三种模式中，我认为KVO有最清晰的使用案例，而且针对某个需 求有清晰的实用性。而另外两种模式有比较相似的用处，并且经常用来给controller间进行通信。那么我们在什么情况使用其中之一呢? 根据我开发iOS应用的经历，我发现有些过分的使用通知模式。我个人不是很喜欢使用通知中心。我发现用通知中心很难把握应用的执行流程。UserInfo dictionaries的keys到处传递导致失去了同步，而且在公共空间需要定义太多的常量。对于一个工作于现有的项目的开发者来说，如果过分的使用 通知中心，那么很难理解应用的流程。 我觉得使用命名规则好的协议和协议方法定义对于清晰的理解controllers间的通信是很容易的。努力的定义这些协议方法将增强代码的可读性，以及更 好的跟踪你的app。代理协议发生改变以及实现都可通过编译器检查出来，如果没有将会在开发的过程中至少会出现crash，而不仅仅是让一些事情异常工 作。甚至在同一事件通知多控制器的场景中，只要你的应用在controller层次有着良好的结构，消息将在该层次上传递。该层次能够向后传递直至让所有 需要知道事件的controllers都知道。 当然会有delegation模式不适合的例外情况出现，而且notification可能更加有效。例如：应用中所有的controller需要知道一个事件。然而这些类型的场景很少出现。另外一个例子是当你建立了一个架构而且需要通知该事件给正在运行中应用。 根据经验，如果是属性层的时间，不管是在不需要编程的对象还是在紧紧绑定一个view对象的model对象，我只使用观察。对于其他的事件，我都会使用 delegate模式。如果因为某种原因我不能使用delegate，首先我将估计我的app架构是否出现了严重的错误。如果没有错误，然后才使用 notification。

⑧ IOS开发 警告

delegate的声明应该是类似于
@property (nonautomatic, assign) id<xxxDelegate> delegate;
你检查一下你的代码有没有把assign写成retain或strong，然后检查一下 delegate是不是写成了
*delegate,如果都不是，那就不是我已知的错误了。