不要买关东升的《iOS 开发指南》

如果你去京东上搜“iOS”，出来的第一本图书就是关东升老师的《iOS 开发指南》，这本书销量超过 6 万册。如果你了解技术类图书的销量的话，就会知道 6 万册绝对是一本超级畅销书。

但是，关东升老师其实并没有多少一线的实战开发经验，属于一直在培训界打拼的人。我们当然不能以行业论英雄，我主要想说的是，关东升老师书有一些内容是非常错误的，会误导初学者。

《iOS 开发指南》是一本入门书，写一本 iOS 的入门书，要出错其实是挺难的。比如你写 Objective-C 和 Swift 的语法，写控件的使用，这些有大量的官方文档作为参考。关老师的书在这方面是没问题的。但是这部分内容其实非常多，比如某个控件的 API 和使用示例，与其看书不如用到的时候查官方文档。这部分内容占了厚厚好几百页，实在没什么营养。

这本书比较有争议的是其中的第11章：iOS分层架构设计。我记得几年前，关老师在某个技术大会上还做过这方面的分享。我真的认为这不是一个好的设计方式。我早年做过几年 Java 的服务器开发，关老师的这种设计很可能因为他以前也做过服务器端开发，但是服务器端的开发经验直接套在 iOS 上其实是极其不合适的。关老师不但直接用在 iOS 上了，而且用了非常重的方式：把每一层封装成一个工程，让一个项目以多个工程依赖地方式来构建，这样的设计是没有价值的。

通常情况下逻辑分层是好的，因为每一层可以定义清楚职责，如果每一层都用协议来对外暴露接口，那么我们也可以更方便地做测试和解耦。

但是，以工程为粒度把项目的层次拆解成多个子工程，完全就是用力过猛了。因为工程为粒度的拆解通常只是针对可复用的组件，这些组件应该是有明确的功能。可以将它拆解成工程，就可以以静态库或者动态库的方式来依赖，并且可以给别的项目复用。

但是我们想想关老师的设计，他把一个产品功能实现的每一层变成了一个工程，每一层在工程粒度上没有完整的功能，所以基本上不能以独立静态库的方式存在。或许你要说，这样测试起来方便了，但是即便是不以工程为粒度组织项目的逻辑层次，在一个工程中我们同样可以对每一层进行测试。

我和很多同行讨论过这种架构，我们都认为这确实是一个没有任何价值的、非常牵强的架构设计方式。另外，就我所知，我没有听过国内的一线互联网公司里面，有哪家公司会按照这种方式来组织 iOS 项目的代码。如下是王巍发的关于这个内容的微博：

考虑到关老师的书读者数量巨大，我还是希望他能够修改相关章节，否则确实可能把 iOS 新手带入误区。或许很多人还没有听过关老师，也没有看过这本书，所以这里分享该书某一页的内容：

一个读者说，上面这个 10 种架构是旧的版本，新版本是 16 种架构。我不知道 iOS 开发新人看了这个内容会是什么想法，我只想告诉你：这是错的！

最后再说几件事情。

一、大家一定要有独立思维，关老师这本书评价这么高，我真是想不明白啊。稍微请教一下身边的高手，或者看看 GitHub 上的开源代码，就能知道没有人这么写 App 的。

二、关于 App 架构，其实简单的分层就可以很好用了，你可以翻我以前写的 《被误解的 MVC 和被神化的 MVVM》。当然，你如果想试试 RAC 或 RxSwfit 的响应式写法，我觉得也是有挺多合适的场景的。

就酱。