IOS學習筆記58--IOS7新特性之XCODE

Welcome to Xcode 5

   這是我的WWDC2013系列筆記中的一篇，完整的筆記清單請參看這篇總覽。本文僅作為個人記錄使用，也歡迎在許可協定範圍内轉載或使用，但是還煩請保留原文連結，謝謝您的了解合作。如果您覺得本站對您能有幫助，您可以使用RSS或郵件方式訂閱本站，這樣您将能在第一時間擷取本站資訊。

本文涉及到的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子產品下的内容

随着iOS7 SDK的beta放出，以及Xcode 5 DP版本的到來，很多為iOS7開發應用的方式已經逐漸浮現。可以豪不誇張地講，由于iOS7的UI發生了重大變革，此次的更新不同于以往，我們将會迎來iOS開發誕生以來最劇烈的變動，如何擁抱變化，快速适應新的世界和平台，值得每個Cocoa和CocoaTouch開發者研究。工欲善其事，必先利其器。想做iOS7的開發，就必須切換到Xcode5和新的ObjC體系（包括新引入的文法和編譯器），在這裡我簡要地對新添加或重大變化的功能做一個小結。

說說新的Xcode

Xcode4剛出的時候存在茫茫多似乎無窮無盡的bug（如果是一路走來的同仁可能對此還記憶猶新），好消息是這次Xcode5 DP版本似乎相當穩定，如果你遇到了開啟新Xcode就報錯強退的話，多半原因是因為你在使用為Xcode4制作的插件，不同版本的Xcode是共用同一個檔案夾下的插件的，請将

~/Library/Application Support/Developer/Shared/Xcode/Plug-ins

目錄下的内容清理一下，應該就能順利進入Xcode5了。

Xcode 5現在使用了ARC，取代了原來的垃圾回收（Garbage collection）機制，是以不論從啟動速度和使用速度上來說都比之前快了不少。現在大部分的AppStore送出應用也都使用了ARC，新SDK中加入的系統架構也全都是ARC的了。另外，在Xcode5中建立工程也不再提供是否使用ARC的選項（雖然也還是可以在Build Setting中關掉）。如果你還在使用手動記憶體管理的話，現在是時候抛棄release什麼的了，如果你還在迷茫應該應該怎麼使用ARC，可以參看一下去年這個時候我發的一篇ARC的教程文章。

界面變化

Xcode5減小了頂欄寬度

首先值得稱贊的是頂部工具欄的變化，新版中貫徹了精簡的原則，将頂欄砍掉了30%左右的寬度，對于小螢幕來說絕對是福音。另外，在外觀上界面也向平面和簡潔的方向邁進了一大步，可算是對iOS7的遙相呼應吧。

更易用的版本管理

image

雖然在Xcode 4裡就內建了版本管理的内容，但是一直被藏的很深，很多時候開發者不得不打開Organizer才能找到對應操作的地方。與之相比，Xcode5為版本管理留出了專門的一個

Source Control

菜單，從此以後媽媽再也不用擔心我找不到git放哪兒了。內建的版本管理可以友善地完成大部分初級功能，包括Check Out，Pull，Commit，Push，Merge等，特别是在建立倉庫和檢出倉庫時十分友善。但是在遇到稍微複雜的git操作時還是感到力不從心（比如rebase或摘櫻桃的時候），這點上畢竟Xcode并不是一個版本管理app，而最基本的幾個操作在日常工作中也算能快速地應付絕大部分情況（在不将工程檔案添加到版本管理的情況下）。

值得稱贊的是在編輯代碼的時候，可以直接對某一行進行blame了，在該行點選右鍵選Show Blame for Line，就能看到最後改動的人的資訊。另外，Version Editor（View->Version Editor）也除了之前就有的版本對比之外，還新加了Blame和Log兩種視圖。在對代碼曆史追溯這塊，Xcode5現在已經做的足夠好了.

結論是，雖然有所進步，但是Xcode的内置版本管理仍然不堪大任，指令行或者一個專業的git管理工具還是必要的。

友善的工程配置

與版本管理的強化相比較，工程配置方面也進行了很多加強，簡化了之前開發者的需要做的一些配置工作。首先是在Build Setting的General裡，加入了Team的設定，隻要填寫對應的Apple ID和應用Bundle ID，Xcode就将自動去尋找對應的Provisioning Profile，并使用合适的Provisioning來進行應用打包。因為有了自動配置和将內建的版本管理放到了菜單欄中，Organizer的地位被大大削弱了。至少我現在在Organizer中沒有找到本機的證書管理和Provisioning Profile管理的地方，唯一開Organizer的理由大概就是應用打包釋出時了。想想從遠古時代的Application Loader一步一步走到現在，Xcode可以說在簡化流程，幫助開發者快速釋出應用方面做了很大努力。

另一個重要改進是在Build選項中加入了

Capabilities

标簽，如下圖

Xcode5的Capabilities

想想看以前為app配置iCloud要花的步驟吧：到Apple Developer裡找到應用的ID，打開對應的app的iCloud功能，生成對應的Provisioning檔案，回到Xcode建立一個Entitlements檔案，定義Key-Value Store，Ubiquity Containers和Keychain Groups，然後你才能開始為應用建立UIDocument并且繼續開發。哦天啊…作為學習來說做一次還能接受，但是如果每次開發應用都要來一遍這個過程，隻能用枯燥乏味四個字來形容了。于是，正如你所看到的，現在你需要做的是，點一下iCloud的開關，然後…開始程式設計吧～輕松惬意。同樣的方法也适用于Apple提供的其他服務，包括打開和配置GameCenter，Passbook，IAP，Maps，Keychain，背景模式和Data Protection，當然還有iOS7新加入的Inter-app Audio。這些小開關做的事情都很簡單，但确實十分貼心。

資源管理，Asset Catalog和Image Slicing

資源目錄(Asset Catalog)和圖像切片(Image Slicing)是Xcode5新加入的功能。資源目錄可以友善開發者管理工程中使用的圖檔素材，利用開發中的命名規則（比如高清圖的@2x，圖示的Icon，Splash的Default等），來篩選和分類圖檔。建立一個資源目錄十分簡單，如果是老版本導入的工程，在工程設定中圖示或者splash圖的設定中點選

Use Asset Catalog

，Xcode将建立新的資源目錄；如果是直接使用Xcode 5建立的工程的話，那麼資源目錄應該已經預設躺在工程中了。

添加一個Asset Catalog

添加資源目錄後，在工程中會新加一個.xcassets字尾的目錄用以整理和存放圖檔，該檔案夾中存放了圖檔和對應的json檔案來儲存圖檔資訊。為了能夠使用資源目錄的特性，以及更好的前向相容性，建議将所有的圖檔資源都加入資源目錄中：在工程中選擇.xcassets檔案，然後在資源目錄中點選加号即可添加圖檔。另外，直接從工程外的Finder中将圖檔拖動到Xcode的資源目錄界面中，也将把拖進來的圖檔拷貝并添加到資源目錄中。對的，不再會有讨厭的彈窗出來，問你要拷貝還是要引用了。

在Asset Catalog中添加圖檔

Asset Catalog的意義在于為工程中的圖檔提供了一個存儲資訊的地方，不僅可以描述資源對應的裝置，資源的版本和更新資訊等，更重要的在于可以為Image Slicing服務。所謂Image Slicing，相當于一個可視化的

resizableImageWithCapInsets:resizingMode:

，可以用于指定在圖檔縮放時用來填充的像素。在資源目錄中選擇要slicing的圖檔，點選圖檔界面右下方的Show Slicing按鈕，在想要設定切片的圖檔上點選

Start Slicing

，将出現左中右（或者上中下）三條可以拖動的訓示線，通過拖動它們來設定實際的縮放範圍。

設定Image Slicing

在左側線（或者上方線）和中間線之間的像素将在縮放時被填充，在中間線和右側線（或者下方線）之間的像素将被隐藏。比如上面的例子，實際運作中如果對這張圖檔進行拉伸的話，會是下面的樣子：

拉升Image Slicing後的圖檔

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

新的調試和輔助功能

這應該是Xcode5最值得稱贊的改進了，在調試中現在在編輯框内滑鼠懸浮在變量名上，Xcode将會根據類型進行猜測，并輸出最合适的結果以幫助觀察。就像這樣：

滑鼠懸浮就可以出現變量結果

以前版本的Xcode雖然也有滑鼠懸浮提示，但是想從中找到想要的value确實還是比較麻煩的事情，很多時候我們不得不參考下面Variables View的值或者直接p或者po它們，現在如果隻是需要知道變量情況的話，在斷到代碼後一路用滑鼠跟着代碼走一遍，就差不多了然于胸了。如果你認為滑鼠懸停隻能打打字元串或者數字的話你就錯了，數組，字典什麼的也不在話下，更過分的是設計圖像的也能很好地顯示，隻需要點選預覽按鈕，就像這樣：

直接懸停顯示圖檔

Xcode5內建了一個Debug面闆，用來實作一個簡單的Profiler，可以在調試時直接看到應用的CPU消耗，記憶體使用等情況（其他的還有iCloud情況，功耗和圖形性能等）。在Debug運作時Cmd+6即可切換到該Debug界面。監測的内容簡單明了，CPU使用用來檢查是否有高占用或者尖峰（特别是主線程中），記憶體檢測用來檢查記憶體使用和釋放的情況是否符合預期。

Debug的Profiler面闆

如果養成開發過程的調試中就一直打開這個Profiler面闆的話（至少我從之後會堅持這個做法了），相信是有助于在開發過程中就迅速的監測到潛在的問題，并迅速解決的。當然，對于明顯的問題可以在Debug面闆中發現後立即尋找對應代碼解決，但是如果比較複雜的問題，想要知道詳細情況的話，還是要使用Instruments，在Debug面闆中提供了一個“Profile In Instruments”按鈕，可以快速跳轉到Instruments。

最後，Xcode在注釋式文檔方面也有進步，現在如下格式的注釋将在Xcode中直接被檢測到并內建進代碼提示中了：

1 2 3 4 5 6 7

/** * 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;

得到的結果是這樣的

Xcode對代碼注釋的解析

以及Quick Help中會有詳細資訊

在Quick Help中顯示詳細文檔

Xcode現在可以識别Javadoc格式（類似于上面例子）的注釋文檔，可用的辨別符除了上面的

@param

和

@return

外，還有例如

@see

，

@discussion

等，關于Javadoc的更多格式規則，可以參考Wiki。

關于Objective-C，Modules和Autolinking

OC自從Apple接手後，一直在不斷改進。随着移動開發帶來的OC開發者井噴式增加，客觀上也要求Apple需要提供各種良好特性來支援這樣一個龐大的開發者社群。iOS4時代的GCD，iOS5時代的ARC，iOS6時代的各種簡化，每年我們都能看到OC在成為一種先進語言上的努力。基于SmallTalk和runtime，本身是C的超集，如此“根正苗紅”的一門語言，在今年也迎來的新的變化。

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

什麼是Modules呢

在了解Modules之前我們需要先了解一下OC的import機制。

#import <FrameworkFoo/HeaderBar.h>

，我相信每個開發者都寫過這樣的代碼，用來引用其他的頭檔案。熟悉C或者C++的童鞋可能會知道，在C和C++裡是沒有#import的，隻有#include（雖然GCC現在為C和C++做了特殊處理使得imoprt可以被編譯），用來包含頭檔案。#include做的事情其實就是簡單的複制粘貼，将目标.h檔案中的内容一字不落地拷貝到目前檔案中，并替換掉這句include，而#import實質上做的事情和#include是一樣的，隻不過OC為了避免重複引用可能帶來的編譯錯誤（這種情況在引用關系複雜的時候很可能發生，比如B和C都引用了A，D又同時引用了B和C，這樣A中定義的東西就在D中被定義了兩次，重複了），而加入了#import，進而保證每個頭檔案隻會被引用一次。

如果想深究，import的實作是通過#ifndef一個标志進行判斷，然後在引入後#define這個标志，來避免重複引用的

實質上import也還是拷貝粘貼，這樣就帶來一個問題：當引用關系很複雜，或者一個頭檔案被非常多的實作檔案引用時，編譯時引用所占的代碼量就會大幅上升（因為被引用的頭檔案在各個地方都被copy了一遍）。為了解決這個問題，C系語言引入了預編譯頭檔案（PreCompiled Header），将公用的頭檔案放入預編譯頭檔案中預先進行編譯，然後在真正編譯工程時再将預先編譯好的産物加入到所有待編譯的Source中去，來加快編譯速度。比如iOS開發中Supporting Files組内的.pch檔案就是一個預編譯頭檔案，預設情況下，它引用了UIKit和Foundation兩個頭檔案–這是在iOS開發中基本每個實作檔案都會用到的東西。

于是理論上說，想要提高編譯速度，可以把所有頭檔案引用都放到pch中。但是這樣面臨的問題是在工程中随處可用本來不應該能通路的東西，而編譯器也無法準确給出錯誤或者警告，無形中增加了出錯的可能性。

于是Modules誕生了。Modules相當于将架構進行了封裝，然後加入在實際編譯之時加入了一個用來存放已編譯添加過的Modules清單。如果在編譯的檔案中引用到某個Modules的話，将首先在這個清單内查找，找到的話說明已經被加載過則直接使用已有的，如果沒有找到，則把引用的頭檔案編譯後加入到這個表中。這樣被引用到的Modules隻會被編譯一次，但是在開發時又不會被意外使用到，進而同時解決了編譯時間和引用泛濫兩方面的問題。

稍微追根問底，Modules是什麼？其實無非是對架構進行了如下封裝，拿UIKit為例：

1 2 3 4 5

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

這個Module定義了首要頭檔案（UIKit.h），需要導出的子modules（所有），以及需要link的架構名稱（UIKit）。需要指出的是，現在Module還不支援第三方的架構，是以隻有SDK内置的架構能夠從這個特性中受益。另外，在C++的源代碼中，Modules也是被禁用的。

好了，說了那麼多，這玩意兒怎麼用呢

關于普通開發者使用的這個新特性的方法，Apple在LLVM5.0（也就是Xcode5帶的最新的編譯器前端中）引入了一個新的編譯符号

@import

，使用@符号将告訴編譯器去使用Modules的引用形式，進而擷取好處，比如想引用MessageUI，可以寫成

1	@import MessageUI;

在使用上，這将等價于以前的

#import <MessageUI/MessageUI.h>

，但是将使用Modules的特性。如果隻想使用某個特性的.h檔案，比如

#import <MessageUI/MFMailComposeViewController.h>

，對應寫作

1	@import MessageUI.MFMailComposeViewController;

當然，如果對于以前的工程，想要使用新的Modules特性，如果要把所有頭檔案都這樣一個一個改成

@import

的話，會是很大的一個工作量。Apple自然也考慮到了這一點，于是對于原來的代碼，隻要使用的是iOS7或者MacOS10.9的SDK，在Build Settings中将Enable Modules(C and Objective-C)打開，然後保持原來的

#import

寫法就行了。是的，不需要任何代碼上的改變，編譯器會在編譯的時候自動地把可能的地方換成Modules的寫法去編譯的。

Autolinking是Modules的附贈小驚喜，因為在module定義的時候指定來link framework，是以在編譯module時LLVM會将所涉及到的架構自動幫你寫到link裡去，不再需要到編譯設定裡去添加了。