這是我的WWDC2013系列筆記中的一篇，完整的筆記列表請(qǐng)參看這篇總覽。本文僅作為個(gè)人記錄使用，也歡迎在許可協(xié)議范圍內(nèi)轉(zhuǎn)載或使用，但是還煩請(qǐng)保留原文鏈接，謝謝您的理解合作。如果您覺(jué)得本站對(duì)您能有幫助，您可以使用RSS或郵件方式訂閱本站，這樣您將能在第一時(shí)間獲取本站信息。

本文涉及到的WWDC2013 Session有

• Session 400 What's New in Xcode 5
• Session 401 Xcode Core Concepts
• Session 407 Debugging with Xcode
• Session 404 Advances in Objective-C

等Tools模塊下的內(nèi)容

隨著iOS7 SDK的beta放出，以及Xcode 5 DP版本的到來(lái)，很多為iOS7開發(fā)應(yīng)用的方式已經(jīng)逐漸浮現(xiàn)。可以豪不夸張地講，由于iOS7的UI發(fā)生了重大變革，此次的升級(jí)不同于以往，我們將會(huì)迎來(lái)iOS開發(fā)誕生以來(lái)最劇烈的變動(dòng)，如何擁抱變化，快速適應(yīng)新的世界和平臺(tái)，值得每個(gè)Cocoa和CocoaTouch開發(fā)者研究。工欲善其事，必先利其器。想做iOS7的開發(fā)，就必須切換到Xcode5和新的ObjC體系（包括新引入的語(yǔ)法和編譯器），在這里我簡(jiǎn)要地對(duì)新添加或重大變化的功能做一個(gè)小結(jié)。

說(shuō)說(shuō)新的Xcode

Xcode4剛出的時(shí)候存在茫茫多似乎無(wú)窮無(wú)盡的bug（如果是一路走來(lái)的同仁可能對(duì)此還記憶猶新），好消息是這次Xcode5 DP版本似乎相當(dāng)穩(wěn)定，如果你遇到了開啟新Xcode就報(bào)錯(cuò)強(qiáng)退的話，多半原因是因?yàn)槟阍谑褂脼閄code4制作的插件，不同版本的Xcode是共用同一個(gè)文件夾下的插件的，請(qǐng)將~/Library/Application Support/Developer/Shared/Xcode/Plug-ins目錄下的內(nèi)容清理一下，應(yīng)該就能順利進(jìn)入Xcode5了。

Xcode 5現(xiàn)在使用了ARC，取代了原來(lái)的垃圾回收（Garbage collection）機(jī)制，因此不論從啟動(dòng)速度和使用速度上來(lái)說(shuō)都比之前快了不少。現(xiàn)在大部分的AppStore提交應(yīng)用也都使用了ARC，新SDK中加入的系統(tǒng)框架也全都是ARC的了。另外，在Xcode5中新建工程也不再提供是否使用ARC的選項(xiàng)（雖然也還是可以在Build Setting中關(guān)掉）。如果你還在使用手動(dòng)內(nèi)存管理的話，現(xiàn)在是時(shí)候拋棄release什么的了，如果你還在迷茫應(yīng)該應(yīng)該怎么使用ARC，可以參看一下去年這個(gè)時(shí)候我發(fā)的一篇ARC的教程文章。

界面變化

首先值得稱贊的是頂部工具欄的變化，新版中貫徹了精簡(jiǎn)的原則，將頂欄砍掉了30%左右的寬度，對(duì)于小屏幕來(lái)說(shuō)絕對(duì)是福音。另外，在外觀上界面也向平面和簡(jiǎn)潔的方向邁進(jìn)了一大步，可算是對(duì)iOS7的遙相呼應(yīng)吧。

更易用的版本管理

雖然在Xcode 4里就集成了版本管理的內(nèi)容，但是一直被藏的很深，很多時(shí)候開發(fā)者不得不打開Organizer才能找到對(duì)應(yīng)操作的地方。與之相比，Xcode5為版本管理留出了專門的一個(gè)Source Control菜單，從此以后媽媽再也不用擔(dān)心我找不到git放哪兒了。集成的版本管理可以方便地完成大部分初級(jí)功能，包括Check Out，Pull，Commit，Push，Merge等，特別是在建立倉(cāng)庫(kù)和檢出倉(cāng)庫(kù)時(shí)十分方便。但是在遇到稍微復(fù)雜的git操作時(shí)還是感到力不從心（比如rebase或摘櫻桃的時(shí)候），這點(diǎn)上畢竟Xcode并不是一個(gè)版本管理app，而最基本的幾個(gè)操作在日常工作中也算能快速地應(yīng)付絕大部分情況（在不將工程文件添加到版本管理的情況下）。

值得稱贊的是在編輯代碼的時(shí)候，可以直接對(duì)某一行進(jìn)行blame了，在該行點(diǎn)擊右鍵選Show Blame for Line，就能看到最后改動(dòng)的人的信息。另外，Version Editor（View->Version Editor）也除了之前就有的版本對(duì)比之外，還新加了Blame和Log兩種視圖。在對(duì)代碼歷史追溯這塊，Xcode5現(xiàn)在已經(jīng)做的足夠好了.

結(jié)論是，雖然有所進(jìn)步，但是Xcode的內(nèi)置版本管理仍然不堪大任，命令行或者一個(gè)專業(yè)的git管理工具還是必要的。

方便的工程配置

與版本管理的強(qiáng)化相比較，工程配置方面也進(jìn)行了很多加強(qiáng)，簡(jiǎn)化了之前開發(fā)者的需要做的一些配置工作。首先是在Build Setting的General里，加入了Team的設(shè)置，只要填寫對(duì)應(yīng)的Apple ID和應(yīng)用Bundle ID，Xcode就將自動(dòng)去尋找對(duì)應(yīng)的Provisioning Profile，并使用合適的Provisioning來(lái)進(jìn)行應(yīng)用打包。因?yàn)橛辛俗詣?dòng)配置和將集成的版本管理放到了菜單欄中，Organizer的地位被大大削弱了。至少我現(xiàn)在在Organizer中沒(méi)有找到本機(jī)的證書管理和Provisioning Profile管理的地方，唯一開Organizer的理由大概就是應(yīng)用打包發(fā)布時(shí)了。想想從遠(yuǎn)古時(shí)代的Application Loader一步一步走到現(xiàn)在，Xcode可以說(shuō)在簡(jiǎn)化流程，幫助開發(fā)者快速發(fā)布應(yīng)用方面做了很大努力。

另一個(gè)重要改進(jìn)是在Build選項(xiàng)中加入了Capabilities標(biāo)簽，如下圖

想想看以前為app配置iCloud要花的步驟吧：到Apple Developer里找到應(yīng)用的ID，打開對(duì)應(yīng)的app的iCloud功能，生成對(duì)應(yīng)的Provisioning文件，回到Xcode創(chuàng)建一個(gè)Entitlements文件，定義Key-Value Store，Ubiquity Containers和Keychain Groups，然后你才能開始為應(yīng)用創(chuàng)建UIDocument并且繼續(xù)開發(fā)。哦天啊…作為學(xué)習(xí)來(lái)說(shuō)做一次還能接受，但是如果每次開發(fā)應(yīng)用都要來(lái)一遍這個(gè)過(guò)程，只能用枯燥乏味四個(gè)字來(lái)形容了。于是，正如你所看到的，現(xiàn)在你需要做的是，點(diǎn)一下iCloud的開關(guān)，然后…開始編程吧～輕松愜意。同樣的方法也適用于Apple提供的其他服務(wù)，包括打開和配置GameCenter，Passbook，IAP，Maps，Keychain，后臺(tái)模式和Data Protection，當(dāng)然還有iOS7新加入的Inter-app Audio。這些小開關(guān)做的事情都很簡(jiǎn)單，但確實(shí)十分貼心。

資源管理，Asset Catalog和Image Slicing

資源目錄(Asset Catalog)和圖像切片(Image Slicing)是Xcode5新加入的功能。資源目錄可以方便開發(fā)者管理工程中使用的圖片素材，利用開發(fā)中的命名規(guī)則（比如高清圖的@2x，圖標(biāo)的Icon，Splash的Default等），來(lái)篩選和分類圖片。建立一個(gè)資源目錄十分簡(jiǎn)單，如果是老版本導(dǎo)入的工程，在工程設(shè)置中圖標(biāo)或者splash圖的設(shè)置中點(diǎn)擊Use Asset Catalog，Xcode將建立新的資源目錄；如果是直接使用Xcode 5建立的工程的話，那么資源目錄應(yīng)該已經(jīng)默認(rèn)躺在工程中了。

添加資源目錄后，在工程中會(huì)新加一個(gè).xcassets后綴的目錄用以整理和存放圖片，該文件夾中存放了圖片和對(duì)應(yīng)的json文件來(lái)保存圖片信息。為了能夠使用資源目錄的特性，以及更好的前向兼容性，建議將所有的圖片資源都加入資源目錄中：在工程中選擇.xcassets文件，然后在資源目錄中點(diǎn)擊加號(hào)即可添加圖片。另外，直接從工程外的Finder中將圖片拖動(dòng)到Xcode的資源目錄界面中，也將把拖進(jìn)來(lái)的圖片拷貝并添加到資源目錄中。對(duì)的，不再會(huì)有討厭的彈窗出來(lái)，問(wèn)你要拷貝還是要引用了。

Asset Catalog的意義在于為工程中的圖片提供了一個(gè)存儲(chǔ)信息的地方，不僅可以描述資源對(duì)應(yīng)的設(shè)備，資源的版本和更新信息等，更重要的在于可以為Image Slicing服務(wù)。所謂Image Slicing，相當(dāng)于一個(gè)可視化的resizableImageWithCapInsets:resizingMode:，可以用于指定在圖片縮放時(shí)用來(lái)填充的像素。在資源目錄中選擇要slicing的圖片，點(diǎn)擊圖片界面右下方的Show Slicing按鈕，在想要設(shè)定切片的圖片上點(diǎn)擊Start Slicing，將出現(xiàn)左中右（或者上中下）三條可以拖動(dòng)的指示線，通過(guò)拖動(dòng)它們來(lái)設(shè)定實(shí)際的縮放范圍。

在左側(cè)線（或者上方線）和中間線之間的像素將在縮放時(shí)被填充，在中間線和右側(cè)線（或者下方線）之間的像素將被隱藏。比如上面的例子，實(shí)際運(yùn)行中如果對(duì)這張圖片進(jìn)行拉伸的話，會(huì)是下面的樣子：

Image Slicing可以幫助開發(fā)者用可視化的方式完成resizable image，之后通過(guò)拖拖線就可以完成sliced image，而不必再寫代碼，也不用再一次次嘗試輸入的insets合不合適了。slicing可縮放的圖片大量用于UI中可以節(jié)省打包的占用空間，而在Xcode 5中引入和加強(qiáng)圖片資源管理的目的，很大一部分是為了配合SpriteKit將游戲引擎加入到SDK中，并將Xcode逐漸打造為一個(gè)全面的IDE工具。

新的調(diào)試和輔助功能

這應(yīng)該是Xcode5最值得稱贊的改進(jìn)了，在調(diào)試中現(xiàn)在在編輯框內(nèi)鼠標(biāo)懸浮在變量名上，Xcode將會(huì)根據(jù)類型進(jìn)行猜測(cè)，并輸出最合適的結(jié)果以幫助觀察。就像這樣：

以前版本的Xcode雖然也有鼠標(biāo)懸浮提示，但是想從中找到想要的value確實(shí)還是比較麻煩的事情，很多時(shí)候我們不得不參考下面Variables View的值或者直接p或者po它們，現(xiàn)在如果只是需要知道變量情況的話，在斷到代碼后一路用鼠標(biāo)跟著代碼走一遍，就差不多了然于胸了。如果你認(rèn)為鼠標(biāo)懸停只能打打字符串或者數(shù)字的話你就錯(cuò)了，數(shù)組，字典什么的也不在話下，更過(guò)分的是設(shè)計(jì)圖像的也能很好地顯示，只需要點(diǎn)擊預(yù)覽按鈕，就像這樣：

Xcode5集成了一個(gè)Debug面板，用來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的Profiler，可以在調(diào)試時(shí)直接看到應(yīng)用的CPU消耗，內(nèi)存使用等情況（其他的還有iCloud情況，功耗和圖形性能等）。在Debug運(yùn)行時(shí)Cmd+6即可切換到該Debug界面。監(jiān)測(cè)的內(nèi)容簡(jiǎn)單明了，CPU使用用來(lái)檢查是否有高占用或者尖峰（特別是主線程中），內(nèi)存檢測(cè)用來(lái)檢查內(nèi)存使用和釋放的情況是否符合預(yù)期。

如果養(yǎng)成開發(fā)過(guò)程的調(diào)試中就一直打開這個(gè)Profiler面板的話（至少我從之后會(huì)堅(jiān)持這個(gè)做法了），相信是有助于在開發(fā)過(guò)程中就迅速的監(jiān)測(cè)到潛在的問(wèn)題，并迅速解決的。當(dāng)然，對(duì)于明顯的問(wèn)題可以在Debug面板中發(fā)現(xiàn)后立即尋找對(duì)應(yīng)代碼解決，但是如果比較復(fù)雜的問(wèn)題，想要知道詳細(xì)情況的話，還是要使用Instruments，在Debug面板中提供了一個(gè)“Profile In Instruments”按鈕，可以快速跳轉(zhuǎn)到Instruments。

最后，Xcode在注釋式文檔方面也有進(jìn)步，現(xiàn)在如下格式的注釋將在Xcode中直接被檢測(cè)到并集成進(jìn)代碼提示中了：

/*** Setup a recorder for a specified file path. After setting it, you can use the other control method to control the shared recorder.** @param talkingPath An NSString indicates in which path the recording should be created* @returns YES if recorder setup correctly, NO if there is an error*/ - (BOOL)recordWithFilePath:(NSString *)talkingPath;

得到的結(jié)果是這樣的

以及Quick Help中會(huì)有詳細(xì)信息

Xcode現(xiàn)在可以識(shí)別Javadoc格式（類似于上面例子）的注釋文檔，可用的標(biāo)識(shí)符除了上面的@param和@return外，還有例如@see，@discussion等，關(guān)于Javadoc的更多格式規(guī)則，可以參考Wiki。

關(guān)于Objective-C，Modules和Autolinking

OC自從Apple接手后，一直在不斷改進(jìn)。隨著移動(dòng)開發(fā)帶來(lái)的OC開發(fā)者井噴式增加，客觀上也要求Apple需要提供各種良好特性來(lái)支持這樣一個(gè)龐大的開發(fā)者社區(qū)。iOS4時(shí)代的GCD，iOS5時(shí)代的ARC，iOS6時(shí)代的各種簡(jiǎn)化，每年我們都能看到OC在成為一種先進(jìn)語(yǔ)言上的努力。基于SmallTalk和runtime，本身是C的超集，如此“根正苗紅”的一門語(yǔ)言，在今年也迎來(lái)的新的變化。

今年OC的最大變化就是加入了Modules和Autolinking。

什么是Modules呢

在了解Modules之前我們需要先了解一下OC的import機(jī)制。#import <FrameworkFoo/HeaderBar.h>，我相信每個(gè)開發(fā)者都寫過(guò)這樣的代碼，用來(lái)引用其他的頭文件。熟悉C或者C++的童鞋可能會(huì)知道，在C和C++里是沒(méi)有#import的，只有#include（雖然GCC現(xiàn)在為C和C++做了特殊處理使得import可以被編譯），用來(lái)包含頭文件。#include做的事情其實(shí)就是簡(jiǎn)單的復(fù)制粘貼，將目標(biāo).h文件中的內(nèi)容一字不落地拷貝到當(dāng)前文件中，并替換掉這句include，而#import實(shí)質(zhì)上做的事情和#include是一樣的，只不過(guò)OC為了避免重復(fù)引用可能帶來(lái)的編譯錯(cuò)誤（這種情況在引用關(guān)系復(fù)雜的時(shí)候很可能發(fā)生，比如B和C都引用了A，D又同時(shí)引用了B和C，這樣A中定義的東西就在D中被定義了兩次，重復(fù)了），而加入了#import，從而保證每個(gè)頭文件只會(huì)被引用一次。

如果想深究，import的實(shí)現(xiàn)是通過(guò)#ifndef一個(gè)標(biāo)志進(jìn)行判斷，然后在引入后#define這個(gè)標(biāo)志，來(lái)避免重復(fù)引用的

實(shí)質(zhì)上import也還是拷貝粘貼，這樣就帶來(lái)一個(gè)問(wèn)題：當(dāng)引用關(guān)系很復(fù)雜，或者一個(gè)頭文件被非常多的實(shí)現(xiàn)文件引用時(shí)，編譯時(shí)引用所占的代碼量就會(huì)大幅上升（因?yàn)楸灰玫念^文件在各個(gè)地方都被copy了一遍）。為了解決這個(gè)問(wèn)題，C系語(yǔ)言引入了預(yù)編譯頭文件（PreCompiled Header），將公用的頭文件放入預(yù)編譯頭文件中預(yù)先進(jìn)行編譯，然后在真正編譯工程時(shí)再將預(yù)先編譯好的產(chǎn)物加入到所有待編譯的Source中去，來(lái)加快編譯速度。比如iOS開發(fā)中Supporting Files組內(nèi)的.pch文件就是一個(gè)預(yù)編譯頭文件，默認(rèn)情況下，它引用了UIKit和Foundation兩個(gè)頭文件--這是在iOS開發(fā)中基本每個(gè)實(shí)現(xiàn)文件都會(huì)用到的東西。

于是理論上說(shuō)，想要提高編譯速度，可以把所有頭文件引用都放到pch中。但是這樣面臨的問(wèn)題是在工程中隨處可用本來(lái)不應(yīng)該能訪問(wèn)的東西，而編譯器也無(wú)法準(zhǔn)確給出錯(cuò)誤或者警告，無(wú)形中增加了出錯(cuò)的可能性。

于是Modules誕生了。Modules相當(dāng)于將框架進(jìn)行了封裝，然后加入在實(shí)際編譯之時(shí)加入了一個(gè)用來(lái)存放已編譯添加過(guò)的Modules列表。如果在編譯的文件中引用到某個(gè)Modules的話，將首先在這個(gè)列表內(nèi)查找，找到的話說(shuō)明已經(jīng)被加載過(guò)則直接使用已有的，如果沒(méi)有找到，則把引用的頭文件編譯后加入到這個(gè)表中。這樣被引用到的Modules只會(huì)被編譯一次，但是在開發(fā)時(shí)又不會(huì)被意外使用到，從而同時(shí)解決了編譯時(shí)間和引用泛濫兩方面的問(wèn)題。

稍微追根問(wèn)底，Modules是什么？其實(shí)無(wú)非是對(duì)框架進(jìn)行了如下封裝，拿UIKit為例：

framework module UIKit {umbrella header "UIKit.h"module * {export *}link framework "UIKit" }

這個(gè)Module定義了首要頭文件（UIKit.h），需要導(dǎo)出的子modules（所有），以及需要link的框架名稱（UIKit）。需要指出的是，現(xiàn)在Module還不支持第三方的框架，所以只有SDK內(nèi)置的框架能夠從這個(gè)特性中受益。另外，在C++的源代碼中，Modules也是被禁用的。

好了，說(shuō)了那么多，這玩意兒怎么用呢

關(guān)于普通開發(fā)者使用的這個(gè)新特性的方法，Apple在LLVM5.0（也就是Xcode5帶的最新的編譯器前端中）引入了一個(gè)新的編譯符號(hào)@import，使用@符號(hào)將告訴編譯器去使用Modules的引用形式，從而獲取好處，比如想引用MessageUI，可以寫成

@import MessageUI;

在使用上，這將等價(jià)于以前的#import <MessageUI/MessageUI.h>，但是將使用Modules的特性。如果只想使用某個(gè)特性的.h文件，比如#import <MessageUI/MFMailComposeViewController.h>，對(duì)應(yīng)寫作

@import MessageUI.MFMailComposeViewController;

當(dāng)然，如果對(duì)于以前的工程，想要使用新的Modules特性，如果要把所有頭文件都這樣一個(gè)一個(gè)改成@import的話，會(huì)是很大的一個(gè)工作量。Apple自然也考慮到了這一點(diǎn)，于是對(duì)于原來(lái)的代碼，只要使用的是iOS7或者M(jìn)acOS10.9的SDK，在Build Settings中將Enable Modules(C and Objective-C)打開，然后保持原來(lái)的#import寫法就行了。是的，不需要任何代碼上的改變，編譯器會(huì)在編譯的時(shí)候自動(dòng)地把可能的地方換成Modules的寫法去編譯的。

Autolinking是Modules的附贈(zèng)小驚喜，因?yàn)樵趍odule定義的時(shí)候指定來(lái)link framework，所以在編譯module時(shí)LLVM會(huì)將所涉及到的框架自動(dòng)幫你寫到link里去，不再需要到編譯設(shè)置里去添加了。

轉(zhuǎn)載自：https://onevcat.com/

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的WWDC 2013 Session笔记 - Xcode5和ObjC新特性的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。