WWDC 2015 (二)


由于这两天Hiking,看电影,和朋友吃饭等等琐事占用了大部分的时间。所以这篇延误了几天时间。上一篇介绍了关于App thinning和Deep linking的一些新内容。接来继续介绍本次WWDC让我眼前一亮的内容。

Xcode7

其实每年新的Xcode都是我比较期待的,因为让我在三四年放弃Android认定iOS,Xcode在里面起到的很大的作用 (也可以说Eclipse起到了很大的反作用 ╮(╯3╰)╭ )。今年的Xcode7也不出意外的有了不少的新功能,除去那些常规的性能上的提升,有几点是让我觉得非常有用的。

1.Xcode Free for ALL!

我只想说还有比这个更让人高兴的么?对普通的学生来说,总算不再需要每年花上99美金只为了学习怎么做iOS App了。回想当年在留学时候帮学校做着几块钱一个小时的廉价网站开发,为了学iOS还必须凑钱买个Macbook和这个99快钱的Developer Program。真的是很苦恼。现在虽然Mac还是不能省去,可毕竟Mac算是一台很不错的笔记本,而且可以使用至少几年。这个开发者Program真的是在学习开发阶段毫无意义(你觉得才99块钱没省多少?对于一贯抠门的Apple来说,知足吧,还要什么自行车)。

Anyway,主要想说的也不是省下这99块钱就能把世界变的多美好。但是不论如何降低门槛对于整个行业来说还是很有帮助的,进来的人越多,这个行业发展的速度就越快。形成一个健康的生态环境和良性循环是最重要的。

2. Address Sanitizer

我相信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。当然背后的细节做法肯定比听起来复杂的多。

撇开背后的复杂含义,对开发者来说,最有帮助的就是一旦遇到这类的Crash,Xcode不会像以前那样仅仅break在Main class和显示一条不是特别有帮助的"EXC_ BAD_ ACCESS xxxxxxxx"的错误信息。有了Address Sanitizer的支持Xcode会提供具体的Crash trace和break在具体的line上,和提示一条相对好理解的Error message,比如"Use of deallocated memory detected"

而且开发者还能看到具体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用的类似的技术,一旦选则一个,就不能用使用另一个了。

我会推荐大家同时打开Zombie和Address Sanitizer,这样基本就能覆盖大部分的Memory相关的Bug。Address Sanitizer虽然并不算一个非常大的创新,但是不论如何只要能把Debug的效率提高,让App更完善更稳定,让PM更舒心,让老板更安心,这样对开发者,用户,PM和老板都是一件好事。又是一个一举多得的的新功能。

2. UI Test

新的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的方法处理一些逻辑上的判断,从而做到一个完整的测试。

至于我特地把他拿出来再写一次的原因也主要是Record UITest目前在Xcode7中还是比较好用的。简单易懂。基本完全还原了用户操作的过程,而且比较精确。只要建一个UITest的Function,然后打开录制模式,任意在Simulator中操作,Xcode就会顺利把操作内容转化成代码。之后只需要简单的run录制好的Function,就能顺利达到测试的效果。和Unit Testing一样可以把他们放在XCodeServer中做一并的测试。

他最后生成的Test report也和UIAutomation类似。会提供简单的错误的信息,和每个步骤上提供一张截图。好好利用Assertion来提供更详尽的测试信息和错误提示吧。

Watch OS

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

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让他签下了自己的名字。(什么,你觉得是反过来的?别呢么在意,意思 到了就行了!)