一直以来我都认为在 ARC 下，给 Cocoa 框架的集合类，如 NSArray，添加 Block 类型的元素时，Block 是会被编译器自动执行 copy 操作的。而且一直以来的实践也验证了这一事实。但今天在测试如下一段代码时出现了问题。

做网页前端的同学有时为了减少 Http 的请求数量，经常会把一些需要重复使用并且比较小的图片根据 Data URI 协议，经 base64 编码成字符串格式来储存。

有这样一个场景。现在想给一个 ViewController 容器增加一个手势，触发前进后退的导航功能。正常情况下，这里用 UIPanGestureRecognizer 就可以了。但是存在一个问题，如果当前界面有一个可以左右滑动的 ScrollView 时，比如是一个被双指放大了的 WebView，那么所加的这个 pan 手势就会被 ScrollView 的内部手势 (UIScrollViewPanGestureRecognizer 类型) 给屏蔽掉而不会被触发。于是这里又添加了两个 UIScreenEdgePanGestureRecognizer 边缘滑动手势，以在上述情况下通过触发边缘滑动手势进行前进后退导航。这时问题就来了，这几个手势势必会存在冲突问题 (其实真实项目中这里还有一个自定义的上下滑动手势，不过这里就先不提它了，主要说说上述两个手势的冲突问题)。下面就来解决这个问题。

虽然现在已经有很多第三方的服务能帮你分析线上 App 的 Crash 文件，但有时还是难免要对单独某个 Crash 文件做分析，本文就是来介绍一下这个流程。

自动释放池块提供了一种机制，通过它我们在放弃一个对象的所有权时，可以避免该对象被立即释放掉(就像从一个方法返回一个对象那样)。通常情况下不需要创建自己的自动释放池的，但有些特殊情况就必须或者说有必要这样做。

虽然上篇文章中所介绍的基本概念简单明了，但仍有一些实用的套路可使内存管理更加简单，而且能帮忙确保在最大限度得减少资源需求的同时，程序依然能够可靠健壮得运行。

在引用计数环境下用于内存管理的基本模型，是由 NSObject protocol中所定义的一些方法，结合一套标准的方法命名约定共同提供的。NSObject 类还定义了一个dealloc方法，该方法会在对象被释放时自动调用。本文将讲解在 Cocoa 编程中所需了解的关于正确进行内存管理的基本规则，并提供一些正确用法的示例。

不论哪门编程语言，内存管理都一直是一个广受关注的问题，包括有垃圾回收机制的 Java (前几天还听几个搞 Android 的小伙伴在热切的讨论 Java 中的内存管理)。作为有节操的 iOS 开发者，大家对内存管理问题更是时刻保持着高度的使命感。这两年新开的项目可能都已经使用 ARC ( Automatic Reference Counting )了。想想自己刚从 MRR ( manual retain-release ) 往 ARC 过渡那会儿，虽然苹果官方一再强调可以放心得使用 ARC，但由于在 ARR 下谨慎惯了，一时还是不太敢放心的把内存管理全都交给编译器去做。现在再看 ARC，确实是个可以放心托付的家伙，而且它在编译器级对内存管理做了更进一步的优化。其实当苹果在 Xcode 中内置了强大的静态分析器( Clang Static Analyzer )时我就想，既然内存泄漏隐患都能在编译阶段这么精准得定位到，为什么不更进一步直接把它们解决了呢。后来果然不久苹果就推出了强大的 ARC 机制，直接帮开发者把内存管理的事儿给做了，真是家强大的公司。虽然在 ARC 下不用太过多的关注内存管理问题，但是对 OC 的内存管理机制有一个深刻的理解还是非常有必要的，而且有时你也可能不得不去维护由于历史原因还在使用 MRR 的项目。

众所周知，Git 是目前最优秀的版本控制工具。但很多团队在使用Git进行协作开发的过程中，并没有形成一个清晰规范的流程。本文的作者 Vincent Driessen 向我们介绍了一个相对比较完美的分支管理策略，依照这个策略基本可以保证团队开发和版本发布有条不紊得进行。Vincent Driessen还据此实现了一个 Git 扩展集 git-flow ，它为本文所介绍的分支管理模型提供了一些较高层次的repository operations(库操作)。其本质是对下文所述的相关Git命令集进行进一步封装，并提供一些友好的命令行提示，具体可参考 git-flow 备忘清单。本文译自 A successful Git branching model ，推荐原汁原味的阅读。

博客搭建起来后，总感觉默认的 classic 主题有些呆板，而且字体太大，阅读体验不是很好。于是就尝试着更改下主题。把 Octopress 的推荐主题浏览了一遍后发现 Greyshade 的效果还不错。但是安装后发现该主题有些细节还是不尽如人意，比如字体大小、行高、代码高亮背景，等等。经过一番调试后总算基本满意了，但是用移动设备打开后，顿时碎了。它的样式对移动设备真是差劲，比如代码高亮字体大小不一、左右滑动后右边有一条不窄的黑边并且消不去、左侧边栏在 iPad 上不能很好的适应，等等等等。相比之下 Octopress 的默认主题对移动设备的支持就要好太多，几乎完美，而且由于样式不花哨，很好的突出了内容主体。也许这就是这个主题的设计初衷吧，以内容为主体，淡化样式。对于博客来说，阅读体验才是重中之重，而且在这个移动互联网的时代，对移动设备的支持也必须到位。出于以上考虑，我又换回了默认的 classic 主题，但决定对其进行个性化改造。