[TOC]
一。UITableView+FDTemplateLayoutCell
- 介绍
第一个是让我从复杂的tableviewcell布局中解放出来的一个category：UITableView-FDTemplateLayoutCell，我在上一篇文章中有提起：(iOS)使用auto layout进行复杂布局时，UILabel的相关trick
作者也很能写，上面的地址中有作者的文章，介绍这个库的使用方法。
- 阅读和评论
- 使用block，将UITableViewDelegate最重要的两个函数：
heightForRowAtIndexPath:和cellForRowAtIndexPath:给统一了
- 通过block让用户装填cell的信息后，使用系统提供的
systemLayoutSizeFittingSize:计算出在实际的cell大小（fd_heightForCellWithIdentifier） - 对tableviewcel的加载进行了优化，即在idle阶段pre cache了cell height （
fd_precacheIfNeeded）
赞！
二。Shimmer
-
介绍
Shimmer是facebook在paper应用中采用的loading UI，该效果让字体闪烁出银色的光泽，很赞。
（图片来自Shimmer在github上的主页） 阅读和评论
- Shimmer的效果由FBShimmeringMaskLayer : CAGradientLayer来实现，其opacity被渐变以显现出底色，从而造成高亮的效果（
_updateMaskColors&_updateMaskLayout）
- 上面的mask的position被animate，从而造成闪动（高亮移动）的效果（
shimmer_slide_animation）
赞~
三。XYPieChart
-
介绍
选用XYPieChart是因其小巧和华美的展开效果。之前用core-plot，感觉其结构的确非常好，但是文档过于粗糙。现在看中的ios-charts是由android移植而来，看起来不错，但还未使用过。
不过我至今没看到一个能在pie chart上比较好的显示折线legend的库。谁有推荐吗？自己虽然有写一个，但是处理的极端情况还不够全，也许有空可以发布出来看看。
（图片来自XYPieChart在github上的主页） 阅读和评论
- 每个pie slice都是一个layer（SliceLayer : CAShapeLayer），其展开动画由startAngle和endAngle两个double属性决定
- 动画效果的参数由
createArcAnimationForKey:创建，startAngle和endAngle分开animate。CABasicAnimation按照用户定义的动画效果来更新startAngle和endAngle的值【注：由于startAngle和endAngle是用户自定义的property，不是UIView内建的关联了动画效果的property，因此CABasicAnimation仅能animate这两个property的数值，此数值所对应的UI animation需要靠下一步来完成】 - CABasicAnimation delegate的
animationDidStart中，创建用于展示UI animation的timer（updateTimerFired）。timer中取得当前startAngle和endAngle的值【注：上述，此2数值被CABasicAnimation所animate了】，然后绘制出相应的pie slice
【第3步可以对比pop库中的相应实现。pop中利用了CADisplaylink的回调，实现了和屏幕刷新率相同动画；而此处是自己创建的NSTimer。感觉pop更优。】
赞~
四。JLRoutes
介绍
通过App link，打开App后直接显示某个特定内容或页面，是notification等圈留用户方法的强需求。JLRoute提供了解析App link，并回调block的机制，很好的实现了这个功能。阅读和评论
- API以class method的形式提供：
addRoute注册回调block，routeURL解析app link
singleton（static
routeControllersMap）保证数据的唯一性。routeControllersMap管理app link scheme，每个scheme对应一个JLRoute类的实例。（若app仅注册了一个app link，则仅维护一个global route）JLRoute类维护包含多个JLRoutes_的列表，JLRoute_类则具体存放用户注册block及其相关参数（如priority等）。在用户解析app link后，查找合适的block予以执行
总结：
routeControllersMap(singleton) -> JLRoute(对应具体scheme) -> JLRoutes_(管理回调block)
五。pop
-
介绍
iOS系统提供的UIView animation其实挺好用的，配合CABasicAnimation对CALayer的动画，大多数情况都尽够用了。选用pop，一来是因为其默认可以操作更多的UI property（比如color），二来也是其默认的弹簧效果实在配置得很赏心悦目。
（图片来自pop在github的页面） 阅读和评论
- 底层的动画支持，使用了
CADisplayLink，提供了和屏幕刷新率同频的回调，以保证动画的顺滑（见POPAnimator）
动画曲线参数，保存在POPAnimation及其子类中，提供各式各样的动画效果
比如，动画某个参数X时，在
CADisplayLink的回调函数中，POPAnimation子类计算该参数X在当前帧的数值：POPAnimator的applyAnimationTime，其中调用了定义在POPAnimationInternal.h中的关键函数：advanceTime，而关于实际UI property的变化所引起的UI变化，则实现在updateAnimatable中。对于此lib所支持的可以动画的UI property，系统定义了其pop_animatable_write_block（见POPAnimatableProperty中的POPStaticAnimatablePropertyState），此预设block完成UI的改变。pop是用c++写的哟
总结：
CADisplayLink提供timer，POPAnimation计算当前帧的数值，POPAnimatableProperty定义了该lib中所支持的UI property的block回调，从而完成整套动画效果。
六。reactiveCocoa (FRP / MVVM)
- 介绍
这东西值得花时间多写一点。
从方法上来看：
- 函数式编程（Functional programming）源远流长，其思路是将计算理解成数学函数，即函数输出仅与函数输入有关。比较常用的函数有：map, reduce, filter等
- 响应式编程（Reactive programming）大约出现在Y2K，其思路是将计算看作对连续数据流的响应。大体可以理解为事件驱动。
- 函数响应式编程（Functional reactive programming / FRP）采两家之长。FRP应该是近期的一种思潮和趋势吧，reactiveCocoa即是以FRP为理念的编程方法在cocoa(iOS)上的实现
从结构上来看：
- 大约Y2K的时候，大牛Martin Fowler构思了一种新的模型：Presentation Model。其定义为：Represent the state and behavior of the presentation independently of the GUI controls used in the interface，即，将图形控件的状态和行为独立出来作为一个新的组件。这种建模方式将图形控件进一步分拆解耦，能有效降低“富图形界面”的开发和测试难度。
- 后来微软在开发WPF（Windows Presentation Foundation）时，参考了Presentation Model思路，提供了图形控件（View）和其模型（ViewModel，即View的状态和行为）间的逻辑支持。此结构被称为MVVM（Model-View-ViewModel）。
- 在iOS的开发中，xcode project默认采用的是MVC结构。但是随着界面元素的丰富和逻辑的复杂，view controller变得越来越臃肿。因此MVVM的思路被借鉴过来，即对view controller进行分拆，将view的状态和行为拆至新的ViewModel中。整个程序的结构由原来的Model-ViewController-View，变成Model-ViewModel-ViewController-View
- reactiveCocoa可以提供View和ViewModel之间的DataBinding，从而方便的实现MVVM结构。
从历史上来看：
微软的The Reactive Extensions (Rx)是对.Net库的响应式编程的扩充，提供了异步的、基于事件的编程实现。
也许是View和ViewModel之间的天然特性(事件表象与内在逻辑?)，大家发现Rx与MVVM实乃天作之合。
ReactiveCocoa是Rx在cocoa框架上的FRP实现。其为MVVM中的View和ViewModel间的逻辑提供了支持。
阅读和评论
源代码还没看
七。SDWebImage
- 介绍
大多数CS类型的app，都少不得要用到服务端的图片，对于图片的下载和加载，最大的需求有三：1. 异步下载；2. 缓存图片；3. 优化显示。SDWebImage可以比较好的完成这几个需求，是比较常用的开源库之一。
同时正因为这个库的出名，已经有很多分析和介绍的文章了，比如：
SDWebImage库结构的简单分析
后面两篇文章不能保证是原始链接，因为网上的转载太多了，并且都不带转载链接。而原作者似乎也并未对文章的原创性做更多的声明。阅读和评论
由于本库较为出名，相关介绍和分析文章已经很多了，我也并不能写不出什么新花样。最最关键的是：源代码既不多，也不长。因此有兴趣的同学还是自己去看源代码吧。
呃，毕竟读了代码，还是稍稍写一点吧：按我在一。介绍中的说法，用户的最大需求有三：1. 异步下载；2. 缓存图片；3. 优化显示
因此对应到代码中：
- 接口类
SDWebImageManager，提供核心API。（其含有下面两个类的实例）
-
SDWebImageDownloader，完成需求1.异步下载 -
SDImageCache，完成2. 缓存图片 - 由UIImageView和UIButton的category，如
UIImageView+WebCache，完成3. 优化显示
DONE
[TOC]
