懒，基本上是每个程序员同学公有的特性。也就是因为懒才造就了现在众多先进的发明，才让我们的生活省时省力起来。写这篇文章，也是因为自己犯懒，不想总是重复性的干一些固定的工作，所以通过脚本来完成。文章主要介绍了Xcodeproj这个Ruby的工具包，为了使用这个工具包我还现学现卖了Ruby这门语言，算是个入门级选手了吧，其实真的没有想象中的那么复杂。 如果已经是能够熟练使用Xcodeproj的选手，就可以不用继续往下看了。^_^

CF对象与NS对象互转

在ARC下，如果我们需要操作一些底层的库，有时会用到Core Foundation的对象，简称CF对象，例如Core Graphic、Core Text。在ARC下，这些CF的对象的内存是不会被自动管理的，而是需要我们在它的生命周期结束的时候调用CFRelease()释放它。

CF对象与NS对象之间如何相互转换呢？系统提供了bridge,bridge_retained,__bridge_transfer 三个关键字给我们使用。

苹果于2016年5月4日告知开发者应用需要在6月1日前支持IPv6-only,也就是说在 6 月 1 日后发布的新版本是需要支持 IPv6-only。

原文地址：https://developer.apple.com/news/?id=05042016a

首先看下图

其中蓝色部分的高级API，其实都已经帮我们做好了IPv6的支持，我们使用的大多数第三方网络库也都是基于这些高级API的，所以这里我们不需要做什么改动。 需要注意的是下面的红色部分的底层的socket API需要做出适配支持。

SafeKit一般指那些被用来防止App crash的类库或者方案，常见的方式有通过method swizzling替换系统方法，或者通过消息转发机制将无法响应的方法都转发给一个可以handle任何消息的对象身上等。通过这些方式都可以将·常见数组越界、unrecognized selector sent to instante 0xXXXXXXXX等crash类型在App内部自身得到消化处理，从而将程序的crash率降到一个可以接受的范围内。

在我刚刚开始写Objective-C代码的时候，觉得这是一种非常好的编程方式，应该大力推崇，能够极大地降低crash率，想怎么写代码就怎么写代码，妈妈再也不担心我的程序会crash了。但是，后来渐渐发现这并不是一种很好的解决方案，它其实是一把双刃剑。在给我们带来便利的同时也给我们带来了一些不利的地方。这就是本次讨论的主题慎用或者不用SafeKit类似物。

上一篇Part 2只介绍了第一个技术点alignment和distribution的约束如何添加和管理的alignment这一部分的内容，这一篇继续介绍distribution的约束添加和管理。

同样的在介绍实现之前，我先介绍一下StackView的各种distribution模式都是什么效果的：

写完了Part 1就被接踵而至的新项目和新版本忙的不可开交，转眼间一个季度就已经过去了，而这篇Part 2却迟迟还没有出现。实在是抱歉没有及时更新。不过有一个好消息就是FDStackView已经被使用在我们自己的项目中，并且我们的项目也已经经过了两个版本的迭代，FDStackView可以说还是相当稳定的，并且可以顺利的通过苹果的审核机制，对这方面有顾虑的小伙伴们可以放心大胆的使用了。同时我们也将它的版本号从1.0-alpha升级到1.0。在此感谢一下各位热心的小伙伴们在Github上提出的issue,以及着重感谢下@里脊串对FDStackView的重度使用及提出的各种隐晦的bug。后续我们将会对性能的优化做出改进，以及对Layout Margins的支持。

回到主题，这篇文章主要介绍StackView的实现，即如何通过现有AutoLayout技术实现StackView这样的一个控件。这里说明一下，当初我们编写FDStackView的时候，UIStackView还没有支持Layout Margins，所以我们也没有添加Layout Margins的支持，不过目前的iOS SDK已经增加了这一部分的支持，所以在打开layoutMarginsRelativeArrangement属性的情况下，StackView创建出的约束会与我后面所介绍的内容有一些出入，不过问题不大，仅仅是部分约束的firstItem由StackView本身变成UILayoutGuide的区别。

实现StackView主要包括这几个技术点：

• alignment和distribution的约束如何添加和管理；
• spacing和distribution的关系及约束的创建；
• 子视图的隐藏显示如何处理；
• 子视图的intrinsicContentSize发生变化时如何处理。

加入百度知道团队也有一段时间了，能跟@我就叫Sunny怎么了、@sinojerk等小伙伴一起工作生活是一种极赞的体验。在完成日常业务开发之余，我们也会进行一些技术研究项目，并将研究结果以开源的方式公布出来，自然我也成为了forkingdog开源小组的一员。

近期我们的研究项目是FDStackView，现如今已经完成了Alpha版本的开发工作，并将其开源在了Github上，项目地址。虽然现在已经完成所有的基本功能，但是仍需要在真实的环境中测试试用，欢迎大家将试用之后的问题反馈给我们，提issue给我们，使我们更好的修复和完善FDStackView，以便于更好的方便开发者们使用。

使用AutoLayout时，在iOS7和iOS8上两者会有很大的不同，iOS8苹果优化了很多。最近看了一篇bolg，是Reveal的工程师写的介绍使用Constraints以及transform变幻之后在iOS78上的异同。

Cocoapods是非常好用的一个iOS依赖管理工具，使用它可以方便的管理和更新项目中所使用到的第三方库，以及将自己的项目中的公共组件交由它去管理。Cocoapods的介绍及优点本文就不在赘述，我开始使用Cocoapods还是在两年前，那个时候它刚刚出现，网上的资料还非常的少，就连他们自己的HomePage都十分的简单，我就着手尝试着使用了一下，用它管理起第三方库确实是十分的方便顺手。后来它有了更强大的功能就是自己创建podspec，更可以设置私有的库。

春节回来上班，一天的工作结束之后，需要充实下自己，正好项目中有一些公共组件需要从庞大的项目体系中剥离出来，而且年前项目终于从SVN迁移到了Git，真是喜大普奔，大快人心！这样项目使用Cocoapods就有了条件，正好学习一下创建私有的podspec并在项目中部署使用，以及pods的subspec的创建及使用。

最近项目在搞适配，目前的适配原则是不改变既有的设计图的设计样式，使用@3x的图片去进行完美适配。即不涉及到某一个模块在iPhone5及以下的设备上是一个展示样式，在iPhone6或着iPhone6 Plus上是另外的一个展示样式。单纯是这样的需求通过Auto Resizing和AutoLayout就完全可以应付的了。以前硬编码写的view的frame通过乘上一个屏幕放大的比例系数也可以搞定。

可是目前设计同学提出在一个使用collection view的页面中，之前是通过各种设备使用同一个大小的cell，不同的屏幕上拉大的是cell之间的间距来进行适配。现如今要改成只有在6 Plus上要将cell上半部分等比例放大，cell中下半部分的文字的字号也放大。目前的需求就是这个样子，其实我觉得这样适配就不是苹果的设计规范，按道理说屏幕大了看的内容多才对，这样搞个等比例放大，跟没有适配在兼容模式下运行的效果似地。不过需求来了还是得搞。