原文链接：http://qingmo.me/2017/02/07/fakedata/
欢迎关注我的微博：http://weibo.com/shellhue
当工期比较紧的时候，项目开发中会经常出现移动端等待后端接口数据的情形，不但耽误项目进度，更让人有种无奈的绝望。所以在开发中，我们常常自己做些假数据，以方便开发和UI调试。然而做假数据方法不同，效率和安全性都各不同，有时稍有不慎，还会产生很大的bug。因此本文拟结合我在贝聊的开发经验，讲一讲我们组在iOS开发中曾经用过的做假数据的方法及其优劣。
示例项目
为方便下文的说明，本文主要以贝聊家长版app发现首页的热门帖子列表的实现为例。热门帖子列表的样式如下图：
sampleCell.png
这是比较常见的列表，用常用的UITableView实现即可，但需要自定义一个的UITableViewCell的子类ExploreTableViewCell。项目中，ExploreTableViewCell并没有用xib实现（因为xib日后不好修改，且代码复用性差），而是通过SnapKit用纯代码布的局，具体的布局代码大致如下：
import UIKit
import SnapKit
class ExploreTableViewCell: UITableViewCell {
let thumbnailImageView: UIImageView
let titleLabel: UILabel
let avatarImageView: UIImageView
let authorNameLabel: UILabel
let viewCountLabel: UILabel
let commentCountLabel: UILabel
//...其他属性
override init(style: UITableViewCellStyle, reuseIdentifier: String?) {
//创建view
thumbnailImageView = UIImageView()
titleLabel = UILabel()
avatarImageView = UIImageView()
authorNameLabel = UILabel()
viewCountLabel = UILabel()
commentCountLabel = UILabel()
//...其他view的创建
super.init(style: style, reuseIdentifier: reuseIdentifier)
//设置view
titleLabel.numberOfLines = 2
titleLabel.textColor = UIColor.black
titleLabel.snp.makeConstraints { (make) -> Void in
make.left.equalTo(thumbnailImageView.snp.right).offset(15)
make.right.equalTo(contentView.snp.right)
make.top.equalTo(contentView.snp.top)
}
//...其他view的设置
}
//...其他业务代码
}
源码中写死
源码中写死数据是最便捷的假数据做法，项目很赶时，为最快速的看到UI效果，一般都会采取这种假数据方式。比如在上述热门帖子列表示例项目中，为查看整个ExploreTableViewCell的布局效果，在titleLabel等subview的设置位置，直接写死假数据。
//...其他代码
override init(style: UITableViewCellStyle, reuseIdentifier: String?) {
//...其他初始化代码
//写死的假数据代码
titleLabel.text = "这是一个标题这是一个标题这是一个标题这是一个标题这"
thumbnailImageView.image = UIImage(named:"sampleImage")
avatarImageView.image = UIImage(named:"sampleImage")
authorNameLabel.text = "作者名"
viewCountLabel.text = "1000"
commentCountLabel.text = "1000"
//...其他初始化代码
}
//...其他代码
源码中写死假数据虽然方便，但稍有不慎就容易直接上线上环境（因为测试在测试时一般都会有数据，假数据被遮盖了），演变成一个有可能非常严重也有可能很轻的bug（贝聊就切实出现过这样的bug，而且还是个影响广泛的大bug），为安全起见，所有写死的假数据都应该包在条件编译宏内。
//...其他代码
override init(style: UITableViewCellStyle, reuseIdentifier: String?) {
//...其他初始化代码
//写死的假数据代码，包裹在条件编译宏内
#if DEBUG
titleLabel.text = "这是一个标题这是一个标题这是一个标题这是一个标题这"
thumbnailImageView.image = UIImage(named:"sampleImage")
avatarImageView.image = UIImage(named:"sampleImage")
authorNameLabel.text = "作者名"
viewCountLabel.text = "1000"
commentCountLabel.text = "1000"
#endif
//...其他初始化代码
}
//...其他代码
包在条件编译宏内，就可以保证不污染正式环境的代码，从而保证安全性。
利用单元测试的网络请求stub做假数据
在源码中写死假数据，有以下三个缺点，
- 污染源代码
假数据写在源代码中，即使用宏包裹起来，只是保证了一定的安全性，但依然污染了源代码，如果上线前忘了把假数据代码移除，它一直会残留在源代码中，而且还会一直影响DEBUG环境的调试。 - 假数据散落四处，无法集中管理
本文示例代码的假数据虽然写在一块，但在实际开发中，并不是所有的UI代码都在一个文件中。即使在一个文件内，往往各个属性的初始化和设置也不在一个方法内。代码一多，基本很难管理。 - 扭曲了数据的正确流通
正确的数据产生方式，应该是发一个网络请求，然后把请求回来的数据转成model，最后通过model给各个UI组件填充数据。而在源代码中写死假数据，直接打乱了数据的正确流通，这会使得整个开发的逻辑是颠倒的，不但使开发更容易出bug，而且逻辑流的切换带来的开发效率和开发感受都很差。
较好的假数据方式，应该尽可能的不污染源代码，不扰乱正常的数据流通，而且能集中管理。在研究单元测试时，我无意中发现stub某个页面请求数据的网络请求即可达到这种完美的假数据效果。
首先按正常的流程开发整个功能，（在开发中，我总是倾下于先创建Model，而不是先写UI）
- 创建Model
- 创建ViewController
- 创建View等UI元素
- 在ViewController中完成网络请求的发起，并完成从网络数据到Model的转换
- 应用Model填充UI
整个功能开发按照有真实网络请求进行，但事实上并没有网络请求，因为后台并未搭好，没关系，先按照后台给出的接口和数据格式定义，创建一个本地JSON文件。对于本文的示例（假定只有列表数据）来说，文件名暂为hotTopics.json，内容大致如下（贝聊发现首页实际上有很多其他元素，网络请求返回的JSON也比这个复杂的多）：
{
hotTopics: [
{
"title": "这是一个标题这是一个标题这是一个标题",
"thumbnail": "https://api.beiliao.com/explore/image/fdlafjlfp34523.jpg",
"author": "小黄老师",
"authorAvatar": "https://api.beiliao.com/explore/image/fdlafjlfp34523.jpg",
"commentCount": 1000,
"viewCount": 3000
},
{
"title": "这是另外一个标题这是另外一个标题这是另外一个标题",
"thumbnail": "https://api.beiliao.com/explore/image/fdla32131fjlfp34523.jpg",
"author": "小李老师",
"authorAvatar": "https://api.beiliao.com/explore/image/fdl232afjlfp34523.jpg",
"commentCount": 1030,
"viewCount": 3400
}
]
}
然后在ViewController中stub本ViewController中所有的网络请求，我在开发中用的是OHHTTPStubs，大致的代码如下：
class ExploreViewController: UITableViewController {
//...其他代码
override func viewDidLoad() {
super.viewDidLoad()
//...其他代码
#if DEBUG
stubRequests()
#endif
//...其他代码
}
//...其他代码
func stubRequests() {
stub(isPath("/explore/hotTopics")) { _ in
let stubPath = OHPathForFile("hotTopics.json", type(of: self))
return fixture(filePath: stubPath!, headers: ["Content-Type":"application/json"])
}
}
}
注意所创建的JSON文件一定要加到项目目录中。添加完上述代码后，path为/explore/hotTopics的网络请求将被stub，返回的数据将是所指定JSON文件中的数据，这样就跟真实的网络请求没有任何的区别了。而且利用OHHTTPStubs还可以模拟网络请求失败、网络请求超时以及throttle等各种网络请求状态，从而更全面的调试UI和整个功能。
利用stub做假数据可以真实的做到基本不污染代码、集中管理和完全真实的数据流通流程，与在源码中写死这种方式相比，近乎完美。然而当你真正用过一段时间后，你会发现，这种方式还是有一个致命的缺点和一个不那么重要的缺点。
- 不适合做UI调试
因为每改动一次数据，都需要重新编译，而iOS编译是很慢的，尤其是Swift。而要想做UI调试，频繁的改动数据，查看各种边界条件下的UI是必然的。 - 还是污染了代码
虽然相较上一种方法，污染非常小，但或多或少还是有污染的，有强迫症的人是受不了的，而且有时测试说是个bug（测试包一般是BETA环境），你build一下发现数据是假数据，不是网络请求的数据，还需要找到stub网络请求的位置，然后把代码注释了，也是极其的烦人的。
如果能做到每改动一下数据，然后刷新一下就可以看到了，像网页一样，而且真的一点都不污染代码，那就是完美的解决方案。
动态注入
如果只是想做到，每改动一下数据，然后刷新以下就可以看到了，像网页一样，Xcode的动态注入是可以的，现在比较流行的是 injectionforxcode和dyci-main两个库。利用单元测试的网络请求stub做假数据，然后结合动态注入，理论上应该可以做到实时刷新，但事实上injectionforxcode和dyci-main的体验都是很糟糕的，时灵时不灵，我用过两次后，基本就不想碰了，我宁愿编译慢一点，当然我从来没有用动态注入去做假数据的实时刷新，但我觉得应该是个方案。
但这个方案即使可行，也还是会污染代码，并不算特别彻底的方案。真正彻底的方案，与用stub拦截网络请求的思路相同，只是要将网络请求的拦截放到整个APP外，有两个方案可行。
本地自己搭个服务器
第一种就是本地自己搭个服务器，然后把开发时需要拦截的网络请求地址改为自己搭建的服务器地址，然后返回自己自定义的JSON数据。但这种方式也有三个缺点：
- 有一定门槛
虽然搭建服务器是很简单的事，并不是所有人都会，也是需要一定的学习成本的。 - 还是要修改源码中网络请求的地址
这虽然已经把源码污染降到最低了，但毕竟还是有。 - 要想模拟不同的网络状态，还需去修改服务器的代码，不方便。
综合起来这种方案性价比并不高，但确实有一定的趣味性，毕竟自己折腾东西嘛。
网络代理
第二种就是利用现有的网络代理软件，直接拦截对应的网络请求，然后返回本地写好的JSON数据。我最终采用的这种方案（因为我嫌配置服务器麻烦）。将APP中所有的网络请求都代理给网络代理，然后指定特定的网络请求返回本地JSON数据。这种方案的好处不言而喻，
- 真正的不污染源码
源码中任何代码都不用动，真正做到了干净绿色无污染。 - 拦截起来很方便
许多网络代理软件，都自带拦截甚至改写网络请求的功能，所以启动拦截功能很方便。 - 方便调试
网络代理一般都有改变一个网络请求状态的功能，可以轻松实现返回网络错误、网络超时和延迟网络请求等不同的网络请求状态的功能，非常方便。
我常用的网络代理就是Charles，相信大家都有耳闻。Charles有个maplocal的功能（在工具菜单下），如图:
charlesmaplocal.png
mapLocal的设置也很简单，在Location一栏填上所要拦截的网络请求的host、path或者完整的URL，然后在LocalPath一栏选择对应的本地JSON文件即可，记得勾选启动。
maplocal.png
这样简单的设置后，所指定的网络请求都会返回本地对应的JSON文件数据。然后你将发现这种假数据之完美，简直让人窒息。
编译后，如果想改变一个数据，看看对应的UI，直接去改变本地JSON文件，然后下来刷新一下，你会发现显示的数据就是刚刚改动的数据，简直要感动哭了。
但事实上这种方式还是有一个小小的缺点，即Charles与Shadowsocks不能同时开着，因为Charles不支持父代理。搞编程开发，为方便查阅资料，翻墙软件会一只开着，但这样Charles就不能开着，想用的话，又要先退出Shadowsocks，再打开Charles，这让我很头疼。最后只能在真正写完所有的逻辑和UI后，关闭Shadowsocks，打开Charles，集中调试。
=============2017-03-04更新开始===============
文章发出后，不少读者反馈，
- Charles与Shadowsocks可以共存
具体怎么共存，我还有待研究，后续文章再做补充 - 假数据的数据应该能随机生成
具体由json server、mock.js和Charles三者结合完成，有意思，值得研究，待后续文章详细补充。
=============2017-03-04更新结束===============
总结
一路试下来，其实只有第一种源码中写死和最后一种网络代理两种假数据方式最常用，虽然第一种缺点最多，但方便快捷，最后一种虽无任何缺点，但启动还是有点麻烦。
写了这么多，还是希望对大家有所启发。
欢迎关注我的微博：http://weibo.com/shellhue
网友评论