如果你是一个有经验的工程师，在初次看到一个全新的概念时一定会想：这个东西会不会又是一个强行造出来的轮子？使用起来是不是门槛比较高，适不适合推广？ 关于RxSwift/RxJava/RxJS的具体使用介绍网上非常多，这篇文章并不是要再一次介绍如何使用，也不打算讨论函数式、副作用等话题，而是想写一些关于Reactive这个话题一些更本质的思考。 Reactive Programming这个词理解起来很容易让人一知半解，感觉和声明式、函数式有一些关系，而且也感觉和Rx系列有什么关系。那到底它的定义是什么呢？看看维基百科上的解释（如果有更精确的表达欢迎指出）： In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change.

iPhone 作为一个移动设备，其计算和内存资源通常是非常有限的，而许多用户对应用的性能却很敏感，卡顿、应用回到前台丢失状态、甚至 OOM 闪退，这就给了 iOS 工程师一个很大的挑战。 网上的绝大多数关于 iOS 内存管理的文章，大多是围绕 ARC/MRC、循环引用的原理或者是如何找寻内存泄漏来展开的，而这些内容更准确的说应该是 ObjC 或者 …

对于一个用户每天打开多次的app来说，用户会重复经历这样一个过程： 找到app图标并点击 系统启动动画（从icon放大到全屏） Launch Screen 停留一段时间 （有些app会展示自己的广告页，看3~5秒广告） 进入主界面，开始加载动画 网络加载完成，开始渲染界面 加载返回数据中的图片 以上是用户看到的加载过程，一定程度上决定了用户对app是否responsive的印象。 从技术上来说，app可以掌控并且优化的，可以按顺序分为四个主要部分： 应用本身被系统加载到内存 应用执行启动代码 第一屏内容的网络请求 布局计算和文字图形渲染 在即刻，我们通过持续的分析、监控和优化，将整个流程所需要的时间压缩到1秒左右，使用户几乎感觉不到app重启的过程。接下来我们会一一讨论，如何把每个环节都压缩到极限。 应用被系统加载 虽然app代码是“被加载”的，开发者能控制的部分很有限，但是我们可以把代码组织成“最适合被系统加载”的形式，以降低系统的负担，达到加快加载速度的目的。

似乎听起来这是一件很小的事，为什么要写一篇文章呢？一开始我们也觉得简单，但是最后这件事仍然是超出了我们的预期范围，因此值得稍微整理一下解决的整个过程。 清Badge？没那么容易 对于一个app，如果在home screen上的badge一直消不掉，是一个比较烦人的事。因此一般来说，app需要在未读消息都处理完的时候，通过代码把badge清零（通过本地设置badge或者远程推送badge）。 不过这样一来会有一个副作用：一旦app的badge被设置为0，系统通知中心里先前的推送都会被清空，这是一个系统隐藏的逻辑。我们的问题就是：如何在badge清零的同时，保留通知中心的推送？ 一般思路 通常来说对于这类业务逻辑并不复杂，同时跟系统API紧密相关的需求，我们会尝试通过以下几个步骤来解决： 查看文档（我们发现applicationBadge和远程推送都可以设置badge，但是无法解决通知中心被清空的问题）

即刻作为一个创业公司，不管是团队还是产品都在快速变化。在提升每个人自身能力的同时，团队协作也慢慢成为一个重要的部分，因此我们不仅引入了Scrum，也在其基础上根据自身情况不停的调整。 先看下没有Scrum时的问题 产品发布周期不稳定，迭代缺乏节奏感。 开发缺乏明确任务时间表，时间安排全凭自己。对于工程方面的工作比较有利，想做的可以马上做，但是对于团队协作开发的需求效率较低 产品需求不够明确（只有idea，缺乏具体细节）时就开始动工。不可否认这样的好处是小功能可以快速试错，但是随着项目发展，当多team协同开发大功能时，会极大地增加沟通成本。比如由于文档不够清晰，客户端A去跟产品经理B确认一个细节，完成了以后还需要通知其他产品经理C、客户端D、后端E、测试F等等，有时候还会推翻之前的结论。这样一来虽然看起来大家都在热火朝天地讨论，但是效率其实不高。 产品和开发对于工期的预期不一致，时常会互相pending，客户端等后端接口，后端等具体需求等等。

数据序列化是每个app开发者必须面对的工作。 在OC年代，为了实现数据序列化（记得Core Data和NSKeyedArchiver吗？），我们必须为一个数据结构实现NSCoding协议，写一大堆重复啰嗦的代码，或者借助一些第三方库（如Mantle/MagicalRecord）实现。后来由于JSON的流行，iOS逐步引入了JSONSerialization和JSONEncoder类来帮助我们操作。 到了Swift年代，第三方库SwiftyJSON和ObjectMapper都曾经作为JSON转换的中流砥柱，只是这两者还是免不了“手动指定字段和JSON字典映射关系”的工作。于是阿里想了个黑科技（HandyJSON），通过分析Swift数据结构在内存中的布局，自动分析出映射关系，进一步降低开发者使用的成本。 自从Swift4中开始从语言和系统(Foundation)层面支持Codable(Encodable&Decodable)协议，叫好的声音不断，颇有取代ObjectMapper之势；对于HandyJson来说，也有了更强的官方版本——如果原生已经支持了，何必用第三方库呢？

说起Monad，这个词并不直白，再看它的中文译名“单子”，同样让人云里雾里。其运用的场景，常常跟函数式编程密切相关，这对于iOS开发来说，又是一个距离日常工作比较远的概念。在一开始学习时我们也碰到了一些障碍，再看了几篇文章，听了几次分享，也没有完全理解。 如果从数学或者函数式编程的意义上来解释，会显得非常枯燥——如果我们不知道它对于日常使用有什么帮助，而它本身又比较难懂，又为什么要去了解呢？ 我们不妨试试从应用的角度切入，看看Monad究竟能做些什么。希望这篇文章能带给你一些启发。 对于iOS开发来说，OC的年代并没有那么明显的函数式的概念。有一次看到Stackoverflow上有人问OC的链式调用应该怎么写，有人吐槽答： 如果没办法把多个函数优雅地拼接在一起，那写函数式的痛苦可想而知。幸运的是Swift带来了很大的改变。 一个实际的例子 即刻从一开始就是一个纯Swift项目，并且在15年下半年用上了RxSwift，迄今已有两年多的时间，积累了一定的实践经验。

说到视图性能，不能不提到UITableView，对于它的滚动性能的讨论和优化从未停止。在我们的探索过程中，尝试过以下一些措施： Cell reuse，Apple原生支持 estimated cell height，iOS8开始原生支持 手动将计算完成的height缓存(或使用FDTemplateLayoutCell等框架自动计算) prefetch API，iOS10开始原生支持 异步加载cell内容，文字图片等 还有一些诸如圆角、opaque等普通UIView性能瓶颈已经在第一篇中讨论了一些，这里不再赘述。 然而我们会想，cell布局是否必须要在主线程，图片和文字渲染是否必须要在主线程，cell预加载是否可以更完善更智能？仍然有许多问题等待被解决。 UITableView加载Cell的过程 我们先看一下一般UITableView加载Cell的过程： cellForRowAtIndexPath，读取model

作为Facebook系的大将之一，Instagram在实践React-Native这件事上当仁不让地作为开拓者披荆斩棘，并分享了一些他们的经验。国内也有不少大小厂小心翼翼地尝试着RN和weex，享受期待来的前所未有的优势，也踩着一个个坑。要不要入坑？可能是迟早的。那什么时候引入比较合适，是迟还是早呢？ 一些Web和js实践 由于我之前做过Angular和Ionic（hybrid），与所有前端工程师一样，每天都享受着web开发带来的好处（相对native）： 显示什么（HTML）逻辑（Javascript）和样式（CSS）完全分离 对代码任何修改都可以在1秒内在浏览器内看到结果，开发效率非常高 只要有重复的流程操作，一定有一系列强大的自动化工具等着你，社区活跃程度比native高很多 功能更新不需要任何app store的审核 绝大多数bug都由浏览器捕捉，几乎不会闪退，并且bug fix可以在很短的时间内立即生效