multi-threading

题外

objc.io 是一个非常棒的iOS进阶学习的网站,上面有很多超赞的学习资源和例子。最近我和 @方一雄@answer-huang 和社区的另外几名小伙伴在主持做一个 objc.io 的译文整理汇总和后续翻译跟进的项目,我暂时略自我狂妄地把它叫做 objc中国objccn.io) 项目,希望它能给现在已经很红火的中国objc社区锦上添花。现在上面已经有一些文章,您可以时不时地访问我们的首页来查看新的动态。如果有兴趣,也可以考虑加入我们,来为中国objc社区的发展贡献一点力量。

对objc中国上的每一篇文章,我都会至少进行一个基本的校对。在整理和收集的过程中,我发现虽然不少文章有相对完整的译文,但其中也存在对原文的理解上有一定偏差的情况。可能是译者并没有原作者对某些问题的深入理解,可能是原文也做过一些修改调整而译文没有更新,也可能是因为翻译时时间上多有仓促,导致了它们并不足以在只是稍加修改后就能发表在主站点上。对于这样的译文,我的想法是为了保证文章质量,牺牲一些个人时间来重新进行翻译。一来可以保证文章质量和站点的水准,二来也算是一次自我学习和提高的过程。

题外话完毕。本文是 objc.io issue #2 的第二篇正文,这篇文章在该主题第一篇并发编程:API 及挑战的基础上深层次地讲了一些实践上的例子和技术,颇有难度。对多线程不熟悉的同学可以先参照看看第一篇,再来阅读本文。

继续阅读

Kiwi

测试驱动开发(Test Driven Development,以下简称TDD)是保证代码质量的不二法则,也是先进程序开发的共识。Apple一直致力于在iOS开发中集成更加方便和可用的测试,在Xcode 5中,新的IDE和SDK引入了XCTest来替代原来的SenTestingKit,并且取消了新建工程时的“包括单元测试”的可选项(同样待遇的还有使用ARC的可选项)。新工程将自动包含测试的target,并且相关框架也搭建完毕,可以说测试终于摆脱了iOS开发中“二等公民”的地位,现在已经变得和产品代码一样重要了。我相信每个工程师在完成自己的业务代码的同时,也有最基本的编写和维护相应的测试代码的义务,以保证自己的代码能够正确运行。更进一步,如果能够使用TDD来进行开发,不仅能保证代码运行的正确性,也有助于代码结构的安排和思考,有助于自身的不断提高。我在最开始进行开发时也曾对测试嗤之以鼻,但后来无数的惨痛教训让我明白那么多工程师痴迷于测试或者追求更完美的测试,是有其深刻含义的。如果您之前还没有开始为您的代码编写测试,我强烈建议,从今天开始,从现在开始(也许做不到的话,也请从下一个项目开始),编写测试,或者尝试一下TDD的开发方式。

Kiwi是一个iOS平台十分好用的行为驱动开发(Behavior Driven Development,以下简称BDD)的测试框架,有着非常漂亮的语法,可以写出结构性强,非常容易读懂的测试。因为国内现在有关Kiwi的介绍比较少,加上在测试这块很能很多工程师们并没有特别留意,水平层次可能相差会很远,因此在这一系列的两篇博文中,我将从头开始先简单地介绍一些TDD的概念和思想,然后从XCTest的最简单的例子开始,过渡到Kiwi的测试世界。在下一篇中我将继续深入介绍一些Kiwi的其他稍高一些的特性,以期更多的开发者能够接触并使用Kiwi这个优秀的测试框架。

什么是TDD,为什么我们要TDD

测试驱动开发并不是一个很新鲜的概念了。软件开发工程师们(当然包括你我)最开始学习程序编写时,最喜欢干的事情就是编写一段代码,然后运行观察结果是否正确。如果不对就返回代码检查错误,或者是加入断点或者输出跟踪程序并找出错误,然后再次运行查看输出是否与预想一致。如果输出只是控制台的一个简单的数字或者字符那还好,但是如果输出必须在点击一系列按钮之后才能在屏幕上显示出来的东西呢?难道我们就只能一次一次地等待编译部署,启动程序然后操作UI,一直点到我们需要观察的地方么?这种行为无疑是对美好生命和绚丽青春的巨大浪费。于是有一些已经浪费了无数时间的资深工程师们突然发现,原来我们可以在代码中构建出一个类似的场景,然后在代码中调用我们之前想检查的代码,并将运行的结果与我们的设想结果在程序中进行比较,如果一致,则说明了我们的代码没有问题,是按照预期工作的。比如我们想要实现一个加法函数add,输入两个数字,输出它们相加后的结果。那么我们不妨设想我们真的拥有两个数,比如3和5,根据人人会的十以内的加法知识,我们知道答案是8.于是我们在相加后与预测的8进行比较,如果相等,则说明我们的函数实现至少对于这个例子是没有问题的,因此我们对“这个方法能正确工作”这一命题的信心就增加了。这个例子的伪码如下:

继续阅读

Happy define :)

宏定义在C系开发中可以说占有举足轻重的作用。底层框架自不必说,为了编译优化和方便,以及跨平台能力,宏被大量使用,可以说底层开发离开define将寸步难行。而在更高层级进行开发时,我们会将更多的重心放在业务逻辑上,似乎对宏的使用和依赖并不多。但是使用宏定义的好处是不言自明的,在节省工作量的同时,代码可读性大大增加。如果想成为一个能写出漂亮优雅代码的开发者,宏定义绝对是必不可少的技能(虽然宏本身可能并不漂亮优雅XD)。但是因为宏定义对于很多人来说,并不像业务逻辑那样是每天会接触的东西。即使是能偶尔使用到一些宏,也更多的仅仅只停留在使用的层级,却并不会去探寻背后发生的事情。有一些开发者确实也有探寻的动力和意愿,但却在点开一个定义之后发现还有宏定义中还有其他无数定义,再加上满屏幕都是不同于平时的代码,既看不懂又不变色,于是乎心生烦恼,怒而回退。本文希望通过循序渐进的方式,通过几个例子来表述C系语言宏定义世界中的一些基本规则和技巧,从0开始,希望最后能让大家至少能看懂和还原一些相对复杂的宏。考虑到我自己现在objc使用的比较多,这个站点的读者应该也大多是使用objc的,所以有部分例子是选自objc,但是本文的大部分内容将是C系语言通用。

入门

如果您完全不知道宏是什么的话,可以先来热个身。很多人在介绍宏的时候会说,宏嘛很简单,就是简单的查找替换嘛。嗯,只说对了的一半。C中的宏分为两类,对象宏(object-like macro)和函数宏(function-like macro)。对于对象宏来说确实相对简单,但却也不是那么简单的查找替换。对象宏一般用来定义一些常数,举个例子:

1
2
//This defines PI
#define M_PI        3.14159265358979323846264338327950288
继续阅读

Code-vs-Xibs-vs-StroyBoard

最近接触了几个刚入门的iOS学习者,他们之中存在一个普遍和困惑和疑问,就是应该如何制作UI界面。iOS应用是非常重视用户体验的,可以说绝大多数的应用成功与否与交互设计以及UI是否漂亮易用有着非常大的关系。而随着iOS开发发展至今,可以说在UI制作上大家逐渐分化为了三种主要流派:使用代码手写UI及布局;使用单个xib文件组织viewController或者view;使用StoryBoard来通过单个或很少的几个(关于这点稍后会进行展开)文件构建全部UI。应该使用哪种方式来制作UI已经是iOS开发中亘古不变的争论话题了,或许永远不会有一个统一的结论。但是首先需要知道的是三种方式各有优劣,所以也各有自己最适用的场合,而不会有完全的孰优孰劣。对于初学iOS开发来说,一时间其实是很难判定最适合自己的UI架构方式的。在这篇文章里我希望能够通过自己的经验给出一些意见,以期能帮助入门者来挑选最适合自己应用场景的方案。对于老鸟的话,也不妨对照自己平日的使用习惯和运用场景,看看有没有可以改进或变化的地方。最后,因为我本人现在最习惯和喜欢的是用Interface Builder(之后简称IB)及xib来做UI,所以文末附上了一些IB使用时候的小技巧,算是做个总结。

继续阅读

image

免费+应用内购买的模式已经被证明了是最有效的盈利模式,所以实现内购功能可能是很多开发者必做的工作和必备的技能了。但是鉴于内购这块坑不算少,另外因为sandbox测试所需要特定的配置也很多,所以对于经验不太多的开发者来说很容易就遇到各种问题,并且测试时出错Apple给出的也只有“Can not connect iTunes Store”或者”Invalid Product IDs”之类毫无价值的错误提示,并没有详细的错误说明,因此调试起来往往没有方向。有老前辈在这里整理过一个相对完整的check list了,但是因为年代已经稍微久远,所以内容上和现在的情况已经有一些出入。趁着在最近两个项目里做内购这块遇到的新问题,顺便在此基础上总结整理了一份比较新的中文Check list,希望能帮到后来人。

如果您在实现和测试iOS应用内购的时候遇到问题,可以逐一对照下面所列出的条目,并逐一进行检查。相信可以排除大部分的错误。如果您遇到的问题不在这个列表范围内,欢迎在评论中指出,我会进行更新。

  • 您是否在iOS Dev Center中打开了对应应用AppID的In-App Purchases功能?登陆iOS Dev Center的Certificates, Identifiers & Profiles下,在Identifiers中找到正在开发的App,In-App Purchase一项应当显示Enabled(如果使用Xcode5,可以直接在Xcode的Capabilities页面中打开In-App Purchases)。
  • 您是否在iTunes Connect中注册了您的IAP项目,并将其设为Cleared for Sale?
  • 您的plist中的Bundle identifier的内容是否和您的AppID一致?
  • 您是否正确填写了Version(CFBundleVersion)和Build(CFBuildNumber)两个数字?两者缺一不可。
  • 您用代码向Apple申请售卖物品列表时是否使用了完整的在iTC注册的Product ID?(使用在IAP管理中内购项目的Product ID一栏中的字符串)
  • 您是否在打开IAP以后重新生成过包含IAP许可的provisioning profile?
  • 你是否重新导入了新的包含IAP的provisioning profile?建议在Organizer中先删掉原来设备上的老的provisioning profile。
  • 您是否在用包含IAP的provisioning profile在部署测试程序?在Xcode5中,建议使用General中的Team选项来自动管理。
  • 您是否是在模拟器中测试IAP?虽然理论上说模拟器在某些情况下可以测试IAP,但是条件很多也不让人安心,因此您确实需要一台真机来做IAP测试。
  • 您是在企业版发布中测试IAP么?因为企业版没有iTC进行内购项目管理,也无法发布AppStore应用,所以您在企业版的build中不能使用IAP。
  • 您是否将设备上原来的app删除了,并重新进行了安装?记得在安装前做一下Clean和Clean Build Folder。
  • 您是否在运行应用前将设备上实际的Apple ID登出了?建议在设置->iTunes Store和App Stroe中将使用中的Apple ID登出,以未登录状态进入应用进行测试。
  • 你是否使用的是Test User?如果你还没有创建Test User,你需要到iTC中创建。
  • 您使用的测试账号是否是美国区账号?虽然不是一定需要,但是鉴于其他地区的测试账号经常抽风,加上美国区账号一直很稳定,因此强烈建议使用美国区账号。正常情况下IAP不需要进行信用卡绑定和其他信息填写,如果你遇到了这种情况,可以试试删除这个测试账号再新建一个其他地区的。
  • 您是否有新建账户进行测试?可能的话,可以使用新建测试账户试试看,因为某些特定情况下测试账户会被Apple锁定。
  • 您的应用是否是被拒状态(Rejected)或自己拒绝(Developer Rejected)了?被拒绝状态的应用的话对应还未通过的内购项目也会一起被拒,因此您需要重新将IAP项目设为Cleared for Sale。
  • 您的应用是否处于等待开发者发布(Pending Developer Release)状态?等待发布状态的IAP是无法测试的。
  • 您的内购项目是否是最近才新建的,或者进行了更改?内购项目需要一段时间才能反应到所有服务器上,这个过程一般是一两小时,也可能再长一些达到若干小时。
  • 您在iTC中Contracts, Tax, and Banking Information项目中是否有还没有设置或者过期了的项目?不完整的财务信息无法进行内购测试。
  • 您是在越狱设备上进行内购测试么?越狱设备不能用于正常内购,您需要重装或者寻找一台没有越狱的设备。
  • 您是否能正常连接到Apple的服务器,你可以访问Apple开发者论坛关于IAP的板块,如果苹果服务器正down掉,那里应该有热烈的讨论。

如果您正在寻找一份手把手教你实现IAP的教程的话,这篇文章不是您的菜。关于IAP的实现和步骤,可以参考下面的教程:

iOS7中的ViewController切换

这是我的WWDC2013系列笔记中的一篇,完整的笔记列表请参看这篇总览。本文仅作为个人记录使用,也欢迎在许可协议范围内转载或使用,但是还烦请保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS邮件方式订阅本站,这样您将能在第一时间获取本站信息。

本文涉及到的WWDC2013 Session有

  • Session 201 Building User Interfaces for iOS 7
  • Session 218 Custom Transitions Using View Controllers
  • Session 226 Implementing Engaging UI on iOS

毫无疑问,ViewController(在本文中简写为VC)是使用MVC构建Cocoa或者CocoaTouch程序时最重要的一个类,我们的日常工作中一般来说最花费时间和精力的也是在为VC部分编写代码。苹果产品是注重用户体验的,而对细节进行琢磨也是苹果对于开发者一直以来的要求和希望。在用户体验中,VC之间的关系,比如不同VC之间迁移和转换动画效果一直是一个值得不断推敲的重点。在iOS7中,苹果给出了一套完整的VC制作之间迁移效果的方案,可以说是为现在这部分各种不同实现方案指出了一条推荐的统一道路。

iOS 7 SDK之前的VC切换解决方案

在深入iOS 7的VC切换效果的新API实现之前,先让我们回顾下现在的一般做法吧。这可以帮助理解为什么iOS7要对VC切换给出新的解决方案,如果您对iOS 5中引入的VC容器比较熟悉的话,可以跳过这节。

继续阅读

这是我的WWDC2013系列笔记中的一篇,完整的笔记列表请参看这篇总览。本文仅作为个人记录使用,也欢迎在许可协议范围内转载或使用,但是还烦请保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS邮件方式订阅本站,这样您将能在第一时间获取本站信息。

本文涉及到的WWDC2013 Session有

  • Session 206 Getting Started with UIKit Dynamics
  • Session 217 Exploring Scroll Views in iOS7

UIScrollView可以说是UIKit中最重要的类之一了,包括UITableView和UICollectionView等重要的数据容器类都是UIScrollView的子类。在历年的WWDC上,UIScrollView和相关的API都有专门的主题进行介绍,也可以看出这个类的使用和变化之快。今年也不例外,因为iOS7完全重新定义了UI,这使得UIScrollView里原来不太会使用的一些用法和实现的效果在新的系统中得到了很好的表现。另外,由于引入了UIKit Dynamics,我们还可以结合ScrollView做出一些以前不太可能或者需要花费很大力气来实现的效果,包括带有重力的swipe或者是类似新的信息app中的带有弹簧效果聊天泡泡等。如果您还不太了解iOS7中信息app的效果,这里有一张gif图可以帮您大概了解一下:

iOS7中信息app的弹簧效果

这次笔记的内容主要就是实现一个这样的效果。为了避免重复造轮子,我对这个效果进行了一些简单的封装,并连同这篇笔记的demo一起扔在了Github上,有需要的童鞋可以到这里自取。

iOS7的SDK中Apple最大的野心其实是想用SpriteKit来结束iOS平台游戏开发(至少是2D游戏开发)的乱战,统一游戏开发的方式并建立良性社区。而UIKit Dynamics,个人猜测Apple在花费力气为SpriteKit开发了物理引擎的同时,发现在UIKit中也可以使用,并能得到不错的效果,于是顺便革新了一下设计理念,在UI设计中引入了不少物理的概念。在iOS系统中,最为典型的应用是锁屏界面打开相机时中途放弃后的重力下坠+反弹的效果,另一个就是信息应用中的加入弹性的消息列表了。弹性列表在我自己上手试过以后觉得表现形式确实很生动,可以消除原来列表那种冷冰冰的感觉,是有可能在今后的设计中被大量使用的,因此决定学上一学。

首先我们需要知道要如何实现这样一种效果,我们会用到哪些东西。毋庸置疑,如果不使用UIKit Dynamics的话,自己从头开始来完成会是一件非常费力的事情,你可能需要实现一套位置计算和物理模拟来使效果看起来真实滑润。而UIKit Dynamics中已经给我们提供了现成的弹簧效果,可以用UIAttachmentBehavior进行实现。另外,在说到弹性效果的时候,我们其实是在描述一个列表中的各个cell之间的关系,对于传统的UITableView来说,描述UITableViewCell之间的关系是比较复杂的(因为Apple已经把绝大多数工作做了,包括计算cell位置和位移等。使用越简单,定制就会越麻烦在绝大多数情况下都是真理)。而UICollectionView则通过layout来完成cell之间位置关系的描述,给了开发者较大的空间来实现布局。另外,UIKit Dynamics为UICollectionView做了很多方便的Catagory,可以很容易地“指导”UICollectionView利用加入物理特性计算后的结果,在实现弹性效果的时候,UICollectionView是我们不二的选择。

如果您在阅读这篇笔记的时候遇到困难的话,建议您可以看看我之前的一些笔记,包括今年的UIKit Dynamics的介绍和去年的UICollectionView介绍

继续阅读

Unity Shader教程

关于本系列

这是Unity3D Shader入门指南系列的第二篇,本系列面向的对象是新接触Shader开发的Unity3D使用者,因为我本身自己也是Shader初学者,因此可能会存在错误或者疏漏,如果您在Shader开发上有所心得,很欢迎并恳请您指出文中纰漏,我会尽快改正。在之前的开篇中介绍了一些Shader的基本知识,包括ShaderLab的基本结构和语法,以及简单逐句地讲解了一个基本的shader。在具有这些基础知识后,阅读简单的shader应该不会有太大问题,在继续教程之前简单阅读一下Unity的Surface Shader Example,以检验您是否掌握了上一节的内容。如果您对阅读大部分示例Shader并没有太大问题,可以正确地指出Shader的结构,声明和使用的话,就说明您已经准备好继续阅读本节的内容了。

法线贴图(Normal Mapping)

法线贴图是凸凹贴图(Bump mapping)的一种常见应用,简单说就是在不增加模型多边形数量的前提下,通过渲染暗部和亮部的不同颜色深度,来为原来的贴图和模型增加视觉细节和真实效果。简单原理是在普通的贴图的基础上,再另外提供一张对应原来贴图的,可以表示渲染浓淡的贴图。通过将这张附加的表示表面凸凹的贴图的因素于实际的原贴图进行运算后,可以得到新的细节更加丰富富有立体感的渲染效果。在本节中,我们将首先实现一个法线贴图的Shader,然后对Unity Shader的光照模型进行一些讨论,并实现一个自定义的光照模型。最后再通过更改shader模拟一个石头上的积雪效果,并对模型顶点进行一些修改使积雪效果看起来比较真实。在本节结束的时候,我们就会有一个比较强大的可以满足一些真实开发工作时可用的shader了,而且更重要的是,我们将会掌握它是如何被创造出来的。

继续阅读

iOS7的后台多任务特性

这是我的WWDC2013系列笔记中的一篇,完整的笔记列表请参看这篇总览。本文仅作为个人记录使用,也欢迎在许可协议范围内转载或使用,但是还烦请保留原文链接,谢谢您的理解合作。如果您觉得本站对您能有帮助,您可以使用RSS邮件方式订阅本站,这样您将能在第一时间获取本站信息。

本文涉及到的WWDC2013 Session有

  • Session 204 What’s New with Multitasking
  • Session 705 What’s New in Foundation Networking

iOS7以前的Multitasking

iOS的多任务是在iOS4的时候被引入的,在此之前iOS的app都是按下Home键就被干掉了。iOS4虽然引入了后台和多任务,但是实际上是伪多任务,一般的app后台并不能执行自己的代码,只有少数几类服务在通过注册后可以真正在后台运行,并且在提交到AppStore的时候也会被严格审核是否有越权行为,这种限制主要是出于对于设备的续航和安全两方面进行的考虑。之后经过iOS5和6的逐渐发展,后台能运行的服务的种类虽然出现了增加,但是iOS后台的本质并没有变化。在iOS7之前,系统所接受的应用多任务可以大致分为几种:

  • 后台完成某些花费时间的特定任务
  • 后台播放音乐等
  • 位置服务
  • IP电话(VoIP)
  • Newsstand

在WWDC 2013的keynote上,iOS7的后台多任务改进被专门拿出来向开发者进行了介绍,到底iOS7里多任务方面有什么新的特性可以利用,如何使用呢?简单来说,iOS7在后台特性方面有很大改进,不仅改变了以往的一些后台任务处理方式,还加入了全新的后台模式,本文将针对iOS7中新的后台特性进行一些学习和记录。大体来说,iOS7后台的变化在于以下四点:

  • 改变了后台任务的运行方式
  • 增加了后台获取(Background Fetch)
  • 增加了推送唤醒(静默推送,Silent Remote Notifications)
  • 增加了后台传输(Background Transfer Service)
继续阅读

Unity Shader教程

动机

自己使用Unity3D也有一段时间了,但是很多时候是流于表面,更多地是把这个引擎简单地用作脚本控制,而对更深入一些的层次几乎没有了解。虽然说Unity引擎设计的初衷就是创建简单的不需要开发者操心的谁都能用的3D引擎,但是只是肤浅的使用,可能是无法达到随心所欲的境地的,因此,这种状况必须改变!从哪里开始呢,貌似有句话叫做会写Shader的都是高手,于是,想大概看看从Shader开始能不能使自己到达的层次能再深入一些吧,再于是,有了这个系列(希望我能坚持写完它,虽然应该会拖个半年左右)。

Unity3D的所有渲染工作都离不开着色器(Shader),如果你和我一样最近开始对Shader编程比较感兴趣的话,可能你和我有着同样的困惑:如何开始?Unity3D提供了一些Shader的手册和文档(比如这里这里这里),但是一来内容比较分散,二来学习阶梯稍微陡峭了些。这对于像我这样之前完全没有接触过有关内容的新人来说是相当不友好的。国内外虽然也有一些Shader的介绍和心得,但是也同样存在内容分散的问题,很多教程前一章就只介绍了基本概念,接下来马上就搬出一个超复杂的例子,对于很多基本的用法并没有解释。也许对于Shader熟练使用的开发者来说是没有问题,但是我相信像我这样的入门者也并不在少数。在多方寻觅无果后,我觉得有必要写一份教程,来以一个入门者的角度介绍一些Shader开发的基本步骤。其实与其说是教程,倒不如说是一份自我总结,希望能够帮到有需要的人。

所以,本“教程”的对象是

  • 总的来说是新接触Shader开发的人:也许你知道什么是Shader,也会使用别人的Shader,但是仅限于知道一些基本的内建Shader名字,从来没有打开它们查看其源码。
  • 想要更多了解Shader和有需求要进行Shader开发的开发者,但是之前并没有Shader开发的经验。

当然,因为我本身在Shader开发方面也是一个不折不扣的大菜鸟,本文很多内容也只是在自己的理解加上一些可能不太靠谱的求证和总结。本文中的示例应该会有更好的方式来实现,因此您是高手并且恰巧路过的话,如果有好的方式来实现某些内容,恳请您不吝留下评论,我会对本文进行不断更新和维护。

继续阅读