移动设备的内存是一块共享资源。内存管理不恰当的APP会内存使用暴增，严重的性能损耗，甚至崩溃。

Facebook的iOS版APP功能庞大繁多，但在iOS只有相同的内存使用空间。如果任何一个功能消耗了过多的内存，则会影响整个APP的性能。而这个当一个功能出现内存泄漏时是有极大可能性发生的。

当我们给对象分配一块内存后，当使用完对象但忘了释放对象占用的内存，这就会造成内存泄漏，这意味着操作系统没法回收内存来给其他功能使用，最终可能导致APP超过允许使用的内存极限。

Facebook的工程师们在代码库不同的模块下进行开发工作，造成内存泄漏情况出现很难避免，如果发现内存泄漏，我们需要快速地找到内存泄漏的地方，然后快速修复他们。

已经有不少工具可以用来查找内存泄漏了。但是他们通常都需要太多的手动操作：

1.打开Xcode，然后 build for profiling.

2.启动Instruments

3.开始测试APP，尽可能测试每个APP使用场景。

4.观察内存是否泄漏或者内存暴增

5.在代码中找出问题所在

6.修复内存泄漏元凶

这意味着需要大量的重复手工操作，因此我们很难抽出时间在开发阶段定位和修复内存泄漏问题。

如果能自动化这个流程那就太棒了，这样我们就不需要太多的工程师参与就能更快速的定位内存泄漏问题。为了搞定这个目标，我们开发了一套工具，并且已经帮我们修复了代码库的大量问题。现在我们非常开心地宣布我们将开放这些工具：FBRetainCycleDetector, FBAllocationTracker和FBMemoryProfiler.

循环引用

Objective-C使用引用计数的方式来管理内存和决定是否释放对象。内存里的任何一个对象都可以持有其他对象，如果前者依然持有后者，那后者就一直在在内存中，我们可以理解为前者“拥有”后者。
大部分时候不会出现内存问题。但是某些情况就不是这么回事了，会出现某种所谓的”僵局“，比如两个对象通过直接互相“拥有”彼此，或者间接通过其他对象互相持有。这种循环拥有就是所谓的循环引用了。

循环引用会带来许多问题。幸运的话，这些循环引用的对象可能只是小对象，一直只是浪费一丁点内存。如果这些对象做了一些重要的操作并消耗大量内存的话，那可能意味着其他功能就只能使用剩下的内存了。倒霉的话，程序会因为的内存使用超出限制导致APP崩溃。
在手工使用profile时，我们发现了大量的循环引用问题，这些问题非常容易产生，但却非常难以发现。使用循环引用发现器的话这些困难都不算事了。

在运行时（runtime）发现循环引用

查找循环引用有点像在有向非循环图(directed acyclic graph)查找循环问题，对象就是节点，边线就是对象之间的引用（因此如果对象A持有对象B，就存在A到B的引用）。我们的OC对象已经在图表中了，我们需要做的就是使用深度优先查找（depth-first）遍历图表。

这个抽象比喻非常好的解释查找内存的工作。我们需要确定是否想节点一样使用对象，并且每个对象，我们能获取到它引用的所有其他对象，这种引用要么是抢引用要么是若引用。循环引用只在强引用之间产生，因此每个对象我只需要找出它的强引用。

非常幸运，OC提供了强大的、内省（译者注：仔细观察的意思）的（introspective）运行时（runtime）库，来帮助我们发觉这张图表。

图表的节点可能是对象也是可能是block，让我们分别介绍如何来遍历他们。

对象

运行时有很多工具帮助我们内观（introspect）对象，并从中学习。

我们要做的第一件事是获取对象的实例变量的布局（ivar layout）。

1
2
3

const char *class_getIvarLayout(Class cls);
const char `*class_getWeakIvarLayout(Class cls);

对于对象，实例变量的布局描述了我们在哪儿可以找到其他对象的引用。它会提供给我们一个索引（index），这代表我们需要在对象地址上添加一个偏移量(offset)，就可以得到它所引用的对象的地址。运行时也允许我们获取“弱引用实例变量布局(weak ivar layout)”。
这也部分支持Objective-C中，我们可以在结构体中定义对象，但是这不会在实例变量布局中获取到。运行时提供了“类型编码(type encoding)”来处理这个问题。对于每一个实例变量来说，类型编码描述了变量是如何结构化的。如果这是一个结构体，它会描述它包含了哪些字段和类型。我们计算出它们的偏移量，在图中，找出它们所指向的对象。
也有一些边缘条件我们不会深入。大部分是一些不同的集合，我们不得不列举它们去获得它们持有的对象，这可能会导致一些副作用。

Block

Block和对象有一点不一样。运行时不会让我们很轻易的看到它们的布局，但是我们仍然可以猜个大概。
在处理Block的时候，我们使用了Mike Ash在他的项目Circle中提出的思路：Circle最早启发了FBRetainCycleDetector的项目。
我们可以使用的是Block应用程序二进制接口(ABI,application binary interface for blocks)。它描述了Block在内存中的样子。如果我们知道我们在处理的引用是一个Block,我们可以把它投射成一个模仿该Block特征的虚构的结构体中。在放到一个C语言的结构体之后，我们就可以知道该Block所持有的对象了。可是，我们不知道这些引用是强引用还是弱引用。
我们使用了一个黑盒技术来搞定这个问题。我们创建一个对象来假扮我们想要查找的Block。因为我们知道Block的接口，我们知道在哪可以找到Block持有的引用。我们伪造的对象用“释放检测器(release detectors)”来代替这些引用。释放检测器是一些很小的对象，它们会观察发送给它们的释放消息，当持有者放弃持有时，释放消息会发送给强引用对象。当我们释放伪造对象时，我们可以检测哪些检测器接收到了这些消息。只要知道哪些索引在伪造的对象的检测器中，我们就可以找到原来Block中实际持有的对象了。

自动化

这个工具牛逼之处，就实在在程序员写代码的时候它会自动运行并持续检查内内存问题。

客户端的自动化方式很简单。我们在定时器上安装了一个循环引用检查器，并定期扫描内存来发现循环引用问题。当然有出现过一些小问题。当我们第一次运行检测器时，发现它不能足够快地检查所有内存空间，因此我们需要给它一组候选对象来进行检测。

为了更有效地解决这个问题，我们开发了FBAllocationTracker。这个工具会主动跟踪所有NSObject子类的创建和释放。它可以随时获取任何类的任何实例，并且性能消耗微不足道。

客户端的自动化内存检查只要在NSTimer上使用FBRetainCycleDetector，再用FBAllocationTracker来抓取实例来配合跟踪就行了。现在，让我们来仔细看看内部具体会发生什么。

循环引用可以包含任何数量的对象。一个坏的连接会导致很多环的时候，这就复杂了。

A->B是一个糟糕的连接，因为由于它导致了两个循环引用A-B-C-D and A-B-C-E。
这就导致了两个问题产生：
1.我们不想因为同一个坏引用把这个两个循环引用进行独立开来标记。
2.我们不想把两个循环引用放在一起处理，尽管他们有相同的连接，但他们事实上不同的循环引用。

因此我们需要为循环引用定义簇（clusters）。我们根据一下规则写了一个算法来查找这些问题：
1.汇总指定日期查找到的所有循环引用
2.为每个环，命名一个Facebook格式的类名
3.为每个环，找到该环内被汇报的最小的环
4.将上面的原则将环添加到一个组
5.只汇报最小的环

有了这些工具之后，最后一步就是找到导致循环引用的工程师。我们在造成环的代码部分使用‘git/hd指责’（’git/hg blame’），推测最新修改这部分代码的工程师导致了这个问题。因此这个工程师收到任务去修复这个问题。这个系统工作原理可以如图所示：

手动性能分析

虽然自动化有助于简化发现循环引用的过程，降低人员的消耗，手动性能分析依然有它的用武之地。我们创建的另一个工具允许任何人查看内存使用，甚至不需要把他的手机插到电脑上。
FBMemoryProfiler可以很容易的添加到任何应用程序，可以让你手动配置构建文件，可以让你在应用程序内运行循环应用检测。它会借用FBAllocationTracker和FBRetainCycleDetector来实现此功能。

代(Generations)

FBMemoryProfiler最屌的特性在于它提供了“代跟踪”，类似苹果Instruments的代跟踪。代用来快照两次事件标记之间的所有存活对象。

使用FBMemoryProfiler的UI进行操作，比如分配三个对象后我们可以标记一个代，然后继续分配更多对象再标记一个代，第一个代包含开始的三个对象，如果任何一个对象释放了，它就从第二个代里移除了。

:

当我们有一个重复的任务，它可能会内存泄露的时候，生成代追踪是很有用的，例如，导航View Controller的进出。在每次开始我们的任务的时候，我们标记一个代，然后，对之后的每个生成代进行调查。如果一个对象不应该活这么长时间，我们可以在FBMemoryProfiler界面清楚地看到。

欢迎检出(checkout)来用

不管你的APP大小，功能多还是少，好的内存管理意味着好的工程质量标配。有了这些工具，我们能更容易发现内存泄漏的问题，我们可以花更少的时间去手动处理这些问题，然后就有时间写更好的代码啦。希望喜欢这些工具，去github上检出这些工具试试看吧FBRetainCycleDetector, FBAllocationTracker和FBMemoryProfiler。

原文

《Automatic memory leak detection on iOS》

前言

iOS系统采取引用计数的方式进行内存管理，这也是为什么iOS系统和APP更流畅的一个原因，，它给了开发者更精确控制对象在内存中的生命周期的机会，让APP对内存的消耗有机会控制到最低，提高响应速度。在iOS5之后，新增了ARC（自动引用计数），这让开发者从复杂的内存管理中解放出来，更专注于业务的开发，只是更而已，内存管理你依然是ios项目十分关心的点。我们可能会在项目结束后，统一用instruments工具对ios项目的内存和CPU使用情况进行测试。这是一个很复杂又很难得工作量，初中级开发工程师，可能也没有这个和耐心去一一解决开发中的内存问题，高级开发又希望能从这类问题中抽身去做更重要的事情。那要怎么办呢？要怎么样利用技术手段解决ios大型项目的内存管理呢？如何让开发工程师更顺利的开发业务，而不是动不动需要关注内存释放问题呢，又能保证项目的内存使用在一个理想的状态呢？能不能内存管理方式更加容易，而不需要单独额外的时间专门去内存泄露问题的检查？恩，这就本文将要给大家揭晓的答案。

我不是要讲iOS系统中的内存管理原理，我是要从架构层面去介绍如何设计方案，能够让ios项目的内存管理变得及其容易，对开发透明，助力ios开发工程师专注于业务开发的同时提高项目内存管理质量。

内存泄露自动化管理技术方案：MLeaksFinder找出内存泄露的对象

利用MLeaksFinder工具检查内存泄露问题
以前我的团队项目会让所有的viewController，继承一个DellocViewController,然后复写dealloc方法，在里面打印一下控制器释放日志，这确实可以发现viewController的释放问题，然后加以解决，但是这让项目仅仅为了监控内存释放多了一层继承关系，而且这也只能监控controller的内存泄露问题，但是view的释放问题是没办法监控的，我曾经因为控制器的tableView持有一个picker，而picker持有tableView导致通知键盘通知没有释放的崩溃问题，解决这个问题了花了好几天时间。

本文给大家介绍一款有weRead团队开发的一款棒棒的内存泄露检查工具MLeaksFinder。MLeaksFinder 目前能自动检测 UIViewController 和 UIView 对象的内存泄露，而且也可以扩展以检测其它类型的对象。

MLeaksFinder 具备以下优点：

1. 使用简单，不侵入业务逻辑代码，不用打开 Instrument
2. 不需要额外的操作，你只需开发你的业务逻辑，在你运行调试时就能帮你检测
3. 内存泄露发现及时，更改完代码后一运行即能发现（这点很重要，你马上就能意识到哪里写错了）
4. 精准，能准确地告诉你哪个对象没被释放
   这篇文章不会对MLeaksFinder做细节介绍，而是更侧重于介绍利用技术方案解决内存管理的问题。关于MLeaksFinder的介绍可以阅读MLeaksFinder的官方博文吧。《MLeaksFinder：精准 iOS 内存泄露检测工具》

   查找内存泄露对象的循环引用链方案：FBRetainCycleDetector

   Facebook 在前阵子开源了一个循环引用检测工具 FBRetainCycleDetector。当传入内存中的任意一个 OC 对象，FBRetainCycleDetector 会递归遍历该对象的所有强引用的对象，以检测以该对象为根结点的强引用树有没有循环引用。
   我们知道，很多循环引用是 block 的使用不当造成的。而 FBRetainCycleDetector 最大的技术亮点，正在于如何找出一个 block 的所有强引用对象。对于这个感兴趣的，可以看 facebook 的这篇文章。
   然而，FBRetainCycleDetector 的使用存在两个问题：
   需要找到候选的检测对象
   检测循环引用比较耗时
   正是由于这两个问题，FBRetainCycleDetector 通常是结合其它工具一起使用，通过其它工具先找出候选的检测对象，然后进行有选择的检测。当 MLeaksFinder 与 FBRetainCycleDetector 结合使用时，正好能达到很好的效果。我们先通过 MLeaksFinder 找到内存泄漏的对象，然后再过 FBRetainCycleDetector 检测该对象有没有循环引用即可。
   循环引用的输出信息如下：

1
2
3
4
5
6

{
(
    "-> MyTableViewCell ",
    "-> _callback -> __NSMallocBlock__ "
)
}

上面的信息表示，MyTableViewCell 有一个强引用的成员变量 _callback，该变量的类型是NSMallocBlock，在 _callback 里，又强引用了 MyTableViewCell 造成循环引用。

在团队项目中使用这个两个方案管理内存问题

在PodFile文件添加

1
2

pod 'MLeaksFinder', '~> 0.2.0'
pod 'FBRetainCycleDetector', '~> 0.1.3'

当UIViewController和UIView对象内存泄漏时，MLeaksFinder会负责发现它，然后弹出一个一个内存泄露警告，然后点击查看循环引用，它会调用FBRetainCycleDetector框架查看对象的循环引用情况。就很快能定位到泄露的问题了。

前言

深深的喜欢这篇文章《iOS各种调试技巧》的写作风格，读起来就是那么愉快，文章有内容有价值，而且作者这么用心为大家写，推荐大家阅读这篇文章。写文章就是用来读的啊。我们开发者写产品要有为用户考虑的态度才能做出好产品；写文章要有为读者服务的态度才能让读者喜欢；做好工作也要有给同事给领导排忧解难的的公仆态度才对。你可能要问了，人家写了那么好的有关调试的文章，你干嘛还要写调试的文章，多此一举啊？你要是有这想法啊，我就得说您幼稚了，作者我混迹江湖这么多年，怎么这会考虑不到呢，主要是觉得《iOS各种调试技巧》只能算是一个调试技巧的笼统介绍，其实里面的每一种调试技巧都值得深入讲解，而且有些调试技巧他的文章也没有提到，比如这篇文章要讲的reveal调试，但我希望能借鉴他这篇文章的写作风格，希望带给读者轻松的阅读体验。

作为iOS开发者为什么需要学会使用reveal

1.相比xcode自带的视图调试（下文简称XcodeVD），reveal强大的不是一丁点。
比如，XcodeVD会有部分信息不显示，还有布局显示不精确，而reveal则表现好很多。
XcodeVD下的表现：

reveal下的表现：

大家可以注意看看，XcodeVD中显示的文本被挡住了挡住了耶，这怎么受得了，如果读者您眼尖，相信您已经注意到reveal显示的视图层次结构提供的信息更丰富，比如显示了文本的内容（中文内容信息），而xcode不仅仅需要您眼尖，还需要您能智慧过人聪明绝顶的去猜测一个UILabel对应模拟器上的哪个Label,蛋疼吗？不疼只能说明您牛逼。

2.相比xcodeVD只能看看之外，reveal可以修改视图的属性，并实时在模拟器（真机）上显示变化。（当然只是临时修改的属性，不会修改工程的实际代码，如果真实修改，还是需要修改的工程源代码的）。

在reveal中修改UILabel的属性

而XcodeVD几乎什么也干不了，只能看看，咳。

3.reveal最强大的一点是可以通过它查看和分析别伦家的App视图元素构成和布局。（牛逼波？这是reveal最有价值的部分，如果您觉得这个信息有价值，你西不西应该打赏我一下）。
下图是我特地为了读者您去偷窥了下携程这个美妞，（如果读者您是携程的，请您留情，不要笑我太疯癫，我只笑他人看不穿（😄））。

好了，您如果看到这里，我相信您已经迫不及待想要去学会如何使用reveal，我知道您不是因为喜欢偷窥而去学的，您只是单纯的爱好学习。

如何在Mac上安装Reveal

1.作为国人我知道您不喜欢轻易付费
reveal破解和安装：在简书上看到这篇文章《Reveal 1.6.2最新版 破解教程》,大家照着做就好，如果您笨到搞不定（或者聪明到想利用时间专注做好开发和产品，而不是这些非核心的学习上），您可以付费咨询我（打赏金额：￥10+）。
2.您是愿意的付费的小众？
直接去官网下载然后购买吧 http://revealapp.com/ 你要是肯花钱买，我真的为您点个赞，您是有钱的主，您顺便顺个手也给我打赏打赏吧，嗯。

如何在项目中集成Reveal

1.reveal官方有中文集成的教程。介绍了静态库、动态库、cocoapod的安装方法（这三种建议选这种）自行查看吧：
http://support.revealapp.com/kb/getting-started/reveal
上面的集成方式多少需要在我们的工程项目中加入一些代码，可能有些同事并不想使用这玩意，所以应该在团队中慎用。
2.下面这个方法不需要在工程中加入任何代码就可以使用：
http://support.revealapp.com/kb/getting-started/revealxcodereveal
3.一劳永逸的最佳集成玩法：
http://blog.ittybittyapps.com/blog/2013/11/07/integrating-reveal-without-modifying-your-xcode-project/
第三种集成的高级玩法有点复杂，如果你只想用好reveal而不想浪费时间去学如何集成，或者同样您可能笨到没搞定（哈哈，不是侮辱您啊，我也很笨，笨有笨的优点啊，比如学习有耐性和长性，我就研究了两天才研究明白），同样可以付费咨询我：（20元打赏+）。

在自己的项目中使用Reveal

一、基本使用
本文的重点是教大家如何使用Reveal，这部分只能有请我闪亮登场（掌声响起来），亲自出马搞了，关于Reveal的中文教程真的太少，不信你搜搜看看，基本都是一些重复且看了等于没看的垃圾文章。像作者我这样认认真真给老外当搬运工的人都不多见。
1.如果您安装reveal顺利，打开reveal应该是看到大致如下图这样的界面：

2.如果您搞定了集成，那你可以在模拟器（真机）上运行您项目程序，然后就可以reveal的左上角选择该模拟器（真机）了。

3.刷新界面
当您在模拟器上操作您的APP，你可能发现reveal没有及时更新，这个它确实做不到，您可以像2提到的再选择一次模拟，或者按下Command+R,还可以点击右上角的刷新图标：

Reveal 界面和功能介绍

Reveal界面主要分为三个部分：

1.左侧层级面板：界面层级关系区域，用于显示当前界面元素的结构树。

如果你多查看几个APP，就会发现他们的根都是UIScreen,然后是UIWindow，然后还有几个我们都不了解的UIKit封装类，如：

• 1）UINavigationTransitionView：导航控制器在这里发生转场行为的容器视图。
• 2)UIViewControllerWrapperView: 包含view controller 的view属性的封装视图。
  总之这些我们不了解的视图我们(biè)管就对了。

2.中央可视化面板：可视化查看区域， 用于显示当前界面的布局效果（2D/3D）

在顶部有是三个控件。

• 1）显示样式分段控件。从左至右可以让视图显示三种状态：只显示视图边界frame，不显示内容；只显示内容不显示边界frame；边界frame和内容都显示。
• 2）中间的选择器控制器可以选择视图尺寸大小，它的值是视图内容和模拟器内容的大小正比值。
• 3）最右侧的开关控制可以选择显示3D效果还是2D效果。默认为3D效果。

在3D模式下，点击空白区域然后上下左右拖动，视图也跟着您的拖动方向三地旋转和3D展示。

3.右侧属性面板：控件详细参数区域，用于当前选中控件的参数展示（可以修改并 实时反应到可视化查看区域）

如图所示，包含以下5个功能。

• 1）程序观察器Application Inspector。主要显示和程序相关的全局属性。
• 2）对象观察器Identity Inspector。主要显示选中对象的先关属性，如父类信息，自身类名信息，内存地址信息等。
• 3）属性观察器Attributes Inspector。我知道您聪明，这些都知道。可是我就是要告诉您一遍：这里展示和选中对象相关属性的信息。您能拿我怎么着（O(∩_∩)O哈哈）。
• 4）布局观察器Layout Inspector。这里可以查看选中对象的frame,bounds，自动布局特性相关信息。
• 5）图层观察器Layer Inspector。

自动布局的调试（这部分的内容是从这里搬运）

自动布局（Auto Layout）已经越来越普遍的深入千家万户了，随着iOS设备分辨率的多(sui)样(pian)化，自动布局已慢慢成为了标准配置。
你可能经常看到控制台输出类似这样的内容，而不知何处下手：

Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints)
(
"<NSLayoutConstraint:0x7fc82d3e18a0 H:[UIView:0x7fc82aba1210(768)]>",
"<NSLayoutConstraint:0x7fc82d6369e0 H:[UIView:0x7fc82aba1210]-(0)-| (Names: '|':UIView:0x7fc82d6b9f80 )>",
"<NSLayoutConstraint:0x7fc82d636a30 H:|-(0)-[UIView:0x7fc82aba1210] (Names: '|':UIView:0x7fc82d6b9f80 )>",
"<NSLayoutConstraint:0x7fc82d3e7fd0 'UIView-Encapsulated-Layout-Width' H:[UIView:0x7fc82d6b9f80(50)]>"
)
Will attempt to recover by breaking constraint\<NSLayoutConstraint:0x7fc82d3e18a0 H:UIView:0x7fc82aba1210(768)>
Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKit/UIView.h> may also be helpful.

除了我们在编码时自己绑定到View上的约束条件(Constraints)之外，其实许多UIKit控件还会被隐式地地设置上一些约束，而这些可能会带来一些意外的布局结果。

也许曾经你需要使用LLDB来一点点调试Auto Layouts：

(lldb) po 0x7731880
$0 = 124983424 <UIView: 0x7731880; frame = (90 -50; 80 100);
layer = <CALayer: 0x7731450>>
(lldb) po 0x7731880 superview$2 = 0x07730fe0 \<UIView: 0x7730fe0; frame = (32 128; 259 604);layer = \<CALayer: 0x7731150>>
(lldb) po [[0x7731880 superview] recursiveDescription]
$3 = 0x07117ac0 <UIView: 0x7730fe0; frame = (32 128; 259 604); layer = <CALayer: 0x7731150>>
| <UIView: 0x7731880; frame = (90 -50; 80 100); layer = <CALayer: 0x7731450>>
| <UIView: 0x7731aa0; frame = (90 101; 80 100); layer = <CALayer: 0x7731c60>>
有了Reveal，这就方便多了。Reveal对视图上的约束条件提供了相当丰富的检视与实时修改功能，具体看下面这张图，再自己摸索一下就好了。

• a显示/隐藏所有约束条件
• b 查看关联到此View的所有约束
• c 可以直接在Canvas中选中某一约束
• d 查看某一约束的具体信息，可以实时修改constant属性，立刻检查效果
• e 跳转到某一约束的详细属性页面

给大家透露一个我摸索到的十分特别以及及其重要的知识：蓝色的约束代表系统给对象添加的约束，紫色的约束是我们开发者给对象添加的约束。恩，这个在您调试布局冲突时很重要。不谢，打赏我就对了，我不是雷锋，我不会武功，我不会飞檐走壁，也不会饿着肚子写文章。

实时修改View属性

Reveal不仅仅只是查看各种属性的工具，也支持实时的修改一些属性。如下图中的大部份属性，你都可以实时的在模拟器中看到修改后的效果。这省去了过去总是要修改代码，重新编译运行这个漫长的反馈流程。在和设计师一起尝试各种显示效果时，这个功能特别高效。

Reveal偷窥正确姿势

（部分内容搬运，接受鄙视，但是我是让文章有深度需要的勤快的搬运工，和普通搬运工可以区别开来好嘛，O(∩_∩)O）（您错过以下内容，我只能呵呵了）
温馨提示：前方高能，越过难度有点大，如果遇到头晕脑胀、眼神绝望，请尽快逃离现场。如果您依然十分想要偷窥，又不想费时费力，最好的解决办法依然是打赏我拉，小的带您坐缆车，飞速直达目的地。（打赏￥50+）。
1.越狱你的iOS设备：可以利用盘古、PP助手、太极等三方工具一键越狱。这部分内容请自行搜索。
2.iOS设备越狱完成后，需要使用Cydia
安装两个软件：OpenSSH 和CydiaSubstrate
安装OpenSSH，打开越狱后的设备上的Cydia程序，点击搜索输入OpenSSH，然后点击安装。（下面的配图是已经安装成功后搜索的显示画面）

SSH是一种可以保证用户加密远程登录到系统的协议，OpenSSH是一个SSH的连接传输工具。

安装Cydia Substrate，打开越狱后的设备上的Cydia程序，点击搜索输入Cydia Substrate，然后点击安装。只有安装了CydiaSubstrate之后才会有MobileSubstrate目录（此目录必须存在才可以继续下面的步骤）。（下面的配图是已经安装成功后搜索的显示画面）

MobileSubstrate是一个公共库，可以用来动态替换内存中的代码、数 据等。基本上越狱机下比较有用的系统工具都需要这个库，是Cydia同一个作者 维护的，可以放心装。

3.将libReveal.dylib上传到越狱后的设备的/Library/MobileSubstrate/DynamicLibraries下检查工作：测试OpenSSH和CydiaSubstrate是否安装成功

• 1）上传libReveal.dylib文件必须使用到上面安装的OpenSSH工具。如果想要使用OpenSSH工具，那么就必须将Reveal软件所在的mac设备与越狱后的iOS设备置于同一个局域网内。

• 2）首先来测试OpenSSH是否安装成功。获取越狱后的设备的局域网内的IP地址，打开“设置”->“WLAN”，连上局域网，然后再点击连接上的局域网查看iOS设备的IP地址。
  

• 3）打开mac上的终端工具(Terminal)，输入如下命令：ssh root@iOS设备IP地址。输入完成后回车，等待连接iOS设备。

iOS设备的IP地址指的是越狱后的设备（iphone、ipad）的IP地址，也就是上个步骤中获取的IP地址，后面的教程中出现的地址仅仅是代表笔者测试时iOS设备的IP地址(192.168.2.2)，读者请一定要查看自己的iOS设备地址，并进行替换。

4）接下来会提示你输入root用户的密码，iOS设备root用户的默认密码是alpine，在终端中输入密码时，终端不会显示你输入的字符，所以只需要输入alpine字符后回车就可以请求连接iOS设备了。（这一步请保证你的iOS设备屏幕已经解锁，不然不会出现输入密码的提示！）

如果出现root#字符就表示连接成功了。

接下来测试Cydia Substrate 是否安装成功，上一步已经连接上iOS设备的终端中输入以下命令：cd /Library/MobleSubstrate/DinamicLibraries
，回车查看返回结果。如果出现-sh: cd: /Library/MobileSubstrate/DynamicLibraries: No such file or directory
提示那就说明Cydia Substrate安装不成功，不成功请重新进入iOS设备上下载安装Cydia Substrate软件。
若果没出现如何错误提示信息，就说明Cydia Substrate安装成功！

4.上传libReveal.dylib。如果上一个步骤的检查工作全部完成：OpenSSH和Cydia Substrate成功安装。
重新打开mac上的终端工具(Terminal)，使用如下命令进入Reveal软件的动态库所在目录：cd /Applications/Reveal.app/Contents/SharedSupport/iOS-Libraries

使用如下命令将libReveal.dylib上传到iOS设备的/Library/MobileSubstrate/DynamicLibraries目录下：scp libReveal.dylib root@iOS设备IP地址:/Library/MobileSubstrate/DynamicLibraries/
，请替换@之后的“iOS设备的IP地址”为你的iOS设备的真实地址，回车执行命令后会让你输入iOS设备的root的密码，默认是alpine，上传成功后会显示%100字样。

5.编写并上传一份libReveal.plist
到iOS设备的/Library/MobileSubstrate/DynamicLibraries
目录中。这个文件的作用是：在Reveal中监控指定的App，不上传这个文件也是可以的，那么Reveal就会监控所有的App，只是这样速度会慢一点点。编写libReveal.plist文件，最简单的方法就是新建一个plist文件，它的内容是
Filter = { Bundles = ( “你要查看的app的bundle Id1”,”你要查看的app的bundle Id2” ); ; }

xcode下打开这个libReveal.plist文件可以看到它的结构示例（笔者已经添加了两个Bundle ID）：

关于获取iOS App应用的Bundle ID：打开PP助手、iTools、itunes等工具，备份手机上安装到的程序到电脑上(或直接下载需要查看程序ipa文件)，将.ipa修改成.zip，解压后按如下路径进入info.plist文件所在目录，打开info.plist其中便有我们需要的bundle Id。

6.上传libReveal.plist
到iOS设备的/Library/MobileSubstrate/DynamicLibraries
目录中。打开终端进入libReveal.plist所在的目录，使用如下命令上传：scp libReveal.plist root@iOS设备的IP地址:/Library/MobileSubstrate/DynamicLibraries/，请替换@之后的“iOS设备的IP地址”为你的iOS设备的真实地址，回车执行命令后会让你输入iOS设备的root的密码，默认是alpine，上传成功后会显示%100字样。

7.接下来在重启你的iOS设备，连上mac电脑所在的局域网，上打开你需要在Reveal中观察的程序，此时在mac电脑上的Reveal中选择你要观察的程序。

提示：如果此时在mac上的Reveal左上方没有出现你想要调试的程序，这里给出几个检查的建议：

• 1.手机连接的wifi是否与mac处于同一局域网（如果你在执行步骤7时是在正确执行步骤5和6之后，那就忽略这个检查，这里是针对手机重启了或者是切换了手机网络等情况）。
• 2.查看你编写的libReveal.plist文件中写的BundleID是否与你在iOS设备上打开的应用是否匹配。甚至，请检查你的pist文件结构是否正确！
• 3.iOS设备上想要观察的App应用必须处于前台，进入后台即使打开了，在Reveal的左上角“选择连接的应用”框中也不会显示。

  补充

  欢迎收藏的 我的博客

前言

最近哥们我比较痴迷于琢磨如何利用技术手段，提高项目代码的可维护性，不要嫌弃我烦啊，往往知识就藏在细微之中啊，现在APP的竞争那是相当的激烈，你做的比别人好那么一点点，也许剩者就是你了，有木有，想不想做王，肯定的是不是，那就好好琢磨一些别人不去关注的细节吧。

前面我已经写过几篇代码规范的文章，也讲到了利用clangFormatForXcode来统一代码规范配置，从而标准格式化团队代码。如果您还没看到过，推荐你去看看，推荐理由：因为是我写的。

clangFormat能解决代码一遍编写规范错误问题，比如方法的第一个括号与方面名之间有一个空格，并且不换行的这样的规范问题clangFormat能帮我们快速发现并自动处理。但是……如果写的代码如果结构和选型有问题，它就像个白痴了，一丁点忙也帮不上。所以我后面还会有几篇文章介绍一些技术手段来解决方法选型问题，比如制作代码模板 (Code Template)来帮助团队开发人员编写规范的代码结构、用OCLint给iOS代码做静态分析等，是不是迫不及待想学习这些知识呢？不过今天不能如你愿，我又没挣你的钱，所以我只负责自己写自己想写的，不好意西啦。

人应该都是懒惰的吧，优秀程序员也是人好嘛。只是优秀程序员会思考如何偷懒又能达成目标，而普通程序员就是想着偷懒，甚至都懒得想，只是单纯的偷懒而已。最近哥哥我又跳了一个新坑——中国平安。TMD，好几天的生命要浪费在配置开发环境上。我决定以后不用公司电脑了，用自己的，恩，努力多挣钱。相信很多iOS开发者都多少有些自己的代码片段，但是，但是肯定不全，因为懒得去制作代码片段，也懒得去收集。作为优秀程序员的我呢，跟尔等比就是勤奋这么一点点，所以在配置新的开发环境时，我决定把自己以前的代码片段，以及网上收集了不少很不错的代码片段总结出来，分享给大家，恩，你不用说，其实我就是IT界的雷锋。github地址：《XcodeSnippetsForObjective-C》

如何使用XcodeSnippetsForObjective-C

需要你先装一个Xcode插件——ACCodeSnippetRepositoryPlugin插件。下载地址：https://github.com/acoomans/ACCodeSnippetRepositoryPlugin，怎么装插件不用我教了吧，你要是不会可以付费咨询我。具体安装和使用参考github的官方介绍吧。

这次你先这么使用吧，我回头有时间把这个细节的文章整理下，然后做一个脚本把这些工具和规范都自动搞定，恩。

XcodeSnippetsForObjective-C主要包含的代码片段介绍

1.常用property创建的片段

2.常见的ENUM、UITableViewDataSource/Delegate、PickerViewDataSourceDelegate、UICollectionViewDataSource/Delegate等片段创建

3.常见的singleton、init、initialize、kvo等方法片段的创建

4.其他常用片段的创建

XcodeSnippetsForObjective-C的后期维护

这个片段github仓库我会长期维护，也欢迎朋友提交你认为对大家有价值的代码片段上来。

关于XCode代码片段的制作和使用

这部分国内文章也不少，大家自行查找吧，我这顺手找了一篇：《iOS 开发偷懒小技巧：自定义 XCode 代码片段
》

总结

等着有时间制作一个脚本，把所有规范代码的技术工具，一次性用脚本在项目中部署。

参考

《Xcode Snippets》

前言

代码就是程序员的面子，你要面子波？中国人都爱面子，所以好好写一辈子优雅的代码呗。写代码这事就像生个孩子，您总不希望辛辛苦苦生的娃，被您养成了废物吧，不知道读者您是不是，反正我要是养了个废物还不如死了算了（shuoshuoeryi）。所以自觉点。

上文是对个人的要求的，我相信对自己有要求的程序员是会听的。但是在团队里，每个程序员写代码的态度是不同的，写代码的风格也是不同的，即使同一个程序员也会因为心情，因为经常加导致写代码的状态不同，而写出不同风格不同格式的代码。作为团队技术管理者就头疼了，为了项目的可读性可维护性，就想出了定制代码规范这招，然后希望团队按照这个规范去写代码。想的不错，不过也想得美，程序员可是闷骚无拘无束出了名的，当面看起来很听话，背地里完全不吊你。虽然定制代码规范后团队代码质量有所起色，但各路神仙那出家的程序员，最后的结局依然是写出了各路神仙那出家的代码。您作为管理者，不太好在代码review的时候为各种简单的代码规范问题不断的给出注释。更不敢当面批评他们，这帮混蛋屌丝真的是屌丝，一不高兴就撂挑子不干了。所以技术人还是应该用技术的方式去管理程序员才是治理他们的良方，他们就服服帖帖了，所谓以技服人。
前面两段请自觉剪掉，我是装逼的，嗯嗯，其实这篇文章是写给懒程序员的，谁愿意为了点代码规范花时间啊，我是来先程序的，难道为了代码规范还得操碎心吗？嗯嗯，我就是因为不想操心这种不相关的事情所以才想找方法去解决这种我不想care的事情的。嗯嗯。

Dang Dang Dang,Dang Dang Dang(请脑补响起贝多芬命运交响曲第九交响曲，谢谢)..今天就给大家隆重介绍这款神器，这真不是一般的神器，是去百货摊买不到的神器，是环游世界也见识不到的神器。没错，它就是ClangFormat-Xcode。只在这里可以免费买到，只在这里可以见识到，下载地址：clangFormat-Xcode

ClangFormat-Xcode介绍

要介绍ClangFomat-Xcode，就需要知道clang-format工具，这款工具可以用来格式化C/C++/Objective-C语言编写的代码。它会根据您的格式化配置，将代码规范成您期望的格式。clang-format工具也内置了LLVM、Google、Chromium、Mozilla、WebKit代码风格的配置。这样我们就不用完全配置所有的代码格式了，而是可以基于这些默认的集中风格，动动手指修改一些配置参数，为自己团队的代码规范所用了。关于clang-format就介绍这么多，关于更多可以参考官方文档：《Clang 4.0 documentation》。

而ClangFomat-Xcode就是一款为Xcode便利化使用clang-format工具的一款插件了，仅此而已，，仅此足以，为人民服务的在我心里是最伟大的。感谢大神@travisjeffery的贡献，为iOS开发没有很好的格式化代码的工具带来了福音。

ClangFormat-Xcode安装

ClangFomat-Xcode的GitHub地址：戳这里,你可以通过Alcatraz安装，也可以下载下来运行安装，重启下应该就可以在菜单Edit看到Clang Format选项了。这里要是还不会，就直接付费咨询我吧。

clang format配置

前面我已经提到了，clang format 工具了，CLangFormat本身就内置了LLVM、Google、Chromium、Mozilla、WebKit的基础样式。而几乎比较好的代码规范大部分内容他们都包括了，所以我们完全可以基于这些基础样式来实现我们各自团队稍微差异的部分。具体配置方式，在我们的项目工程目录或者workspace目录下创建一个”.clang-format”文件。然后修改配置如下，下面我贴一下我项目中的配置吧。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# 你的项目基于的基础样式，我的项目是基于LLVM的
BasedOnStyle: LLVM

# 缩进宽度
IndentWidth: 4

# 圆括号的换行方式
BreakBeforeBraces: Attach

# 支持一行的if

AllowShortIfStatementsOnASingleLine: true

# switch的case缩进
IndentCaseLabels: true

# 针对OC的block的缩进宽度
ObjCBlockIndentWidth: 4

# 针对OC，属性名后加空格
ObjCSpaceAfterProperty: true

# 每行字符的长度
ColumnLimit: 0

# 注释对齐
AlignTrailingComments: true

# 括号后加空格
SpaceAfterCStyleCast: true

# 不在小括号里加空格
SpacesInParentheses: false

# 不在中括号里加空格
SpacesInSquareBrackets: false

记住，如果要让这个配置管用，确认Edit -> clang format -> File，file是勾选状态。
关于clang format格式化配置个多参数介绍，推荐阅读官方文档：《Clang-Format Style Options》

clang format全局配置

配置是一样的，前面一段提到把配置文件放在项目目录下，这种配置就是项目配置，如果把”.clang-format”文件放在家目录下就是全配置了嘛。嘿嘿，把全局配置单拉出来就是怕您忙注意不到，所以显摆出来。我给力吧。点个赞打赏吧。

Clangformat-Xcode使用

通常我会在设置在保存command+s时候自动格式化代码。确认Edit -> clang format -> Enable format on save 改成 Edit -> clang format -> Disable format on save 。这样就开启了保存时自动格式化了。当然你也可以给格式化创建一个单独的快捷键。不过我觉得没必要啦。

总结

SoSo。标准化代码是如此的容易，你还有理由写出烂代码吗？我替你做主了，绝对没有,以后乖乖滴写好代码，Come on。

参考文献

《Automatically Formatting Your Objective-C》

《ClangFormat-Xcode》

《Clang 4.0 documentation》

前言

我们平安健康的App项目的整体架构是我做的。我把我最近学习的网络架构知识结合以前的项目经验，设计了《平安健康》App项目网络架构。现在把这些知识和实践经验总结出来，希望加深网络架构的思考，并和同仁共同学习进步。

认识网络架构

对于网络层的架构，在APP端是不太受到工程师们重视的，在这个APP圈钱的时代，boss们关心的更多是这个APP是否能够工作,然后赚钱，对于APP内部代码设计是否合理,技术应用和代码实现是否可维护可扩展，他们是不care的，老板们多半非技术出身，也关心不到这些，全仰仗工程师们的良知了。等到APP的维护性和扩展性出现问题的时候，可能工程师就已经跳槽了，然后负责填坑的工程师们就要骂娘了，完全不敢接手就跑了。我之前由于知识的局限，考虑不到那么全面。因为看到很多APP，包括以前做的项目都是简单对AFNetworking做一个封装，想当然的以为网络架构就是那么回事。

这半年一直在关注的casa大神的架构系列文章。实在干货太多，所以这半年费了N多脑细胞去琢磨他的几篇文章，比如《iOS应用架构谈 网络层设计方案》。在读这系列文章时，宝宝内心是崩溃的，那感觉就像星爷在电影《九品芝麻官》拿半个饼换了尚书大人两大盘饼，本来星爷很得意认了个亲，还赚了两大盘烧饼，但是尚书那奸臣却要星爷当场啃完那几十个大烧饼…想想我就要吐了吐了……。我因为是一个好学上进的有志青年，所以看到这么好的系列文章，也是恨不得赶紧吸收为己所用，即使吐也要一边吃一边*。

相比普通工程师而言，优秀工程师他们更加关注细节，他们会为了提升一点点团队效率，提升一点项目质量，提升一点点技术手段而绞尽脑汁的去学习然后解决问题。在点点滴滴的总结中提炼出优秀的项目开发和架构方案。

App端的架构和服务器端的侧重点不同，App端技术的架构相比服务器端而言，对性能的关注度不如对用户体验的关注度，因为前端是用户直接使用的端，能从架构层面帮助业务开发解决部分用户体验问题也是很重要的(这个在后面会讲到从网络架构层面可以帮助解决哪些用户体验的问题)；服务器端更看中健壮性和承压能力（性能），而由于前端面对产品的需求变化比服务器端也大，因此架构上对可扩展性、可维护性、可读性的关注度也相比后端更关注一些，假设业务之间耦合性太大，动一些业务代码都导致整个项目难以为继，那这得是多么失败的架构啊。如果能从顶层引导业务开发工程师的代码更规范，那是一件对架构师多有成就感的事情呢。

App网络架构设计的两个关注点

在APP中，网络层属于项目的顶层了。网络层负责直接和server端通信获取或者修改数据，将返回结果交付给业务层去处理，或者业务层将数据传递给网络层去跟server端通信。网络层对接的是sever端和APP项目的业务层，架构师在做网络架构时就需要考虑网络层和这两个层对接设计。

• 1.网络层架构如何设计能更合理地对接server端。
• 2.网络层架构如何设计能更合理地对接业务开发。

casa在的系列开篇中提到架构设计是自顶向下去设计，然后自下向上去实现，反向去验证架构的合理性。我同意这个观点。所以本文的思路就从顶向下去思考的网络层架构的。先从整体思考以前项目中缺陷，从全局层面去思考如何架构能够解决网络层架构存在的问题，然后抽丝剥茧去一个一个找到方案去解决问题。

架构师需要根据自己过去项目的经验，去预演设想项目发展过程中可能遇到的网络架构需要解决的技术坑、同server端对接遇到的坑、和业务层开发工程师对接遇到的坑。

关注点1：如何设计网络架构能更合理地对接server端

1.安全问题

• 1）网络通信的数据安全如何解决？

• 2）如何防止中间人攻击，比如运营商的广告插入？

• 3）如何确保网络请求由开发的App发出，防止其他人爬API请求获取返回数据?

解决方案：

关于第一条、第二条的解决方案如果能和server端协商改成HTTPS就用HTTPS。事实上现在苹果要求的请求必须是HTTPS，从iOS9之后非https的请求的App是无法审核通过的，必须要提出特殊APP使用HTTP的申请。HTTPS可以防止中间人攻击（比如运营商在返回数据里插入广告），也可以保障数据的安全。如果server端就是不支持HTTPS，除了鄙视他们，你能做的就是和他们协商对请求返回的数据做加密处理。

关于第三条安全的解决方案通常做法是使用签名，对请求参数加盐做hash算法，然后在服务端去用彼此协商好的加密解密规则去解这个hash值，如果最后的结果一致，说明该请求是由自家的APP发出，反之则可能是有其他人截获请求后发出的，server端需要把这中非自家的请求给quit掉。服务器端和APP端可以协商一个相对复杂的加密算法，这样不容易被黑客猜测到。APP端最好不要将加密的规则写到本地文件中，而是直接写在代码里，这样不容被攻击者获取到加密规则。

2.性能优化

• 1)如何减少不必要的网络请求，减小server端的压力？

• 2)如何提高用户请求的相应速度？

• 3）如何降低用户请求流量消耗和耗电？

解决方案：

1.必要的API请求的缓存，可以优化上面所有的点。

如果一个请求的返回数据几分钟甚至几小时内不容易有变化，比如产品详情页面的数据一般几个小时内是不怎么会变化的，我们可对请求的返回数据做内存缓存；如果一个请求的返回数据可能几天甚至几个月都不会变化，比如推送的文章数据，我们可以对请求的返回数据做内存和磁盘的二级缓存，当然有变化如何处理，这个可以参考我的文章《iOS架构师之路：数据持久化方案》；关于磁盘缓存，如果数据要求精确度较高，我们可以用数据库精确到字段去存储数据，比如用户信息，城市信息；如果数据只是要求整存整取的非核心数据，我们可以用数据库也可以文件存取。
现在的AFNetworking已经提供CachePolicy这个字段让我们做请求的缓存，但是如果请求头Header加入了区分请求的字段，那用CachePolicy就不好使了，因此在做架构的时候，就需要自定义请求缓存类了。

2.请求状态的记录、暂停、取消。

用户的行为无法预知，比如点击某个按钮发起请求后可能再次点击触发请求，这时候我们最好在网络架构的时候考虑这个问题，有一个机制记录请求是否在请求中，如果在请求中，我们可以暂停发起过的请求的或者暂停即将发起的请求。比如下拉列表，发起请求后，如果用户再次下拉，最好不要再次请求，因为两次的请求数据相同，不需要重复发送请求；如果是用户筛选的请求，那最好取消之前发起的请求，再发起新的请求，因为之前的请求对用户已经没有任何意义了，新请求才可能是用户期望的行为。因此在做网络架构的时候，就需要网络层给业务开发提供记录状态、取消请求的接口。

避免DNS解析，直接IP请求可以稍微提高一写网络请求的速度。

域名解析多少是需要一个解析过程的，APP端因为无需像浏览器一样，需要给用户一个比APP更容易记住的域名输入需求，所以没必要发起请求使用域名，完全可以使用IP地址。

本地IP表，可以解决中国南电信和北联通运营商之间的PING延时差。

用户的手机使用网络环境不可预知，经常出差的同事可能会在多种网络环境下使用手机APP。如果服务器端有多个IP地址，有联通的，用电信的，或者其他运营商的。我们最好能在APP端有一份IP地址列表，把服务器端的所有IP列入，当APP启动时候，针对这个列表的IP地址做ping延时时间，取延时最小的IP作为这段时间应用的服务器IP地址。

3 .如果server端的接口设计的规范和数据结构五花八门，网络层如何为业务开发解决这部分困扰？

我们的服务器端的团队可能是多个团队，也可能是外部团队，甚至是第三方，比如谷歌地图，比如天气服务。这时候我们最好能在网络架构的时候充分考虑到这些。让业务开发可以使用相似的接口，尽可能少的调整就能使用不同接口设计规范提供的API。

在团队中可能多个业务模块由不同的后端团队去做，比如我之前公司《亚程旅游》APP的酒店业务有城市列表，机票业务也有城市列表，但是这两个城市列表的后端来自不同团队，服务器端返回给APP端的数据字段个数不同，字段命名不同。这时候我们可以在网络层提供一个洗数据的功能，让业务端拿到相同字段数字段名的数据。

还有我们的后端有开发、测试、和生产环境。网络架构的时候做好开关功能，而不是切换环境需要手段去更改IP，虽然看起来这并不费工夫，但在实际团队开发的合作开发过程中，我们负责打包的工程师可能会忘记修改IP地址，这时候打包给测试或者上架，那时间成本和代价就不是十分钟二十分钟的事情了。所以能自动化解决的一定要自动化。

4 .当server端没有提前交付真实接口时，在网络层如何通过mock数据，让业务开发顺利进展？

团队作战的能力真的是千差万别，只有更神奇没有最神奇。有些时候，sever端的开发严重滞后前端开发，前端拿不到真实数据，根本不好调试界面和界面逻辑，因此影响前端的开发进度。如果在业务层写很多的假数据，或者硬编码假数据，这又在对接真实数据时需要删除整理，而且让mock假数据的工作变得非常繁杂和沉重，让业务开发感到非常的沮丧。所以架构师需要注意到这些，架构师的存在一个重要理由，就是为业务工程师服务的。
所以在网络层，可以设计一个mock数据的开关，业务开发可以按照接口文档示例，mock一个本地json/xml数据文件，以一个约定方式命名这个json文件。这时候业务开发就可以像调用接口一样调用mock数据里，让开发能够顺利进行。

关注点2：网络架构如何设计能更合理地对接业务开发

1.以哪种方式交付数据给业务层

casa在他的文章中提到一个观点：架构师在该灵活的时候要灵活，该限制的要限制。当然何时灵活合适限制是需要架构师的经验的。网络层交付返回数据给业务层的方式主要有notification、delegate、block.由于AFNetworking使用的是代理的方式，所以多数APP为了偷懒，在网络层都是沿用了AFNetworking的方式，使用了block。而block虽然让代码紧凑，但是在一段代码里，包含我们请求时的参数组装、参数的判断、请求发起、返回数据校验、各种判断的弹出提示、对返回数据进行处理，这些会让请求这段代码变得非常臃肿。业务开发工程师如果勤快一点，可能会为block块单独开一个方法去处理返回结果，但是这样可能导致各个业务处理的方法名不一致，可读性差，因此还不如在网络层架构的时候，就直接使用代理的方式给到业务开发，这样就把请求和返回分离了，代码结构也更清晰，方法命名也更统一。

2.交付什么数据给业务层

我认为这部分就是该灵活的时候了，我看过一些APP直接在网络层返回model给开发，或者是未序列的responseData的原数据给业务开发，这两种方式都不太合理。后者就不必多说，网络层没必要偷这个懒，直接序列化之后给业务开发，就不用每个API业务开发都需要先序列化一下，何乐而不为？而前者直接返回model的话，我认为就对业务开发限制太死了，我认为这部分是网络架构可以该灵活的时候了。可能一个页面只需要这个model的一个两个字段，这样带一个model过去不太合适，太重了，而且也有可能这个页面的数据是多个model的数据某些字段组合而成的，那这时候就会让业务开发很蛋疼了，这个页面可能需要定义一个新的model，或者这个页面需要多个model的数据，那可能需要带入多个model，这样做都很难看。所以我建议网络层返回一个序列化后的数据就好。在casa的文章中还提到了reformmer机制，可以洗数据用，让每个页面取得需要的数据。你可以这么做，也可以直接用字典搞定，或者转化为model，建议最好把处理交给业务层。

3.传递什么类型的参数给网络层

我见过一些项目，可以传model作为参数给网络层，可以传字典到网络层，也可以传key,value的方式给网络层。我认为没必要，直接传递字典就好，这部分完全没必要灵活。因为无论是model，还是字典，还是key value，极可能在发起请求前是需要组装参数的，传入model的话，可能传参前需要转化成model，到网络层可能还需要转字典一下，浪费这个性能和时间成本完全没必要。key,value的方式或许好点，没有多少转化成本，但是为了可读性和规范性，还是觉得没必要。因此我任务传参统一用字典就好，让传参行为标准化，对代码可维护和可读性也是有好处的。

4.给业务层封装共用和不必要的参数传入

这部分不必多说，多数网络层都会做这个事情，但是如果结合综合前文中和server端对接提到的多种服务的情况，最好封装共用参数是和服务绑定的。而不是直接写死，否则网络层应对服务端接口变化时候，可能服务变了，需要不断的改这部分代码。

5.请求状态的记录、取消、暂停的接口开放给业务层。

这部分其实不少APP架构的忽略了这部分设计。这类APP是不关心用户流量的，可能还会给用户非期望的结果。优秀的APP还是尽量多的为用户考虑下吧，所以该设计的要设计，因为业务开发的能力可能还考虑不到这些。

6.请求参数的校验

我们的请求参数，可能是依赖其他API的返回值，或者依赖其他页面，而这个请求的参数的值可能有要求，比如不能为空，或者只能是枚举值中的几个值，这时候如果我们能对参数做校验，在架构成眠为业务提供校验参数的接口，我们业务开发就能根据参数校验情况，决定要不要发起这次请求，直接给用用一个提示；或者让他们根据业务决定要不要给参数一个默认值，有些业务有默认返回结果可能比没有结果更好。所以架构的时候考虑了做这个接口，这样给业务开发工程师一个可以校验的参数的接口，在必要的时候业务开发是喜欢用的。

7.返回值的必要校验

这部分和请求参数的校验类似，因为某些字段服务器返回的不稳定，比如返回”NULL”字符串，就挺让用户崩溃的，这时候如果能够对某些关键的不稳定的字段做一些校验，业务开发肯定期望有这么一个接口，如果网络架构考虑到这些，他一定会对感激涕零的。

总结

这篇文章主要是我对平安健康APP架构的实践的思考，主要的思想来自casa大神，同时也加入了自己的经验。网络架构由于是项目的顶层，如果设计不好，比如该开发的接口没有开发，该限制的地方没限制，该灵活的地方没有灵活，会影响整个项目的进度和业务开发的代码性能和质量。这篇文章主要是谈网络架构的关注的两个点：和服务器对接以及和业务层对接。以及围绕这两个点，架构师需要前瞻到可能会踩到的坑，能在网络层解决的就要提前设计好，然后找到解决方案去解决。这篇文章偏重于设计，由于篇幅太长，周期太长，所以写的时候状态也不一，所以可能写的有点乱，我会在后续的时间慢慢整理。后续有时间我也会把自己的架构设计方案的代码搬上来。

参考

《iOS应用架构谈 网络层设计方案》

开源控件HooCircleProgressView

这周工作中需要开发一个健康走步的功能，需要用到一个环形计步的控件，看了几个开源项目，没有达到自己理想，所以动手写了一个，今天再把它整理了一下，方便开源给需要的朋友调用。

A circular gradient progress view implementation for iOS with efficient drawing using a series of arcs with linear gradient.

一个圆环形进度条，支持颜色渐变

HooCircleProgressView Demo picture:

下载地址链接:HooCircleProgressView

如何使用How To Use:

==================================================

HooCircleProgressView *progressView =
      [[HooCircleProgressView alloc] initWithFrame:(CGRect){0, 0, 240, 240}];
  [_progressView setCenter:self.view.center];
  [_progressView setLineWidth:6.0f];
  [_progressView setProgress:0.0f];
    [_progressView setStartColor:[UIColor greenColor]];
  [_progressView setEndColor:[UIColor yellowColor]];
  [self.view addSubview:_progressView];
  [progressView setProgress:1.0f animateWithDuration:AnimationDuration];

前言

先吹个牛，我打心眼自认为自己是喜欢对团队项目的代码质量负责的人，对于思考如何写出高质量可读性的代码我是乐此不彼。之前我写过两篇关于代码命名规范和代码编写规范的文章，《iOS架构师之路：iOS开发（OC）中的命名规范》、《iOS架构师之路：IOS项目中的编码规范》，您要是心情很好，就去看看吧，如果低于很好，那不建议您看，怕您心里骂娘，因为现在看，感觉自己写的不太认真，有不少方面可以写的更细致，恩，我决定给自己帖贴金，不能这么说自己：其实这半年小哥我在代码规范方面的知识又见涨不少，所以看以前定制的规范不爽，作为架构师保持谦卑，通过不断学习，不断自我修正，对代码有一点洁癖是该有的气质（潜台词其实我想说我有）。制定项目的代码规范对架构师的重要性，就像要你生个娃一样，责任重大，万一生出来缺胳膊少腿，娶不到姑娘，你以后即使伺候他一辈子，给他当牛做马，他也不一定会念你的好。

论代码规范的重要性

• 1.架构师要为整个项目技术方向的发展负责，所以制定一个良好的代码规范，让开发工程师遵守，有利于项目朝着您预知的方向发展。比如当您向使用AOP技术实现日志功能时，就需要规定一些方法命名。
• 2.一致的代码规范，有利于代码reveiw工作。如果每个工程师写的代码风格不一样，review代码的同事，阅读起来肯定不顺畅。
• 3.要求工程师按照代码规范写出一致的代码，就不怕他跳槽。这行本来就浮躁，流动性大，要是工程师写的代码风格只有他自己能看懂，那玩意他跳槽，新人是很难继续维护这部分代码的，得不偿失。

培养代码洁癖

给大家推荐一本关于代码规范的杰作，第一本：《禅与 Objective-C 编程艺术（Zen and the Art of the Objective-C Craftsmanship 中文翻译）》（简称：Zen），这本书开源社区的大牛，无偿奉献出来的，该书给我们介绍许多写代码的正确姿势，并解释为什么使用这个姿势体验更好。看完这本书应该知道如何写出优雅、高可读性并且可靠的代码了。

我推荐的代码规范

《The Objective-C Style Guide used by The New York Times》（简称：New York，该规范也有中文版），《New York》是我比较喜欢的编码规范风格，它是《Zen》的编码思想一个很好的实践。

关于《Zen》、《New York》代码规范的补充

1.iOS切图文件的命名规范

这部分规范可能是很有经验的设计提供，也有可能是我们开发人员提供，掌握总是没有坏处的。

我们的命名规则的基本思想是把文件名分成三部分，第一部分是图片的逻辑归属分类，第二部分是图片的表现内容，第三部分是图片的内容的类型，有些图片还会有第四部分，表示图片表现的状态。首先有几个规则是：

• 用英文命名，不用拼音
• 每一部分用下划线分隔
• 图片名中两倍图在名字最后要加@2x，三倍图在名字最后要加@3x

万能公式：

逻辑分类

逻辑分类即是这张图片所属的分组，在 iOS 中大多的项目是以 Tab bar 的形式进行逻辑上的分组，以Showtime客户端为例：

这张图中的 Showtime 客户端就是使用 Tab bar 进行分组的，可以看出内容分成了五个部分：Home，Categories，Live TV，My List 和 Search。所以例如在这个界面中，右上角的设置按钮，那么它的切图命名的 第一部分就是 Home。

但是仔细看看上面这个界面的话有一些图其实是不属于某个分类的，比如 Tab bar 中的图标文件和 Navigation Bar 中的 Showtime 图标，对于这两种内容来讲，它们命名的规范是第一部分显示的是 navigationbar 或者是 tabbar。

表现内容

表现内容就是这个图片表现的内容，同样以上图为例，界面中右上角的按钮表现的是设置按钮，那么它的表现内容就是设置，所以这个按钮在第二部分显示的就是 settings。

而在上图的 Tab bar 中第二部分的名字就是它们在程序中显示的名字 ，而 Navigation Bar 中的图标的第二部分命名因为表现的内容就是 Showtime，所以显示的就是 showtime。

内容类型

同样以 Showtime 的图为例，在 Navigation Bar 中的图标，它的内容类型是 icon，所以这个图片文件的两倍图完整命名就是 navigationbar_showtime_icon@2x.png。而右上角的设置按钮的话，它的类型是按钮，所以第三部分即是 button 的缩写 btn，即是 navigationbar_settings_button，下面五个 Tab bar 的图片名分别是 tabbar_home_icon,tabbar_categories_icon,tabbar_livetv_icon,tabbar_mylist_icon 和 tabbar_search_icon。

图片状态

对于某些类型的切图，它可能代表的只是某个控件的一种状态，以按钮为例，正常的状态就是 normal，而点击中的状态是 highlighted，选中的状态则是 selected。Showtime 的图中，右上角的设置图标是正常的状态，所以加入图片的状态之后，它的两倍图的完整命名应该是 navigationbar_settings_btn_normal@2x.png。而下方的 Tab bar 来讲，选中的是 Home，那么当前这张图片的两倍图的完整命名就应该是 tabbar_home_icon_selected@2x.png。

2.类的布局

程序布局的目的是显示出程序良好的逻辑结构，提高程序的准确性、连续性、可读性、可维护性。更重要的是，统一的程序布局和编程风格，有助于提高整个项目的开发质量，提高开发效率，降低开发成本。同时，对于普通程序员来说，养成良好的编程习惯有助于提高自己的编程水平，提高编程效率。因此，统一的、良好的程序布局和编程风格不仅仅是个人主观美学上的或是形式上的问题，而且会涉及到产品质量，涉及到个人编程能力的提高，必须引起大家重视。

2.1.文件布局

【规则2-1-1】遵循统一的布局顺序来书写头文件。

说明：以下内容如果某些节不需要，可以忽略。但是其它节要保持该次序。
头文件布局:

1
2
3
4
5
6
7

文件头
#import （依次为标准库头文件、非标准库头文件）
全局宏
常量定义
全局数据类型
类定义

正例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

/***************************************************************************
 *                                文件引用
 ***************************************************************************/ 
/***************************************************************************
 *                                 类引用
 ***************************************************************************/
 
/***************************************************************************
 *                                 宏定义
 ***************************************************************************/
/***************************************************************************
 *                                 常量
 ***************************************************************************/ 
/***************************************************************************
 *                                类型定义
 ***************************************************************************/ 
/ ***************************************************************************
 *                                 类定义
 ***************************************************************************/

【规则2-1-2】遵循统一的布局顺序来书写实现文件。
说明：以下内容如果某些节不需要，可以忽略。但是其它节要保持该次序。
实现文件布局：

1
2
3
4
5
6
7
8
9

文件头（参见“注释”一节）
#import （依次为标准库头文件、非标准库头文件）
文件内部使用的宏
常量定义
文件内部使用的数据类型
全局变量
本地变量（即静态全局变量）
类的实现

正例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/***************************************************************************
 *                                文件引用
 ***************************************************************************/ 
/***************************************************************************
 *                                 宏定义
 ***************************************************************************/
/***************************************************************************
 *                                 常量
 ***************************************************************************/ 
/***************************************************************************
 *                                类型定义
 ***************************************************************************/
/***************************************************************************
 *                                全局变量
 ***************************************************************************/
/***************************************************************************
 *                                 原型
 ***************************************************************************/
/ ***************************************************************************
 *                                类特性
 ***************************************************************************/
/ ***************************************************************************
 *                                类的实现
 ***************************************************************************/

2.2类结构布局

使用#pragma mark –来分类方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#pragma mark – Life Cycle

#pragma mark - Events

#pragma mark – Private Methods

#pragma mark - UITextFieldDelegate

#pragma mark - UITableViewDataSource

#pragma mark - UITableViewDelegate

#pragma mark - Custom Delegates

#pragma mark – Getters and Setters

2.3布局中的空格

每个方法或者功能块之间为了结构清晰，应当有且只有一行空格。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@interface SomeClass:NSObject

@property (noatomic, strong) UIView *aView

-(void)someMethod;

@end

@implementation SomeClass

- (void)setAView:(NSInteger )aview {
    
}

-(void)someMethod {
    
}
@end

2.4关于布局中的Private Methods块，正常情况下ViewController里面不应该写

不是delegate方法的，不是event response方法的，不是life cycle方法的，就是private method了。对的，正常情况下ViewController里面一般是不会存在private methods的，这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。
ViewController基本上是大部分业务的载体，本身代码已经相当复杂，所以跟业务关联不大的东西能不放在ViewController里面就不要放。另外一点，这个private method的功能这时候只是你用得到，但是将来说不定别的地方也会用到，一开始就独立出来，有利于将来的代码复用。

3.属性初始化放哪最好？建议在Getter中初始化

我看到很多APP，甚至我公司的项目，很多开发工程师，初始化属性的位置比较随意，有单独添加一个初始化方法类似setupView的，有在init初始化的，各种情况都有，我其实挺崩溃的，首先初始化方式不一致，其次也这样做非常有可能破坏了每个方法功能的单一性（每个方法只做一件事）。我比较习惯一个对象的”私有”属性写在extension里面，然后这些属性的初始化全部放在getter里面做，在init和dealloc之外，是不会出现任何类似_property这样的写法的。就是这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

@interface CustomObject()

@property (nonatomic, strong) UILabel *label;

@end

@implementation

#pragma mark - getters and setters

- (UILabel *)label {
    if (_label == nil) {
        _label = [[UILabel alloc] init];
        _label.text = @"1234";
        _label.font = [UIFont systemFontOfSize:12];
        ... ...
    }
    return _label;
}
@end
#pragma mark - life cycle

- (void)viewDidLoad {
    [super viewDidLoad];
    [self.view addSubview:self.label];
}

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    self.label.frame = CGRectMake(1, 2, 3, 4);
}

唐巧说他喜欢的做法是用_property这种，然后关于_property的初始化通过[self setupProperty]这种做法去做。从刚才上面的代码来看，就是要在viewDidLoad里面多调用一个setup方法而已，然后我推荐的方法就是不用多调一个setup方法，直接走getter。

嗯，怎么说呢，其实两种做法都能完成需求。但是从另一个角度看，苹果之所以选择让[self getProperty]和self.property可以互相通用，这种做法已经很明显地表达了苹果的倾向：希望每个property都是通过getter方法来获得。

早在2003年，Allen Holub就发了篇文章《Why getter and setter methods are evil》，自此之后，业界就对此产生了各种争议，虽然是从Java开始说的，但是发展到后面各种语言也参与了进来。然后虽然现在关于这个问题讨论得少了，但是依旧属于没有定论的状态。setter的情况比较复杂，也不是我这一节的重点，我这边还是主要说getter。我们从objc的设计来看，苹果的设计者更加倾向于getter is not evil。
认为getter is evil的原因有非常之多，或大或小，随着争论的进行，大家慢慢就聚焦到这样的一个原因：Getter和Setter提供了一个能让外部修改对象内部数据的方式，这是evil的，正常情况下，一个对象自己私有的变量应该是只有自己关心。

然后我们回到iOS领域来，objc也同样面临了这样的问题，甚至更加严重：objc并没有像Java那么严格的私有概念。但在实际工作中，我们不太会去操作头文件里面没有的变量，这是从规范上就被禁止的。

认为getter is not evil的原因也可以聚焦到一个：高度的封装性。getter事实上是工厂方法，有了getter之后，业务逻辑可以更加专注于调用，而不必担心当前变量是否可用。我们可以想一下，假设一个ViewController有20个subview要加入view中，这20个subview的初始化代码是肯定逃不掉的，放在哪里比较好？放在哪里都比放在addsubview的地方好，我个人认为最好的地方还是放在getter里面，结合单例模式之后，代码会非常整齐，生产的地方和使用的地方得到了很好的区分。
所以放到iOS来说，我还是觉得使用getter会比较好，因为evil的地方在iOS这边基本都避免了，not evil的地方都能享受到，还是不错的。

4.Getters and Setters放在最底部

我之前写代码一直把Getters and Setters 放在implementation的最前面，昨天看大神casatwy说最好放在最后面，我觉得更有道理。控制器可能会有非常多的view属性和其他属性,如果所有的getters and setters放在前面，就会导致在implementation代码顶部有大量的初始化代码，这就导致主要的逻辑代码挪到后面去了，其他人阅读代码是不太方便的。

结尾

夜深，该睡了。

译者注：这篇文章是我在一个月前看到的，文章的内容基本表达我转行从事iOS开发时候的思考。觉得这篇文章会对那些想做iOS开发和刚开始做iOS开发的朋友有一些帮助，因此翻译出来并分享给大家，对我而言则温故知新。不忘初心，方得始终，新的一年再次出发。

每个人的都有独特的经历，因此会有特别的事情会让ta感到快乐，并享受做自己喜欢的事情。写程序也不例外，我在很年轻的时候就明白这点，它成为我开始创业的无形资产。写程序的渴望来自我想完整独立做一件事情的渴望，做移动开发，可以让我不依赖任何人就能学会完成一个完整的App需要的所有能力。

为什么我当初会学习现在使用的Objective-C和Swift编程语言？因为我喜欢和用户直接交互，而移动开发满足了我这点。这股激情让我在学习iOS开发时能保持110％的热情。

　　我刚才分享了我想从事移动开发的动力，并且认为这是做iOS开发需要思考的问题。你可以给下面两个问题提供自己的答案：

• 1.你为什么想要编程？

• 2.你能在大脑里勾画出你写代码的景像吗，描绘一下这个场景？

　　如果您已经决定从事这条道路，下面我提供一些建议，希望能够帮助你打开通往移动开发的这扇门。

明确你的激情

　　你已经有了一定的热情，像我当初一样，你还需要更加清楚自己的热爱的具体是什么。好奇心很重要，它会指引你到一个具体的方向，找到一个移动开发中最感兴趣的方向，然后交给命运来安排吧。
　　
　　你在大脑勾画出的景像是什么？喜欢科学和数学的朋友可能希望为NASA写代码；或者有些朋友擅长社交或者运动竞技，那他可以开发健康类的产品来衡量活动量；你也可能喜欢视频游戏。清楚自己在生活中喜欢什么，并让它成为你的灯塔指引你开发项目。当然这也有可能会改变，我开始是写游戏，但是我现在写了更多的社交，教育和效率类的产品。

你可能开始使用swift语言然后发现它不适合你。例如：你可能希望通过SpriteKit和Swift为iPad写游戏，后来你尝试Unity3D写游戏，并且喜欢上它。如果你还没有确定自己的喜欢的平台和语言，那就保持热诚和开放态度去探索吧。

当然如果你没有这从事移动开发的热情，那您需要停下来，重新评估下自己的道路。坚持一段时间如果在显示器面前还是表现的恐惧，那这可能不是你想要的生活，换一个吧，生命短暂，应该享受生命。

开始行动

网上有很多视频教程可以学习，不过我衷心地建议读几本书，因为书籍更加专注，方便浏览，并且没有很多干扰。只有你，书籍还有代码编辑器。

补充一些关于学习平台的书或者视频教程挺好。但是一页一页的读几本书会帮助你极大的提高，一旦你确定自己想要学习的语言，你可以买两本书：

• 1.买一本仅仅介绍该编程语言的书。
• 2.买一本教你在特定编程环境中使用该语言的教程书籍。

记住：在我或者你朋友有效的学习方式不一定适合你。我们的学习方式不同，你需要一些独立意识以便让自己保持在正确的学习轨道上。如果你还没有这种独立判断意识，那读书是一个安全可靠的选择。
　　
　　假设你决定用swift为iOS设备写程序，那你就买一本swift语言的书籍而不是Objective-C语言的书籍，认真读完，然后再买一本教你如何使用swift语言开发一个App的书籍。

　 语言＋开发平台的书籍可以帮助你保持专注而尽可能少地分心。你可能感觉还是很困难，但通常会好过你通过网上教程来学习。 　　

放下书籍动手写自己的项目

　　我敢保证你遇到的最大的挑战不会在你学习一本书籍并完成里面的示例的时候，而是当你读完书籍之后开始开发自己的项目的时候。你学习一本书籍并完成里面的示例只是为了让你写程序的挑战相对小一点，因为你掌握了一定的基础，但仅仅是基础。

• 1.找到简单的点子(idea)，要非常小的点子，第一个app只要完成2-3件事情就可以，这样你就不必花去大量的时间来构思app的实现和架构，而只需要动手开始开发就可以。
• 2.不要完全一个人扛着——找一些方式获取帮助。如果尝试了很多方法失败后，你可以向 Stack Overflow等技术问答网站求救。
• 3.必要时候可以调整你的点子。如果你开发项目时感觉压力太大，开发太难，你可以换一个更容易的开始。比如开发游戏就相对要难很多，换一个更容易的游戏开发。（比如2D游戏代替3D游戏）

　　然后你就需要不断重复前面个学习内容，查找书籍，阅读网上教程，看看视频教程等。解决实际问题需要不少的时间和大量的练习。

加入一个团队

　　培养良好的编程习惯和学习新的方法的最好方式之一就是把自己放到一个团队环境里。团队环境能够把你带到你以前不清楚的方向。你会遇到很多编程老手，这些人对你学习编程非常有价值。不要认为你需要一些很牛的作品才能加入这些团队，很多团队也希望找到有热情的初学者。跟着他们做一些项目吧。
　　如果你很难加入一个团队，那可以找一个朋友或者老师来向他学习。　

击退自我怀疑

　　你需要的只是热情。如果你渴望开发苹果app，就不要让大脑有什么杂念。我保证随着你学习的深入肯定会有自我怀疑出现在大脑里的时候，如果你喜欢写代码、喜欢呆在电脑前，就不要让这些杂念击败你。
　　诚实地对待自己。你可能喜欢底层的开发技术，那你在成长路上会经历很多有趣地挑战。如果你喜欢写代码并设计程序，那太棒了，我认识很多开发者擅长前端开发。如果你喜欢写代码以及商务，你未来会成为优秀的领导者，成为一个多面手不是什么坏事。码农的发展方向上有很多选择的，我打赌肯定会有适合你这款得方向。
　　如果你确实不喜欢写代码。给自己6个月的时间尝试后还是没有兴趣。不要强迫自己，生命短暂。你应该选择更喜欢的道路。不要被周围和自己束缚——这是你的生活。

写代码、写代码、继续开发

　　当我开始编程的时候，我花了2到3周，每天12小时，完全集中在学习如何使用Mac，如何写写Obective-C代码以及如何使用iOS系统的SDK。
　　选一些自己喜欢的书籍然后致力于学习。安安静静坐下来读书，当你完成书上的内容后之后就可以写代码，一定要带着大脑去写。如果你喜欢写代码的话，这些对你来说就很容易，如果你给自己设立了目标，比如要在6个月内发布一款app，你也能很容易坚持下来。
　　你最终希望开始探索自己不熟悉的领域。你不需要给自己太大压力，不要一次给自己喂太多。在自己熟悉的领域加入一点点新技术就好，增加一点新鲜感就够了。总之不要太着急，保持专注。

起航

　　每个人都是不同的,没有人能给你完美的答案。这篇文章描述我所经历以及所观察后总结的，如果让我从新开始学我会这么做。我当时应该更早地加入一个团队，更早些寻找一位导师。即使现在我也希望能有个导师教我如何处理商务上的事情。
　　想好了就闷头扎进去学习吧，你肯定可以做到的，只要你心里有股做好移动开发的欲火在燃烧。 　　　

原文：http://www.xmcgraw.com/what-you-need-to-know-to-start-learning-how-to-code/

编程是一门艺术活，不同意？嘿嘿，那不要怪跟你翻两个白眼。没关系，你一定会同意这句话：艺术品的一个及其重要且必须有的特征就是它们都是由艺术家创作出来的O(∩_∩)O~。方才小生我是逗你玩的，讲真艺术品是由艺术家创作是没有任何问题的，当然其实艺术品还有一个特征就是它把重要的细节发挥到极致。所以，作为ios架构师，不放过任何一个可以提升项目质量、效率、健壮性等等的技术手段，也就是分内事了。也许是不够有技术含量，，发现国内外鲜有关于工程文件组织结构设计的文章。但是从我负责过的几个项目来看，一个好的工程文件组织结构能够从源头上提升工程师的开发效率，提升项目的健壮性和可扩展性，而我也清楚的看到过一些项目因为糟糕的文件目录设计，导致代码管理和项目发展过程会带来的问题。

一个好的工程文件组织结构设计的优点

1.工程文件分类明确，文件容易查找

2.目录功能定义清晰，工程师能轻易知道在哪创建新文件，尤其是当团队有天秤座的工程师时

3.工程和磁盘文件结构清晰，代码维护容易

4.目录粒度足够精细，减少项目依赖关系和增加模块的可移植性

……

关于MVC架构的在工程中两种体现形式

1.有很多项目是直接在工程里创建Controllers、Views、Models这样的目录结构…这样归类
2.按 Feature来划分，每个Feature里面有Controllers、Views、Models…这样归类

ios开发分工有两种，一种是分层开发，第一种形式适合分层开发，一种是分feature开发，第二种形式适合分feature开发。分层开发通常是有人负责DAO层（数据存取）开发，有人负责控制器和view层的开发，但是当API尚未形成，而且Dao层同事对业务层关注不够，DAO层开发的的同事就完全需要依靠自身的想象力去设计数据存取的接口，而往往这和实际API提供的接口存在巨大的落差，从而导致分层开发的各层都会做出大量代码重构。所以分feature开发是大家比较容易接受的一种开发方式。

所以我的建议：是采用第二种MVC组织形式，如果你采用MVVM或者其他，也可以参考此思路。其实第一种形式还有一个问题，比如你要找ControllerA的TableView用到的cellB类，你还要去Views里面一个个找，太痛苦了，就算search也还是苦毕竟不能所见即所得。而分feature则对于负责此feature的开发工程师找到有关文件则容易的多了。

关于Helper与Utility

我看过很多项目，包括自己参与过的一些项目要么没有Helper,要么没有Utility文件夹，而是将他们糅在一起，傻傻分不清楚。
我的建议：尽量细粒度化项目目录结构，在项目里分开提供helper目录和utility目录给开发者使用。与业务无关，具有对象性质，提供支持功能的代码放到Helper，比如创建一个自定义对象的封装。如果只是属于函数或算法，不是对象而且很多地方能用到，就放到Utility，比如排序/加密算法。

关于Common文件夹

这个在大神casa的文章《iOS应用架构谈 开篇》已经有清晰的表示，在他的文章中他建议在工程中标不要有Common文件夹。我一直以来可能都践行细粒度的目录结构划分方式，所以由我负责架构的项目都没有过common文件夹。我也比较认同casa的观点，不仅仅是对common文件夹，其实前面提到的helper和utility文件夹之所以拆分开也是因为希望能细粒度拆分模块，减少横向依赖。

Common的好处只有一个，就是前期特别省事儿。然而它的坏处比好处要多太多。

Common不仅仅是一个文件夹，它也会是一个Pod。不管是什么，在Common里面很容易形成错综复杂的小模块依赖，在模块成长过程中，会纵容工程师不注意依赖的管理，乃至于将来如果要将模块拆分出去，会非常的困难。
Common本身与细粒度模块设计的思想背道而驰，属于一种不合适的偷懒手段，在将来业务拓张会成为阻碍。
一旦设置了Common，就等于给地狱之门打开了一个小缝，每次业务迭代都会有一些不太好分类的东西放入Common，这就给维护Common的人带来了非常大的工作量，而且这些工作量全都是体力活，非常容易出错。

我建议在项目中不使用Common文件夹。这样工程师在创建一些共有文件，就必须按照他们的职责把他们分到不同模块里去，而不是偷懒，扔到common里，这样做虽然前期非常费劲，但是对后期维护、扩展、移植将带来巨大的好处。你会发现项目的可维护性大大提高，模块升级之后要做的同步工作非常轻松，解放了那个苦逼的Common维护者，更多的时间可以用在更实质的开发工作上。这符合我移植强调的细粒度模块划分的架构思想。

关于Xcode的文件夹如何创建

Xcode中组（Group） 和 文件夹引用（Folder Reference）的区别

刚才说了一些有关目录结构设计事情，现在说说 Xcode 的文件夹。我看过很多项目，我认为相当一部分的项目的文件夹管理不合理。在Xcode中 项目的文件夹有 Group 和 Folder Reference 之分。它们的区别在 Xcode Groups vs. Folder References 这篇文章里有详细的讲述。

Group 的缺点如下：

1）Xcode 会为每个文件创建一个 reference，存储在 project.pbxproj 文件中，当有多个 target 时，每个文件的 reference 会被复制多个，这就会大大增加 project.pbxproj 文件的尺寸和复杂度，这对于代码版本管理来是个头疼的问题，尤其是遇到 merge conflict 的时候。
2）项目中 Group 的结构跟磁盘上的文件价的结构可以说是没有啥关系的，在磁盘上的一个文件在一个某个文件夹中，但是在 Xcode 的项目结构中，它可能在任何 Group 中，这样想要去找对应的文件就常常让人很晕。
3）如果你在 Xcode 之外直接去 Finder 里移动项目文件到不同的目录时，那么在 Xcode 中对这个文件的 reference 就会坏掉。
Group 的优点如下：

1）你可以选择磁盘上的文件添加到项目中，不想要的不添加就行了。
2）对不同的 target 对应的文件能够更好地管理，比如，你可以选择对一个 target 排除某一个文件。
3）当 build 的时候，Xcode 会把所有的 Group 下的文件都放到 bundle 的顶级目录，所以你调用文件时不需要制定它的具体位置，比如，你不必这样 [UIImage imageNamed:@”Images/Icons/Go”]; ，这用这样就可以 [UIImage imageNamed:@”Go”];，但是这就意味着在整个项目中，你不能有同名的文件了。
Folder Reference 的有这些优点：

1）Xcode 只存储 folder 的 reference，这个 folder 下所有的文件和 subfolder 都会自动添加到项目中去。这会使项目文件更小更简单，代码版本管理时，产生 merge conflict 的可能就更少。
2）如果你在文件系统中直接对 folder 下的文件进行修改、移动或者删除，Xcode 会自动更新对应的 folder reference 来反应这些改变，这样管理项目文件也更简单。
3）项目的结构和 folder 在磁盘的结构是一致的，这样就不会晕菜了。
4）由于存在不同的 folder 路径，你就不需要担心文件重名问题了，因为在 build 的时候，文件夹结构也会被放到 bundle 中去。
Folder Reference 的有这些缺点：

1）对不同的 target 的管理是个灾难，因为一个 folder 下的代码或文件，要么全一样要么全不要。当然，如果你能为不同的 target 去建立不同的 Folder Reference，这看起来也没什么不好的。
2）对 folder 下的文件无法隐藏，磁盘上如果这个 folder 下有这个文件，那么在项目结构中就会看到它。
3）在加载文件资源的时候，你必须制定全路径。也就是说，你得这样：[UIImage imageNamed:@”Images/Icons/Go”];。
4）存储在 Folder Reference 中的图片在 Interface Builder 中使用时会遇到各种问题。
在实际使用中，使用 Group 要多得多。

Xcode 项目结构和磁盘文件结构的对应

上面说了 Group 和 Folder Reference 各自的优缺点，在项目中，我习惯上也是不使用 Folder Reference，只用 Group。在 Xcode 项目中创建 Group 的方式有两种：

1）第一种方式：创建时需要先在磁盘上创建对应的文件夹，再把文件夹拖进 Xcode 项目中对应的位置，并选择 Create groups for any added folders。这样创建的 Group 会对应着磁盘上的 Folder。

2）第二种方式：直接在 Xcode 项目中创建 Group。

对照 Xcode 项目的 MyProject.xcodeproj/project.pbxproj 文件可以看到对应着 Folder 的 Group 和直接创建的 Group 的区别就在于前者是用 path 属性去记录，后者是用 name 属性去记录。如下，Helper 是一个不对应 Folder 的 Group，Resource 是一个对应 Folder 的 Group。通过各个结点的父子关系以及 path 属性，Xcode 就能管理好每个文件的 Reference。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

//MyProject.xcodeproj/project.pbxproj

45E59EDF18BBA92C00251797 /* Helper */ = {
     isa = PBXGroup;
     children = (
          452183D3195AA18F00679F14 /* CXTaskControlService.h */,
          452183D4195AA18F00679F14 /* CXTaskControlService.m */,
     );
     name = Helper;
     sourceTree = "<group>";
};
45E59EE318BC2B4100251797 /* Resource */ = {
     isa = PBXGroup;
     children = (
          45E59EE418BC2B4100251797 /* Image */,
          45C97CA91900260A0020C517 /* Sound */,
     );
     path = Resource;
     sourceTree = "<group>";
};

对于第一种方式：

好处：这样磁盘上的结构和 Xcode 中的项目结构就是一一对应的。让 Xcode 的目录结构能够跟磁盘文件的结构保持一致，这样让在找代码文件的时候能够更清晰。

坏处：创建和管理代码文件时就要麻烦一些。当你在 Xcode 项目中把一个文件从一个目录拖动到另外一个目录中时，它在 Xcode 中显示的目录路径改变了，但是它在磁盘上的物理位置并没有发生改变，这就会造成混乱。所以，为了保持对应关系，当你要改变文件的目录时，你需要手动到 Finder 文件夹中去移动文件，再在 Xcode 项目中去删除相应的文件引用再重新添加到新的目录下。这又带来了另外一个问题，就是 git 对文件的版本管理信息会被破坏，你可能无法看到这个文件之前的版本了，这个代价可就大了。所以，如果要采用版本管理，就要好好考虑这个因素了。

对于第二种方式：

好处：直接在 Xcode 中管理项目，添加、删除、移动都很方便。采用版本管理时，代码文件的版本信息不会因为移动而丢失。

坏处：Xcode 中的项目结构和磁盘上的结构不能一一对应。
根据上面的对比，

我的建议：对于固定的可复用代码可以采用第一种方式，因为也不会经常移动。复用时，挪动起来也好操作；对于大的目录结构，比如一级目录：Utilities、Helpers、Features、Resource 等目录可以采用第一种方式。其他的情况均采用第二种方式就行了。

###我现在项目的工程结构设计样例

废话不多说，最后给大家举一个我现在项目通常采用工程文件设计结构的例子吧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

1.主目录结构
-ProjectDemo
	--Features         //模块。包含各个模块的Model,View,Controller,Manager
	--categories			//类目。包含各种类的分类
	--Frameworks		//系统框架。包含导入的系统的框架
	--Helpers			//帮助类。包含网络，数据库，归档，定位等操作类的封装和实现
	--Utilites       //工具类，一些非对象的，而是类方法调用的类
	--Vendors			//第三方库。部分需要修改或者不支持cocoapod的第三方的框架引入
	--Config				//配置。包含宏定义文件，全局配置文件，全局常量文件，颜色配置文件
	--Resources			//资源。包含plist,image,html,bundle，Localizable.strings等
	--AppEntry			//程序入口。包含AppDelegate,main.c,info.plist
-PAHealthTests
-PAHealthUITests
-Products           // 系统自动生成的.app所在文件夹
-Pods					// 采用 CocoaPods 管理的第三方库。

2.模块目录结构
-- Features         
	---Base				//MVC的基类或者通用类
		----Models		//数据模型
		----Views		//视图
		----Controllers	//控制器
		----Manager		//store层的数据管理类
	---Home
		----Models
		----Views
		----Controllers
		----Manager
	---UserCenter
		----Models
		----Views
		----Controllers
		----Manager
	---UserEntry
		----Models
		----Views
		----Controllers
		----Manager

	---Payment
		----Models
		----Views
		----Controllers
		----Manager
	…

###参考文章

iOS项目的目录结构

iOS应用架构谈 开篇