《喵神-王巍博客》读书笔记，开发篇（4）

新浪微博：东门兜

《开发者所需要知道的iOS7 SDK新特性》：
UI相关：全新UI设计、UIKit的力学模型（UIKit Dynamics）
游戏方面：Sprite Kit Framework、Game Controller Framework、GameCenter改进
多任务强化：后台应用运行和多任务新特性
AirDrop：UIActivityViewController
地图：MKMapCamera、MKDirections、MKGeodesicPolyline、MKMapSnapshotter
Inter-App Audio 应用间的音频：AudioUnit
点对点连接 Peer-to-Peer Connectivity：MultipeerConnectivity
Store Kit Framework：
最后一个好消息是，苹果放慢了废弃API的速度，这个版本并没有特别重要的API被标为Deprecated，Cheers。

《WWDC 2013 Session笔记 - Xcode5和ObjC新特性》：
说说新的Xcode：界面变化、更易用的版本管理、方便的工程配置、资源管理，Asset Catalog和Image Slicing、新的调试和辅助功能
Image Slicing可以帮助开发者用可视化的方式完成resizable image，之后通过拖拖线就可以完成sliced image，而不必再写代码，也不用再一次次尝试输入的insets合不合适了。
关于Objective-C，Modules和Autolinking
Modules相当于将框架进行了封装，然后加入在实际编译之时加入了一个用来存放已编译添加过的Modules列表。如果在编译的文件中引用到某个Modules的话，将首先在这个列表内查找，找到的话说明已经被加载过则直接使用已有的，如果没有找到，则把引用的头文件编译后加入到这个表中。这样被引用到的Modules只会被编译一次，但是在开发时又不会被意外使用到，从而同时解决了编译时间和引用泛滥两方面的问题。
1、资源文件的Show Slicing按钮
2、鼠标悬浮提示
3、内存检测Cmd+6

《WWDC 2013 Session笔记 - UIKit Dynamics入门》：
什么是UIKit动力学（UIKit Dynamics）：
将2D物理引擎引入了人UIKit。

那么，应该怎么做呢：
view受到重力影响而下降
view掉到地板的时候产生碰撞
模拟一个drag物体然后drop后下落的过程

UIAttachmentBehavior 描述一个view和一个锚相连接的情况，也可以描述view和view之间的连接。
UISnapBehavior 将UIView通过动画吸附到某个点上。
UIPushBehavior 可以为一个UIView施加一个力的作用，这个力可以是持续的，也可以只是一个冲量。
UIDynamicItemBehavior 其实是一个辅助的行为，用来在item层级设定一些参数，比如item的摩擦，阻力，角阻力，弹性密度和可允许的旋转等等

UIKit力学的物理学分析
如果将1单位的UI力学中的力等同于1牛顿的话：
1000单位的UI质量，与现实世界中1kg的质量相当，即一个点等同一克；
屏幕的100像素的长度，约和现实世界中0.99米相当（完全可以看为1米）
UI力学中的默认密度，约和现实世界的0.1kg/m^2 相当

UIKit动力学自定义
对于第一种，其实考虑一下上面的重力+边界碰撞，或者drag & drop行为，其实都是两个甚至多个行为的叠加。将它们打包封装一下。
另一种比较高级一点，需要对计算完全定义。

UIKit动力学的性能分析和限制

《WWDC 2013 Session笔记 - SpriteKit快速入门和新时代iOS游戏开发指南》：
什么是SpriteKit：
Sprite的中文译名就是精灵，在游戏开发中，精灵指的是以图像方式呈现在屏幕上的一个图像。这个图像也许可以移动，用户可以与其交互，也有可能仅只是游戏的一个静止的背景图。塔防游戏中敌方源源不断涌来的每个小兵都是一个精灵，我方防御塔发出的炮弹也是精灵。可以说精灵构成了游戏的绝大部分主体视觉内容，而一个2D引擎的主要工作，就是高效地组织，管理和渲染这些精灵。
SpriteKit是基于场景（Scene）来组织的，每个SKView（专门用来呈现SpriteKit的View）中可以渲染和管理一个SKScene，每个Scene中可以装载多个精灵（或者其他Node，之后会详细说明），并管理它们的行为。
知道么，游戏的本质是什么？就是一堆能动的图像！
SKNode是SpriteKit中要素的基本组织方式，它代表了SKView中的一种游戏资源的组织方式。我们现在接触到的SKScene和SKSprite都是SKNode的子类，而一个SKNode可以有很多的子Node，从而构成一个SKNode的树。在我们的例子中，MyScene直接加在SKView中作为最root的node存在，而英雄或者敌人的精灵都作为Scene这个node的子node被添加进来。SKAction和node上的各种属性的的作用范围是当前这个node和它的所有子node。
在iOS传统的view的系统中，view的内容被渲染一次后就将一直等待，直到需要渲染的内容发生改变（比如用户发生交互，view的迁移等）的时候，才进行下一次渲染。这主要是因为传统的view大多工作在静态环境下，并没有需要频繁改变的需求。而对于SpriteKit来说，其本身就是用来制作大多数时候是动态的游戏的，为了保证动画的流畅和场景的持续更新，在SpriteKit中view将会循环不断地重绘。

《猫都能学会的Unity3D Shader入门指南（一）》：
Unity3D的表面着色器。

《WWDC 2013 Session笔记 - iOS7中的多任务》：
在iOS7之前，系统所接受的应用多任务可以大致分为几种：
后台完成某些花费时间的特定任务、后台播放音乐等、位置服务、IP电话（VoIP）、Newsstand

iOS7的多任务

后台任务

对于开发者来说，这个改变更多的是系统层级的变化，对于非网络传输的任务来说，保持原来的用法即可，新系统将会按照新的唤醒方式进行处理；而对于原来在后台做网络传输的应用来说，苹果建议在iOS7中使用NSURLSession，创建后台的session并进行网络传输，这样可以很容易地利用更好的后台传输API，而不必受限于原来的时长。

后台获取（Background Fetch）

设置为UIApplicationBackgroundFetchIntervalMinimum的话，系统会尽可能多尽可能快地为你的应用进行后台获取，但是比如对于一个天气应用，可能对实时的数据并不会那么关心，就完全不必设置为UIApplicationBackgroundFetchIntervalMinimum，也许1小时会是一个更好的选择。
这些时间对于fetch一些简单数据来说是足够的了，比如微博的新条目（大图除外），接下来一小时的天气情况等。如果涉及到较大文件的传输的话，用后台获取的API就不合适了，而应该使用另一个新的文件传输的API。

后台获取的调试

推送唤醒（Remote Notifications）

Apple将限制此类推送的频率，当频率超过一定限制后，带有content-available标志的推送将会被阻塞，以保证用户设备不被频繁唤醒。按照Apple的说法，这个频率在一小时内个位数次的推送的话不会有太大问题。
后台获取更多地使用在泛数据模式下，也即用户对特定数据并不是很关心，数据应该被更新的时间也不是很确定，典型的有社交类应用和天气类应用；而静默推送或者是推送唤醒更多地应该是用户感兴趣的内容发生更新时被使用，比如消息类应用和内容型服务等。根据不同的应用情景，选择合适的后台策略（或者混合使用两者），以带给用户绝佳体验，这是Apple所期望iOS7开发者做到的。

后台传输（Background Transfer Service）

很多这种时候，用户会想要是在下载的时候能切到别的应用刷刷微博或者玩玩游戏，然后再切回来的就已经下载完成了的话，该有多好。iOS7中，这可以实现了。
想要实现后台传输，就必须使用iOS7的新的网络连接的类，NSURLSession。
你的应用到现在为止只是在后台运行，想要提醒用户传输完成的话，也许你还需要在这个时候发送一个本地推送（记住在这个时候你的应用是可以执行代码的，虽然是在后台），这样用户可以注意到你的应用的变化并回到应用，并开始已经准备好数据和界面。
后台传输非常适合用于文件，照片或者追加游戏内容关卡等的下载，如果配合后台获取或者静默推送的话，相信可以完全很多很有趣，并且以前被限制而无法实现的功能。

《猫都能学会的Unity3D Shader入门指南（二）》：
Mark

《WWDC 2013 Session笔记 - iOS7中弹簧式列表的制作》：
UIKit Dynamics中已经给我们提供了现成的弹簧效果，可以用UIAttachmentBehavior进行实现。另外，在说到弹性效果的时候，我们其实是在描述一个列表中的各个cell之间的关系，对于传统的UITableView来说，描述UITableViewCell之间的关系是比较复杂的（因为Apple已经把绝大多数工作做了，包括计算cell位置和位移等。使用越简单，定制就会越麻烦在绝大多数情况下都是真理）。而UICollectionView则通过layout来完成cell之间位置关系的描述，给了开发者较大的空间来实现布局。另外，UIKit Dynamics为UICollectionView做了很多方便的Catagory，可以很容易地“指导”UICollectionView利用加入物理特性计算后的结果，在实现弹性效果的时候，UICollectionView是我们不二的选择。

《WWDC 2013 Session笔记 - iOS7中的ViewController切换》：
iOS 7 自定义ViewController动画切换：实现自下向上的弹性转场动画。
手势驱动的百分比切换：实现手势滑动转场动画。
关于iOS 7中自定义VC切换的一些总结
自定义切换并不改变VC的组织结构，只是负责提供view的效果，因为VC切换将动画部分、动画驱动部分都使用接口的方式给出，因此重用性非常优秀。在绝大多数情况下，精心编写的一套UIView动画是可以轻易地用在不同的VC中，甚至是不同的项目中的。

《iOS内购实现及测试Check List》：
免费+应用内购买的模式已经被证明了是最有效的盈利模式，所以实现内购功能可能是很多开发者必做的工作和必备的技能了。

《代码手写UI，xib和StoryBoard间的博弈，以及Interface Builder的一些小技巧》：
在UI制作上大家逐渐分化为了三种主要流派：使用代码手写UI及布局；使用单个xib文件组织viewController或者view；使用StoryBoard来通过单个或很少的几个（关于这点稍后会进行展开）文件构建全部UI。
代码手写UI：代码UI可以说具有最好的代码重用性，使用代码最终一定能够完成所要的需求。码手写UI的劣势同时也是最明显的，主要就是一个字：慢。这不仅在前期极为浪费时间，在之后维护时代码定位和寻找也会很痛苦。
Xibs：相对于代码，使用IB和xib文件来组织UI，可以省下大量代码和时间，从而得到更快的开发速度。xib设计的一大目的其实是为了良好的MVC。在使用xib时，辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视，如果选择xib，那么要尽量将xib的工作和代码的工作隔离开来：能够使用xib完成的内容就统一使用xib来做，而不要说三个Label其中两个在xib设置了字体而另一个却在代码中完成。尽量仅保持必要的、较少的IBOutlet和IBAction会是一个好方法。
StoryBoard：一种可行的做法是将项目的不同部分分解成若干个StoryBoard，并安排开发人员对自己的部分进行负责。简单举例比如一个有4个tab功能相互独立的基于UITabBarViewController的应用，完全可以使用4个StoryBoard来分别代表4个tab，并在相互无干扰的情况下完成开发。
对于前者，在正确封装接口以及良好设计的基础上，其实StoryBoard的VC重用与代码的VC重用是没有本质区别的，在StoryBoard中添加封装良好需要重用的Scene即可解决。而对于后者，因为StoryBoard中已经不允许有单个view的存在，因此很多时候我们还是需要借助于单个的xib来自定义UI。
我的观点和选择：在我尝试了几次使用StoryBoard制作demo之后，我已经决定在之后的项目转向使用StoryBoard。
一些IB小技巧：同时添加多个outlet、可视化坐标距离、在一组view层次中进行选择、添加辅助线。

《宏定义的黑魔法 - 宏菜鸟起飞手册》：
对象宏

#define M_PI 3.14159265358979323846264338327950288

函数宏

#define PLUS(x,y) x + y

//Version 3.0
#define MIN(A,B) ((A) < (B) ? (A) : (B))
Log，永恒的主题
当然在这里还是需要重新批评一下认为if后的单条执行语句不加大括号也没问题的同学，这是陋习，无需理由，请改正。不论是不是一条语句，也不论是if后还是else后，都加上大括号，是对别人和自己的一种尊重。

#define NSLogRect(rect) NSLog(@"%s x:%.4f, y:%.4f, w:%.4f, h:%.4f", #rect, rect.origin.x, rect.origin.y, rect.size.width, rect.size.height)#define NSLogSize(size) NSLog(@"%s w:%.4f, h:%.4f", #size, size.width, size.height)#define NSLogPoint(point) NSLog(@"%s x:%.4f, y:%.4f", #point, point.x, point.y)NSLog(@"%@", NSStringFromCGRect(rect)); NSLog(@"%@",     NSStringFromCGSize(size)); NSLog(@"%@",     NSStringFromCGPoint(point));