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,如果都不是，那就不是我已知的錯誤了。