简介

前几天写了一个React Native组件：一个可定制性比较高的底部弹出菜单（ActionSheet）。该组件符合React Native的特性：同时支持iOS和Android双平台，一份相同的代码会在两个平台上展示几乎完全相同的样式。

先看一下效果(上排为iOS模拟器，下排为Android模拟器)：

上图展示的是该组件的默认样式。由于该组件具有较高的定制性，所以只需要通过设置一些属性就可以得到更多不同的样式。

开源项目地址：GitHub:react-naive-highly-customizable-action-sheet

在进行了2个星期的基础学习（Flexbox, React.js, JSX, JavaScript）之后，想通过一个实战项目来提高React Native的开发水平，于是找到了下面这个项目：

一. 项目介绍

这是我在学习贾鹏辉老师在慕课网上的一个很火的React Native实战的教程后，写出的课程Demo。该课程是慕课网里很火的一个React Native课程，当初在看了课程介绍和课程安排觉得讲解的点还是很全的，所以毫不犹豫地买了下来。

从看视频，敲代码到重构，改bug，大概花了2个多星期的时间，除了调用友盟的SDK以及CodePush集成之外，其他的部分都基本完成了，而且同时可以在iOS和Android设备上运行：

而且比较吸引人的是该项目可以实现多个主题的切换：

切换的技术实现会在下文给出。

用一个动图来过一遍大致的需求：

Demo GitHub地址：GitHubPopular-SJ
可以按照README文件里的方法运行该项目。

已经贾老师允许上传到GitHub

值得一提的是：这确实是一门物有所值的课程，可以让想入门React Native的开发者少走很多弯路。虽然我上传的Demo可以实现视频里大部分功能，但是经过调试，修改后的代码信息量还是很有限的，而且老师在视频中讲解的很多关于实际开发的知识点在代码中并没有体现出来，所以还是建议各位报名参加课程来提高自己的开发水平。

对于iOS开发来说，就算是没有用过YTKNetwork框架，应该也见过，听过了。它是猿题库技术团队开源的一个网络请求框架，内部封装了AFNetworking。它把每个请求实例化，管理它的生命周期，也可以管理多个请求。
​
在正式讲解源码之前，我会先讲一下该框架所用的架构和设计模式。我总觉得对架构和设计有一定的了解的话，会有助于对源码的理解。

1. 架构

先上图：

在这里简单说明一下：

1. YTKNetwork框架将每一个请求实例化，YTKBaseRequest是所有请求类的基类，YTKRequest是它的子类。所以如果我们想要发送一个请求，则需要创建并实例化一个继承于YTKRequest的自定义的请求类（CustomRequest）并发送请求。
2. YTKNetworkAgent是一个单例，负责管理所有的请求类（例如CustomRequest）。当CustomRequest发送请求以后，会把自己放在YTKNetworkAgent持有的一个字典里，让其管理自己。
3. 我们说YTKNetwork封装了AFNetworking，实际上是YTKNetworkAgent封装了AFNetworking，由它负责AFNetworking请求的发送和AFNetworking的回调处理。所以如果我们想更换一个第三方网络请求库，就可以在这里更换一下。而YTKRequest更多的是只是负责缓存的处理。
4. YTKNetworkConfig与YTKPriviate的具体职能现在不做介绍，会在后文给出。

OK，现在我们知道了YTKNetwork中类与类之间的关系以及关键类的大致职能，接下来我会告诉你YTKNetwork为什么会采用这种关系来架构，以及采用这种架构会有什么好处。

利用上周的业余时间把这篇规范整理了出来，我会将这篇规范作为我们iOS团队的代码规范，并且还会根据读者的反馈，项目的实践和研究的深入做不定时更新，还希望各位朋友看了多多指正和批评。

这篇规范一共分为三个部分：

1. 核心原则：介绍了这篇代码规范所遵循的核心原则。
2. 通用规范：不局限于iOS的通用性的代码规范（使用C语言和Swift语言）。
3. iOS规范：仅适用于iOS的代码规范（使用Objective-C语言）。

就在上个月中旬，技术老大让我招两个1-2年的iOS开发，把简历的筛选和第一轮技术面试的任务交给了我。

从筛选第一份简历，准备面试题，到成功招到两个人一共花了两个星期多一点，总体来说还是比较顺利的。两位通过者都比较稳重踏实，而且对技术也比较有追求。这也可能和我筛选简历比较谨慎有关系，这次筛选简历所花费的精力是不比面试花费的少的。

虽然时间跨度不是很长，但是毕竟是第一次，所以有些感触，想总结出来分享给大家。这篇总结分为两个部分：

• 第一部分是我当时准备的面试题
• 第二部分是我的心得

我重点在本文的第二部分说一下这次面试别人的心得体会。而关于第一部分的面试题，文中不提供答案（因为不是本文的重点）。

在iOS开发中，我们可以通过KVO机制来监听某个对象的某个属性的变化。

用过KVO的同学都应该知道，KVO的回调是以代理的形式实现的：在给某个对象添加观察以后，需要在另外一个地方实现回调代理方法。这种设计给人感觉比较分散，因此突然想试试用Block来实现KVO，将添加观察的代码和回调处理的代码写在一起。在学习了ImplementKVO的实现以后，自己也写了一个：SJKVOController

SJKVOController的用法

只需要引入NSObject+SJKVOController.h头文件就可以使用SJKVOController。
先看一下它的头文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#import <Foundation/Foundation.h>
#import "SJKVOHeader.h"

@interface NSObject (SJKVOController)


//============== add observer ===============//
- (void)sj_addObserver:(NSObject *)observer forKeys:(NSArray <NSString *>*)keys withBlock:(SJKVOBlock)block;
- (void)sj_addObserver:(NSObject *)observer forKey:(NSString *)key withBlock:(SJKVOBlock)block;


//============= remove observer =============//
- (void)sj_removeObserver:(NSObject *)observer forKeys:(NSArray <NSString *>*)keys;
- (void)sj_removeObserver:(NSObject *)observer forKey:(NSString *)key;
- (void)sj_removeObserver:(NSObject *)observer;
- (void)sj_removeAllObservers;


//============= list observers ===============//
- (void)sj_listAllObservers;

@end

我们知道在iOS开发中，一共有四种多线程技术：pthread，NSThread，GCD，NSOperation：

• 前两者是面向线程开发的多线程技术，需要开发者自己去维护线程的生命周期，比较繁琐。
• 后两者是面向队列开发的多线程技术，开发者仅仅定义想执行的任务追加到适当的Dispatch Queue（队列）中并设置一些优先级，依赖等操作就可以了，其他的事情可以交给系统来做。

在这一章里，作者主要介绍了GCD技术，它是基于C语言的API，开发者只需要将任务放在block内，并指定好追加的队列，就可以完成多线程开发。

但是多线程开发时容易发生的一些问题：

• 多个线程更新相同的资源：数据竞争。
• 多个线程相互持续等待：死锁。
• 使用太多的线程导致消耗内存。

虽然解决这些问题的代价是会使程序的复杂度上升，但是多线程技术仍然是必须使用的：因为使用多线程编程可以保证应用程序的响应性能。如果耗时操作阻塞了主线程的RunLoop，会导致用户界面无法响应用户的操作，所以必须开启子线程将耗时操作放在子线程中处理。那么我们应该怎么进行多线程开发呢？在讲解之前先看一下本文结构（GCD部分）：

本文的Demo地址：knightsj/iOS_Demo/gcd_demo
虽然文章里应给出了详细的输出结果，但还是希望读者可以将demo下载后仔细对照一下代码并体会。

这一章讲解了Block相关的知识。因为作者将Objective-C的代码转成了C++的代码，所以第一次看的时候非常吃力，我自己也不记得看了多少遍了。

这篇总结不仅仅只有这本书中的内容，还有一点在其他博客里看过的Block的相关知识，并加上了自己的理解，而且文章结构也和原书不太一致，是经过我的整理重新排列出来的。

先看一下本文结构（Blocks部分）：

总结了Effective Objective-C之后，还想读一本进阶的iOS书，毫不犹豫选中了《Objective-C 高级编程》：

这本书有三个章节，我针对每一章节进行总结并加上适当的扩展分享给大家。可以从下面这张图来看一下这三篇的整体结构：

注意，这个结构并不和书中的结构一致，而是以书中的结构为参考，稍作了调整。

本篇是第一篇：引用计数，简单说两句：
Objective-C通过 retainCount 的机制来决定对象是否需要释放。 每次runloop迭代结束后，都会检查对象的 retainCount，如果retainCount等于0，就说明该对象没有地方需要继续使用它，可以被释放掉了。无论是手动管理内存，还是ARC机制，都是通过对retainCount来进行内存管理的。

更新记录：

2017.4.23：新增支持数据源完全依赖网络请求的情况。
2017.4.22：新增支持请求新数据后刷新表格。
2017.4.21： 新增CocoaPods支持：pod ‘SJStaticTableView’, ‘~> 1.2.0’。

写一个小小轮子～

写UITableView的时候，我们经常遇到的是完全依赖于网络请求，需要自定义的动态cell的需求（比如微博帖子列表）。但是同时，大多数app里面几乎也都有设置页，个人页等其他以静态表格为主的页面。

而且这些页面的共性比较多：

1. 大多数情况下在进入页面之前就已经拿到所有数据。
2. cell样式单一，自定义cell出现的几率比较小（几乎都是高度为44的cell）。
3. 多数都分组。

因为自己非常想写一个开源的东西出来（也可以暴露自己的不足），同时又受限于水平，所以就打算写这么一个比较简单，又具有通用性的框架：一个定制性比较高的适合在个人页和设置页使用的UITableView。

在真正写之前，看了几篇类似的文章，挑出三篇自己觉得比较好的：

1. Clean Table View Code
2. 如何写好一个UITableView
3. 利用MVVM设计快速开发个人中心、设置等模块

看完总结之后，利用上周3天的业余时间写好了这个框架，为了它实用性，我仿照了微信客户端的发现页，个人页和设置页写了一个Demo，来看一下效果图：

项目所用资源来自：GitHub:zhengwenming/WeChat
Demo地址：GitHub: knightsj/SJStaticTableView

这篇面试总结很短，也没有面试题的答案，只是写给像我一样的非科班iOS开发者的一些话。

昨天进行了人生第一次视频面试，一共三个小时的技术面，还没见到人事，应该是挂了。

不过整个过程下来感触还是蛮多的，除了感受到面试官的牛X之外，也知道自己平时在学习中的不足。

这一系列的源码解析分享到现在已经是第五篇了。这五篇讲解的都是view层的一些流行的iOS开源框架。而从本篇开始开始，我打算要逐渐加深难度，讲解一些model层和网络层相关的开源框架。

想来想去，还是从JSONModel开始吧～

首先因为该框架还是比较流行的，在GitHub上也有将近6000颗星了，而且我自己对这个框架的使用也比较熟悉。还有一点是这个框架运用了运行时的相关知识，对想要了解运行时的童鞋还是很有帮助的。

该框架的核心代码并不是很多，主要还是错误类型判断和容错处理占了不少内容。读过一遍之后，感觉到作者思维的严谨性是非常值得我们学习的：作者专门建立了一个展示错误(NSError)的类，里面封装了很多错误类型，而且这个框架还允许用户根据自己的需求来自定义错误类型并阻止最终模型的生成，在后文会有详细讲解。

这次分享一个关于性能优化的源码。

我们知道UITabelView在iOS开发中扮演者举足轻重的角色，因为它是iOS开发中使用频率非常高的控件之一：几乎每个app都离不开它，因此，UITabelView的性能将直接影响这个app的性能。

如果UITabelView里的cell设计的比较简单，那么即使不做相应的优化，对性能的影响也不会很大。

但是，当cell里面涉及到图文混排，cell高度不都相等的设计时，如果不进行一些操作的话，会非常影响性能，甚至会出现卡顿，造成非常不好的用户体验。

最近在看一些iOS性能优化的文章，我找到了VVeboTableView这个框架。严格来说这个不属于框架，而是作者用自己的方式优化UITableView的一个实现。

作者模仿了新浪微博的cell样式，在里面展示了各种微博的cell。虽然样式比较复杂，但是性能却很好：我在我的iphone 4s上进行了Core Animation测试，在滑动的时候帧率没有低于56，而且也没有觉得有半点卡顿，那么他是怎么做到的呢？

看了源码之后，我把作者的思路整理了出来：

下面我就从左到右，从上到下，结合代码来展示一下作者是如何实现每一点的。

一. 框架介绍

PNChart是国内开发者开发的iOS图表框架，现在已经7900多颗star了。它涵盖了折线图，柱状图，饼图，散点图等图表。图表的可定制性很高，而且UI设计简洁大方。

该框架分为两层：视图层和数据层。视图层里有两层继承关系，第一层是所有类型图表的父类PNGenericChart,第二层就是所有类型的图表。提供一张图来直观感受一下：

在这张图里，需要注意以下几点：

1. 带箭头的线和不带箭头的线的区别。
2. Data类对应图表的一组数据，因为当前类型的图表支持多组数据（例如：饼状图没有Data类，因为饼状图没有多组数据，而折线图LineChart是支持多组数据的，所以有Data类。
3. Item类负责将传入图表的某个真实值转化为图表中显示的值，具体做法会在下文详细讲解。
4. BarChart类里面的每一根柱子都是PNBar的实例（该类型的图表不在本篇讲解的范围之内）。

MJRefresh是李明杰老师的作品，到现在已经有9800多颗star了，是一个简单实用，功能强大的iOS下拉刷新（也支持上拉加载更多）控件。它的可定制性很高，几乎可以满足大部分下拉刷新的设计需求，值得学习。

该框架的结构设计得很清晰，使用一个基类MJRefreshComponent来做一些基本的设定，然后通过继承的方式，让MJRefreshHeader和MJRefreshFooter分别具备下拉刷新和上拉加载的功能。从继承机构来看可以分为三层，具体可以从下面的图里看出来：