iOS的网络框架（HTTP）
背景和目标目前市场上的大部分App都有网络功能，而网络功能大部分都是基于HTTP协议的。HTTP协议简单而又强大，这也是该协议长盛不衰的秘诀之一。每一个程序员都最好了解一下HTTP协议，这会让你受益匪浅。 协议规范(英) 协议规范(中) 回到iOS，我们将如何使用HTTP协议来完成网络请求呢？从头开始开发一个协议栈是重复造轮子，非常不明智。因为苹果的开发框架中已经包含了对HTTP协议的封装。请看官方文档说明
主页
iOS代码中的不良实践与优化
不良实践的根源 项目时间紧，没有时间去思考更好的写法 认为花精力去优化代码结构不值得 第一种原因，一般是因为经验不足，通过学习，任何人都可以很本能的写出结构良好的代码。至于时间确实很紧，后面总会重构的时间。 第二种原因，我觉得要分项目看。如果只是第一个试水版本，没有问题。但是作为一个长久项目，千万不能抱有这种观点。不仅害己，更是害人。 最近做了一个项目，由于种种原因，我们的代码有很多问题。因为正在做重构，所以就把一些不良的实践总结出来。希望对大家有所帮助。
ARC转换总结+避免循环引用
参考 上面的文章写得已经非常全面了，不过还是有些东西需要补充一下。 循环引用循环引用和ARC没有直接关系，但是在转换的过程中遇到了相关问题，所以就着重说明一下。 循环引用的原因任何一种语言，都必须有它的内存管理方式。比如C语言中，我们用malloc申请一块内存，放入数据。当这块内存不在需要时，就调用free将其释放掉。这是一种比较原始的方式，当同一块内存在多个地方被用到时，到底应该由谁来释放呢？你只能小心翼翼的处理这种问题，除此之外没有别的办法。
iOS技术路线图
做技术分成好几个层次： 第一层：把功能做出来，不用考虑代码质量。 第二层：把功能做稳定，不会有太多的bug。 第三层：把功能做得快，能够快速响应需求。 如果是从零开始做项目，迫于经验不足和时间紧迫，都会经历从第一层慢慢向上的过程。遗憾的是，做到第三层是很难的，但不管怎样，追求的过程是充满挑战的，也是受益无穷的。 评价一下我们现在的项目，还应留在第一层。为了能够达到第三层，我和同事们一起想了一些方法和步骤。
iOS架构设计与分层
结构设计的层次是否越多越好？多人都会说，凡事不能走极端，走了极端就过犹不及。所以应该分层，但不能过分分层，应该视具体情况来定。这样的话听起来很有道理，却只是一句废话。当我们遇到问题时，还是摸不着头脑！ 看看知名的架构师是怎么说的吧！来自蔡学镛 我做（开发）架构的几个原则，根据优先次序高低排列：1. （逻辑）拆分越细越好 2. 依赖关细越少越好 3. 交互越少越好 … 相互矛盾时，如果没有特殊理由，以优先权高者胜出。 由此启发，我觉得设计架构应该拆的越细越好。这样做有如下几点好处： 对于大中型软件，层次越多，每一层就更单纯，更容易维护。 团队成员只需了解一小部分业务，就能顺利进行开发。 相对底层的模块，可以更好的重用。 层次分的越多，开发者对抽象的理解就更深入。 iOS说到分层，有几种常见的做法。 按功能分：有MVC，MVVM…… 按层次分：有数据层、逻辑层、展现层……
Objective-C代码规范
为什么要有代码规范？对于团队，如果代码风格不统一，阅读或修改同事的代码会非常困难，造成潜在的风险。 对于个人，代码规范是对自身编码习惯的一种监督，如果没有这种监督，有时候因为偷懒，会写出难看的代码，时间长了自己都看不懂。这样对于代码的维护性是不利的。 代码规范的内容？代码规范包含的范围十分广泛。从一个变量的命名到一个类的设计，我觉得都属于代码规范的范畴。从实践的角度，可以把代码规范分成两个部分： 第一部分是规则，即一定要这么做。这里面没有对错，但需要统一。包含变量的命名、函数的命名、模块的组织、代码块的组织、宏、枚举、常量的声明、函数的粒度。 第二部分是风格，即一种模式化的代码设计结构。我们实现某个功能时，往往不止一种实现方式。每一种实现方式没有绝对的高低之分，不同角度的解读，就会有不同的偏好。所以这个层面上的代码规范，只能求同存异。但是不管怎样，每个人必须要有一致性的风格。就像不同的小区可以有不同的风格，但同一个小区只能有一种设计风格。风格包含代码设计中的抽象概念，比如接口、继承等等。