這是我的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的教程文章。
界面變化
首先值得稱讚的是頂部工具欄的變化,新版中貫徹了精簡的原則,將頂欄砍掉了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中直接被檢測到並集成進代碼提示中了:
1 2 3 4 5 6 7 |
|
得到的結果是這樣的
以及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 |
|
這個Module定義了首要頭文件(UIKit.h),需要導出的子modules(所有),以及需要link的框架名稱(UIKit)。需要指出的是,現在Module還不支持第三方的框架,所以只有SDK內置的框架能夠從這個特性中受益。另外,在C++的源代碼中,Modules也是被禁用的。
好了,說了那麼多,這玩意兒怎麼用呢
關於普通開發者使用的這個新特性的方法,Apple在LLVM5.0(也就是Xcode5帶的最新的編譯器前端中)引入了一個新的編譯符號@import
,使用@符號將告訴編譯器去使用Modules的引用形式,從而獲取好處,比如想引用MessageUI,可以寫成
1
|
|
在使用上,這將等價於以前的#import <MessageUI/MessageUI.h>
,但是將使用Modules的特性。如果只想使用某個特性的.h文件,比如#import
<MessageUI/MFMailComposeViewController.h>
,對應寫作
1
|
|
當然,如果對於以前的工程,想要使用新的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裏去,不再需要到編譯設置裏去添加了。