【xcode5的使用】

layout: post title: "WWDC 2013 Session筆記 - Xcode5和ObjC新特性" date: 2013-06-13 10:05 comments: true categories: 能工巧匠集

published: false

這是個人WWDC2013系列筆記中的一篇，完整的筆記列表請參看這篇總覽。本文僅做爲我的記錄使用，不公開發布，請不要轉載和隨意發佈，謝謝您的理解合做。

本文涉及到的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的教程文章。

界面變化

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

更易用的版本管理

雖然在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標籤，以下圖

想一想看之前爲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創建的工程的話，那麼資源目錄應該已經默認躺在工程中了。

添加資源目錄後，在工程中會新加一個.xcassets後綴的目錄用以整理和存放圖片，該文件夾中存放了圖片和對應的json文件來保存圖片信息。爲了可以使用資源目錄的特性，以及更好的前向兼容性，建議將全部的圖片資源都加入資源目錄中：在工程中選擇.xcassets文件，而後在資源目錄中點擊加號便可添加圖片。另外，直接從工程外的Finder中將圖片拖動到Xcode的資源目錄界面中，也將把拖進來的圖片拷貝並添加到資源目錄中。對的，再也不會有討厭的彈窗出來，問你要拷貝仍是要引用了。

Asset Catalog的意義在於爲工程中的圖片提供了一個存儲信息的地方，不只能夠描述資源對應的設備，資源的版本和更新信息等，更重要的在於能夠爲Image Slicing服務。所謂Image Slicing，至關於一個可視化的resizableImageWithCapInsets:resizingMode:，能夠用於指定在圖片縮放時用來填充的像素。在資源目錄中選擇要slicing的圖片，點擊圖片界面右下方的Show Slicing按鈕，在想要設定切片的圖片上點擊Start 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使用用來檢查是否有高佔用或者尖峯（特別是主線程中），內存檢測用來檢查內存使用和釋放的狀況是否符合預期。

若是養成開發過程的調試中就一直打開這個Profiler面板的話（至少我從以後會堅持這個作法了），相信是有助於在開發過程當中就迅速的監測到潛在的問題，並迅速解決的。固然，對於明顯的問題能夠在Debug面板中發現後當即尋找對應代碼解決，可是若是比較複雜的問題，想要知道詳細狀況的話，仍是要使用Instruments，在Debug面板中提供了一個「Profile In Instruments」按鈕，能夠快速跳轉到Instruments。

最後，Xcode在註釋式文檔方面也有進步，如今以下格式的註釋將在Xcode中直接被檢測到並集成進代碼提示中了：

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

獲得的結果是這樣的

以及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爲例：

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，能夠寫成

@import MessageUI;

在使用上，這將等價於之前的#import <MessageUI/MessageUI.h>，可是將使用Modules的特性。若是隻想使用某個特性的.h文件，好比#import <MessageUI/MFMailComposeViewController.h>，對應寫做

@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裏去，再也不須要到編譯設置裏去添加了。

 

轉自：https://github.com/onevcat/OneV-s-Den/blob/master/source/_posts/2013-06-13-new-in-xcode5-and-objc.markdown