2017年已经过完，终于有时间写下总结，一直想写，却一直不知从何处下手。在2018年的第一天为整个去年画上一个句号吧。

当团队不在是一两个人，业务不再是简单几条线，业务随着时间的推移变得有多又混乱时，传统的一个工程或者一个workspace来开发已经显得不再方便，各个业务的代码管理在一起也显得结构比较混乱，比如Vender、Utils、Helper、Manager、Category、Network以及业务代码等。我们需要构建基础平台，将基础平台中的组件以Library的方式交付业务方使用。同样，对于业务众多的App，每个业务模块也可以使用Library的模式，通过CocoaPods集中构建到一起。

现在遇到很多朋友都在使用MVVM的开发方式，在iOS中使用MVVM的开发方式势必会用到ReactiveCocoa（RAC），而大部分人对其并不是很理解，而只停留在使用的层面，有些人能够说出RAC调用过程是先创建信号、然后订阅信号、然后发送信号。总的流程来讲是这个样的，但是看源码的话，里面细节还是蛮多的。下面分析一下RACSignal的Subscription过程。

当和底层系统交互时，必须花费大量时间为任务做好准备。调用内核或者其他系统层需要切换上下文，这也是比在进程内部调用昂贵的原因。因此，许多系统库提供异步接口，允许您的代码提交请求到系统，且请求执行时继续做其他工作。GCD允许您使用块和调度队列提交请求并将结果返回到您的代码来建立这种行为。

GCD调度队列是执行任务的强大工具。调度队列允许您相对于调度者异步或者同步的执行任意代码块。您能够使用调度队列来执行几乎所有在单独线程上执行的任务。调度队列的优点是它们比线程代码更简单且更高效。

Cocoa操作（operation）是一种面向对象的方式来封装您想要异步执行的工作。操作被设计用来和操作队列（operation queue）一起使用或者由他们自己使用。因为他们是基于Objective-C，操作常用于基于Cocoa的OS X和iOS应用程序。

用户以多种方式操纵他们的iOS设备，例如触摸屏幕或摇动设备。 iOS会解释用户何时以及如何操作硬件并将此信息传递到您的应用程序。 您的应用程序以自然和直观的方式响应操作的次数越多，对用户而言越有吸引力的体验。

手势识别器是附加到视图的对象，将低级别事件处理代码转换为更高级别的操作，它允许视图以控件执行的方式响应操作。 手势识别器解释触摸以确定它们是否对应于特定手势，诸如滑动，捏合或旋转，如果识别他们特定的手势，他们发送动作消息到目标对象。 目标对象通常是视图的控制器，它响应手势，如下图所示。 这种设计模式既强大又简单; 你可以动态确定视图响应的动作，你可以向视图添加手势识别器，而无需对视图进行子类化。

KVO和Notification是Objective-C语言中观察者模式的两种实现机制。KVO指定一个被观察对象，当被观察对象某个属性发生改变时，观察对象会获得通知，你不需要给被观察的对象添加任何额外代码。

KVC(Key-Value Coding)是Objective-C提供的一种利用字符串来间接访问对象属性的一种机制，它是通过访问器去访问对象属性的另一个可选方案。非正式协议NSKeyValueCoding对其接口进行了定义，NSObject中提供了接口的默认实现。

首先，串行并行针对的是队列，同步异步针对的是任务；如果觉得队列和任务不太好理解咱们可以打个比方，假设一个应用程序是一个工厂，那队列就是里面的流水线以及线上的工人，而流水线上的工人所要处理的产品就是所谓的任务。

iOS10正式版发布之后，网上各种适配XCode8以及iOS10的文章满天飞。但对于iOS10适配远程推送的文章却不多。iOS10对于推送的修改还是非常大的，新增了UserNotifications Framework，今天就结合自己的项目，说一说实际适配的情况。

在使用CollectionView的时候，不复杂的情况下我们使用UICollectionViewFlowLayout来设置Cell直接的间距，主要有以下几个地方需要设置：

在使用ReactiveCocoa前，必须要了解RAC和内存管理，有关RAC内存管理，参考下面这篇文章：RAC和内存管理 其中就讲了RACObserve的内存管理过程，也可以直接看源码。

上个版本经过内存等方面的优化，在听云崩溃报告中已经成功将Crash率降低到8‰一下，看了下最新版本七日的Crash率在4.87‰，终于达到标准水平了。下面是听云崩溃率标准：

本来今天想在自家app上购买莫斯利安，发现正常购买活动已经结束，价格恢复到以前了。但是我们有团购活动啊，一样也是很便宜的哦。

昨天看在听云上的Crash记录，看到我们App中有和视频播放相关的Crash。昨天就点了几次发现从视频播放进入产品详情，并进行商品购物下单，最后从订单详情返回到购物车的时候App Crash。操作轨迹如下：

关于CoreData的介绍太多，网上一搜大把全是，这里不介绍CoreData，直接上代码，注释写的很详细，应该很容易理解，暂时现做简单的增删该查，后面有时间再做修改完善。

在iOSApp内存优化（二）这篇文章中解决block循环引用的时候曾经提到@weakify和@strongify，下面就仔细说下这块的内容。

在当今的app中，几乎所有的app都需要进行图片缓存，而在电商App中，图片在线加载到处可见，首页产品展示、分类列表类别icon，产品列表产品缩略图，产品详情主图和图文详情等等等。。。

在iOSApp中经常使用的一个组件叫NSTimer，但是它又是非常容易导致内存泄露组件。我们可能在Controller、View和ViewModel中使用到它，比如：做banner的自动翻页、开机广告倒计时、商品整点抢购倒计时等等等……

在我们的app的业务层中使用了MVVM架构，为了更好的实现MVVM，我们在CocoaPods中引入了ReactiveCocoa， 这样就会大量使用Block，很多时候Block也的确比Delegate，Target-Action使用起来要方便。顺便再推荐个第三方类库BlocksKit，但是在使用Block的时候最容易出现的问题就是循环引用，就循环引用的问题，循环引用危害非常大，controller中只要有循环引用出现，就controller就无法释放，导致app使用内存越来越大。

先吐槽下公司最近的变化，近两个月服务器端的同学将后端进行重构，重新设计了商品模型、网关和API调用。使用Alibaba开源的Dubbo分布式服务框架进行分层架构，并对后端服务最大化的解耦。