@ichanne Thanks 。

国内似乎 Core Data 确实用得比较少，估计是因为学习成本比较高。但是在国外其实非常多的开发人员在使用 Core Data 。熟练以后 Core Data 还是在很大程度上可以简化开发和数据库操作的。

本来我们挺犹豫是不是要翻译这本书，因为可能在国内销量不会很好，但是最后还是决定做这件事，一来显得完美一些，二来毕竟不能以在某个地方的使用广泛程度来判别一项技术的好坏。

在 Core Data 的学习过程中其实涉及到很多多线程处理和方式和思想，这在其他领域的开发以及自己在技术上的成长来说，也是非常重要和不可逃避的环节。

根据经验，一般来说在充电的时候会比较常见。可以录像去，放给他看。

我的 iPad 之前类似问题，录了短视频去，直接换新了。

写。其实一开始都会一头雾水，不知道测试是用来做什么的，也不知道为何要写或者是不知道要如何写。但是如果你有几次软件交付的经历的话就大概能知道测试的重要性了。

写测试说白了就是付出和收益的权衡。对于 app 开发来说， UI 层比较难写测试，加上 app UI 其实并没有太多泛用性，所以测试能带来的好处不明显，甚至无法抵消编写测试的花费和之后维护测试带来的麻烦，如果规模不大，这种情况不写 UI 测试，而是靠人力和 QA 部门来保证也是可行的。但是对于开发框架，或者 app 中的逻辑部分来说，单元测试可以保证软件质量和你的开发信心，能有效缓解开发压力，是非常划算和值得的投入。

作为起步的话，你可以不用太关心什么是单元测试或者应该怎么写，而只是简单地把你本来需要启动 app 去给输入切断点来确认或者调试的步骤用代码在测试中描述就可以了，这样你就不用一遍一遍去运行程序。 Xcode 自带的 XCTest 就是一个很简单易用的测试框架，很适合上手。在有一定测试经验和编程范式的基础以后，可以开始考虑要如何写代码才能方便测试，一般来说易于测试的代码总比无法测试的代码更容易维护。

在我看来，好的测试最大的好处并不是什么提高软件质量或者保证开发进度，而是可以帮助你维持很好的开发心情，这是非常重要的。

虽然回头看看不太愿意承认，但是不得不说...和我当年走上 iOS 开发道路的理由很像..

两者都可以啊..前者复古点但是要改起来灵活解耦好一些，后者稍微方便些但是变动起来困难一点...做 app 的话无所谓哪个都行..感觉并没有很麻烦吧..

系统自带的就挺好。

有时候在想我要是去参加一期培训美化一下简历的话也许每个月也能多拿个三五千..还是挺有诱惑的..

什么叫动态隐藏显示？ hidesBottomBarWhenPushed ?

- -.....你当是前端么

新建了个工程试了一下，并没有能重现。也许是你的项目的问题，或者是特定 SDK 、 Xcode 版本或者系统版本的问题？

本来就是消耗品..用两年就换了..不用纠结-。-

@WildCat 确实不容易做异步，如果有异步设置图片的需求的话是比较蛋疼...如果内容不多或者图片尺寸固定的话就怎么玩儿都可以了，否则的话还要再想办法。还是要具体情况具体分析，要是需求的排版再变态一点，比如各种 css 控制，那就很难有一个好的解法。

其实在 cell 里直接显示可以各种变化的 web 的内容这种事情，本身就不是 cell 的设计意图，所以这样的需求在这里用 cell 来实现其实就是反模式的，自然也不会有特别成熟可以套用的方法。

琢磨一下把要显示的内容解析并且建立一个好的 model ，然后复用地用 cell 来用比较统一的方式显示，可能会是比较 iOS 的解决方式。要是原来的 web 内容就非常复杂并且一定要原封不动地实现的话，那干脆整个直接上个 webview 会更好吧。

-.- ReactiveCocoa ， combineLatest

好吧，直接 dispatch_group 多好..

@Ixizi 编译分为前端和后端，对于 Swift 来说，和 Objective-C 编译上的区别主要在前端（废话...后端的话 LLVM 能编译的语言都是一样的...）。 Swift 编译器先把 Swift 源码转换为 SIL ，就是上面 @sherlocktheplant 说的 Swift Intermediate Language 。 SIL 基本就是对 Swift AST 的组织，然后中间多了一步从 SIL 优化生成 LLVM IR 。到这里之后的后端的话，是和 objc 的处理基本是一样的，因为输入的同样是 LLVM IR 。

转换成 Objective-C 的说法简直是无稽之谈...

习惯一个月就好了…而且如果你要写 Objective-C 的话，日版键盘效率要比英键高不少（一开始我也是抗拒的，但现在我已经不会用英式键盘了…）

为什么老想着把 webview 塞到 cell 里这种邪门歪道，而不去花哪怕那么一点点时间去了解一下 Text Kit 呢？
给几个关键字吧
1. 用 textview 做， subclass 一个 UITextView 是很好的 start point
2. 超链接处理 -> characterIndexForPoint:inTextContainer:fractionOfDistanceBetweenInsertionPoints:
3. 图片 -> NSTextAttachment

当然你如果很赶工期的话直接用 DTCoreText 应该也不错，不过你就错过了一个尝试使用 Text Kit 的好机会，会比较可惜。

@WildCat 你忽略了 Unity Pro License 很贵的这个现实- -...

1. 这里的 images 指的应该是 dynamic framework 本身，而不是图片。比如加载动态库时找不到的时候报错是这样的：
dyld: Library not loaded: XXXX.framework
Reason: image not found

问题在于加载库的速度慢。

2. 实测了一下，似乎第一次有点慢，后来的几次启动看起来没什么问题 https://infinit.io/_/Aen5R2b

3. 不过有个例外，就是如果刚连上 lighting cable 的时候， iTunes 和 Photo 会打开读取 iPhone 内容，这个时候打开 app 的话会比较慢。但是因为同时有不少 I/O 在做，也可以理解。在等待 iTunes 和 Photo 完成工作后，启动速度和上面的视频一样。