你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發基礎 >> WWDC 2015上那些酷酷的新內容(二)

WWDC 2015上那些酷酷的新內容(二)

編輯:IOS開發基礎

57.jpg

作者:作者:徐寅(博客,微博)
由於這兩天Hiking,看電影,和朋友吃飯等等瑣事占用了大部分的時間。所以這篇延誤了幾天時間。上一篇介紹了關於App thinning和Deep linking的一些新內容。接來繼續介紹本次WWDC讓我眼前一亮的內容。

Xcode 7

其實每年新的Xcode都是我比較期待的,因為讓我在三四年放棄Android認定iOS,Xcode在裡面起到的很大的作用 (也可以說Eclipse起到了很大的反作用 ╮(╯3╰)╭ )。今年的Xcode7也不出意外的有了不少的新功能,除去那些常規的性能上的提升,有幾點是讓我覺得非常有用的。

1.Xcode Free for ALL!

Screen-Shot-2015-06-13-at-1-30-05-AM.png

我只想說還有比這個更讓人高興的麼?對普通的學生來說,總算不再需要每年花上99美金只為了學習怎麼做iOS App了。回想當年在留學時候幫學校做著幾塊錢一個小時的廉價網站開發,為了學iOS還必須湊錢買個Macbook和這個99快錢的Developer Program。真的是很苦惱。現在雖然Mac還是不能省去,可畢竟Mac算是一台很不錯的筆記本,而且可以使用至少幾年。這個開發者Program真的是在學習開發階段毫無意義(你覺得才99塊錢沒省多少?對於一貫摳門的Apple來說,知足吧,還要什麼自行車)。

Anyway,主要想說的也不是省下這99塊錢就能把世界變的多美好。但是不論如何降低門檻對於整個行業來說還是很有幫助的,進來的人越多,這個行業發展的速度就越快。形成一個健康的生態環境和良性循環是最重要的。

2. Address Sanitizer

23.png

我相信90%以上的開發者都會遇到"EXC_ BAD_ ACCESS"或者signal SIGBRT這類的"非常規"bug。或者你老板跑來說他遇到一個Crash,但是你嘗試了100次也不能reproduce,然後開始痛不欲生的debug之旅。

現在Xcode7提供了一個也許可以至少提供你一些線索的工具,叫Address Sanitizer(內存地址清潔劑?名字我隨便翻譯的),能夠幫你找到一些常規Compiler沒辦法幫你找到的run time bug,比如deallocated memory,heap buffer overflow/underflow,stack memory overflow之類的。根據Apple的描述,他們對每種結構都有一個獨特的做法。但是簡單來說,是在你每個Allocate的物理內存背後做一個Shadow memory,在Shadow memory中將那些deallcaoted memory標記成redzone,在每次指向內存地址的時候都會檢查是否在指向一個redzone裡面的內存地址,也就是他們所謂的IsPoisoned。如果是的話就crash。當然背後的細節做法肯定比聽起來復雜的多。

11.png

22.png

撇開背後的復雜含義,對開發者來說,最有幫助的就是一旦遇到這類的Crash,Xcode不會像以前那樣僅僅break在Main class和顯示一條不是特別有幫助的"EXC_ BAD_ ACCESS xxxxxxxx"的錯誤信息。有了Address Sanitizer的支持Xcode會提供具體的Crash trace和break在具體的line上,和提示一條相對好理解的Error message,比如"Use of deallocated memory detected"

33.png

而且開發者還能看到具體Memory allocation和deallocation的具體細節。對Debug這類Bug非常有幫助。

Apple自己的Session中提到,Address Sanitizer與的Guard Malloc和 Valgrind類似,但是能找到更多的run time error,還擁有更小的overhead。所以推薦大家在開發的時候都要打開Address Sanitizer,這樣有備無患。

打開的方法也很簡答,就和之前用Zombie來Debug Bad Access一樣。在Schema->Run->Diagnostics裡面選中Enable Address Sanitizer然後再Run App就可以了。就如同上面提到過的,因為Address SanitizerH和Guard Malloc用的類似的技術,一旦選則一個,就不能用使用另一個了。

44.png

我會推薦大家同時打開Zombie和Address Sanitizer,這樣基本就能覆蓋大部分的Memory相關的Bug。Address Sanitizer雖然並不算一個非常大的創新,但是不論如何只要能把Debug的效率提高,讓App更完善更穩定,讓PM更舒心,讓老板更安心,這樣對開發者,用戶,PM和老板都是一件好事。又是一個一舉多得的的新功能。

UI Test

47.png

新的Xcode7中Test Target不光只有Testing Bundle,還加入了UI Testing Bundle。其實UI Testing也不能算是一個非常大的創新,因為早在iOS4的時代Profile裡就已經有UIAutomation,可以用來做相關的UI測試。還有比如像Gogobot利用Javascript寫的Test Class其實都可以做到。但為什麼5年之後的iOS9,Apple再把它重新做了一遍拿到Xcode7中了呢?我相信大家和我猜是一樣的,因為他們自己都意識到UIAutomation這類不太好用吧。

在Xcode7中的UI Testing背後的技術是XCTest加上Accessibility,也就是說XCTest會通過Accessibility Identifier來找到UI中相關的控件,然後做相應的操作。基本用過UIAutomation的小伙伴就不會對這套模式感到陌生了。然後再通過加上Assertion的方法處理一些邏輯上的判斷,從而做到一個完整的測試。

48.png

49.gif

至於我特地把他拿出來再寫一次的原因也主要是Record UITest目前在Xcode7中還是比較好用的。簡單易懂。基本完全還原了用戶操作的過程,而且比較精確。只要建一個UITest的Function,然後打開錄制模式,任意在Simulator中操作,Xcode就會順利把操作內容轉化成代碼。之後只需要簡單的run錄制好的Function,就能順利達到測試的效果。和Unit Testing一樣可以把他們放在XCodeServer中做一並的測試。

50.gif

他最後生成的Test report也和UIAutomation類似。會提供簡單的錯誤的信息,和每個步驟上提供一張截圖。好好利用Assertion來提供更詳盡的測試信息和錯誤提示吧。

Watch OS

51.png

Watch OS也算是今年WWDC的一個重點,但其實一點也不出乎大家的意料。因為只要在這之前做過Watch App的小伙伴就知道,之前Watch Kit能做的東西實在太少,局限性太大。所以推出一個獨立的OS是理所應當的。我之前甚至考慮是不是要把Watch OS做為這篇文章中的一部份,因為說實話,Watch App現在仍是在探索期間,幾乎沒有找到特別實用的第三方App。所以我不覺得單獨變成一個OS和開放幾個基本的Api之後能有多大的突破。畢竟穿戴式設備使用場景原本就不多,加上硬件上的局限性比較大,和Apple對設計Layout的種種的限制,讓我自己對開發Watch App和使用Watch App的熱情降低了很多。

之前在Watch上市前花了兩周把Gogobot的Watch App完成後也被Apple在Watch App Travel的版塊中被Feature了,但是用戶反應平平,甚至我自己都很少使用。所以感覺Watch OS的改變沒有到讓我特別感覺到喜大普奔的意思。當然做為手表的使用者和開發者還是希望看到更多更好的App,可能至少目前還沒有特別好的idea,希望能隨著時間的推移有更多更好的idea出現。

但是不論如何至少隨著Watch OS的推出,很多之前原本就應該開放的功能已經可以被開發者使用,比如麥克風,Digital Cronw,Tapic,心跳指數,UI簡單的動畫,Wifi,視頻等等。同時App從一個附屬Extension變成一個獨立的App,性能上肯定是有不少的提升,但還沒有真的裝在手表中測試,也不能確定性能提高的體驗有多好。

另一個優點是Watch App和iPhone App之間的交流應該會變的簡單些。目前的App之間交流都基本是單向的,只能Watch App連接到iPhone App,反過來的話需要Hack一個Warmhole才行。這一點改變會讓開發的空間更大一些。

還有一點讓我感到失望的是Clock face沒有全面向開發者開發,僅僅能開發Complications還是沒特別大的意義。因為作為手表來說,顯而易見的Watch face是最常被使用到的,而且Wacth face開發的余地很大。比如Moto 360上面就有很多很漂亮而且很實用的第三方Watch face。到現在還掐著這個Api不放,Apple估計也是在為以後的WWDC留一點內容吧。

反正總的來說Wathc OS給我的感覺還是比較一般的,不知道小伙伴對這個有沒有其他看法,或者對Watch App有沒有好的Idea,也可以通過微博和微信和我交流看看。

Swift 2.0

52.png

Swift 2.0可能最大的新聞就是開源。對於以保守出名的Apple來說,要他們開源一個項目是非常非常困難的。因為Swift從去年發布到現在受到的關注大於我聽說過的所有新的編程語言語言,而且在Stackoverflow上竟然短短一年內成為最受歡迎的語言之一。

開發者對一門語言的熱切關注一般是促使這門語言發展的最好趨勢,而開源更是對一門編程語言開發速度的最大助力。而且當一門語言開源之後,最常見的就是在不同的平台上的發展,以後可能Swift不僅僅用於iOS或者OSX軟件上的開發,而Xcode也可能不再是唯一一個Swift的IDE。或者是Swift++,Swift lite這類基於Swift而產生的擴展性編程語言。總而言之開源對一門原本就有很多關注度的語言來說是最有意義的事情。

就Swift語言本身在2.0也有了非常大的進步。Swift 1.2已經達到了一個比較穩定的階段,2.0更是將一些原本沒有做的特別好的區塊做了更大的提升。

比如我最常吐槽的Error Message的問題,Swift對Compile的要求非常高的,一些非常小的錯誤都會導致無法Compile,但讓我頭疼的是不能Compile時顯示的Error Message非常爛,常常詞不達意或者模稜兩可。在Swift 2.0裡面已經有了很大的修復。

還有對協議的擴展,錯誤處理的方法,語法的提升,playground的功能性能進步一加強,讓Comments支持Markdown等等的新內容,都讓Swift比以前更快速高效和安全。我自己目前也花很多時間再Swift的研究和相關內容的編寫上。相信不久以後還會有不少內容和大家分享。敬請期待。

總結

連續兩年參加WWDC,都感覺到現在Mobile開發的風潮越來越盛。做為移動軟件工程師來說還是喜聞樂見的,當然也希望這個風潮能持續。做為領頭羊的Apple和Google都在竭盡所能讓大家的移動設備變得越來越豐富,做為開發者的我們也在盡最大的努力把App的體驗做的更加好。希望一個良性的生態環境讓這個產業鏈持續升溫。

最後附上我的粉絲Tim和我熱情的合照,並且在他要求下,我勉為其難的拿出自己的Badge讓他簽下了自己的名字。(什麼,你覺得是反過來的?別呢麼在意,意思 到了就行了!)

53.jpg

  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved