Author Archives: 庞海礁

iOS弹幕解决方案——HJDanmaku 2.0发布

转载请注明出处：http://www.olinone.com/

Hi，好久不见，HJDanmaku 1.0版本发布已经过去两年之久，直播行业的快速崛起催生了直播弹幕的迫切需求，高并发、大流量、实时性的特性和以往视频弹幕的场景都大有不同，为了满足新的直播业务场景，HJDanmaku2.0正式发布！

流畅度

相较于1.0版本， HJDanmaku2.0采用全新的异步渲染引擎，98%的计算工作转移到子线程执行，避免了主线程的卡顿延时。同时，参考离屏渲染技术，将组装弹幕和渲染弹幕分布在两个独立线程异步执行，确保了弹幕渲染的流畅性

NSBlockOperation *operation = [NSBlockOperation blockOperationWithBlock:^{
    NSArray <HJDanmakuAgent *> *danmakuAgents = [self.danmakuSource fetchDanmakuAgentsForTime:(HJDanmakuTime){HJMaxTime(time), time.interval}];
    dispatch_async(_renderQueue, ^{
        if (danmakuAgents.count > 0) {
            [self.danmakuQueuePool insertObjects:danmakuAgents atIndexes:[NSIndexSet indexSetWithIndexesInRange:NSMakeRange(0, danmakuAgents.count)]];
        }
    });
}];
[self.sourceQueue cancelAllOperations];
[self.sourceQueue addOperation:operation];

NSBlockOperation *operation = [NSBlockOperation blockOperationWithBlock:^{

NSArray <HJDanmakuAgent *> *danmakuAgents = [self.danmakuSource fetchDanmakuAgentsForTime:(HJDanmakuTime){HJMaxTime(time), time.interval}];

dispatch_async(_renderQueue, ^{

if (danmakuAgents.count > 0) {

[self.danmakuQueuePool insertObjects:danmakuAgents atIndexes:[NSIndexSet indexSetWithIndexesInRange:NSMakeRange(0, danmakuAgents.count)]];

}

});

}];

[self.sourceQueue cancelAllOperations];

[self.sourceQueue addOperation:operation];

将组装弹幕的过程拆分为独立的子线程任务，统一由NSOperationQueue单执行队列管理，有效的降低CPU的使用率，提升系统运行稳定性。此外，在2.0版本中，使用CADisplayLink替换定时器NSTimer，与屏幕刷新频率保持一致，可以避免NSTimer由于线程阻塞导致的刷新延时

高并发

直播与传统视频最大区别在于其实时性，短时间大量的弹幕发送对底层渲染引擎是个不小的挑战。为了解决这个问题，HJDanmaku2.0引入数据源Source的思想，将弹幕接收与组装的过程分开，可以针对直播、视频场景实现差异化的处理方案。视频场景对时间精确度要求较高，涉及到弹幕的时间排序，同时，播放进度回放也需要数据源保存所有的弹幕数据。直播场景则比较单一，播放完可以立刻释放，避免内存的过度消耗

u_int interval = 100;
NSMutableArray *danmakuAgents = [NSMutableArray arrayWithCapacity:interval];
NSUInteger lastIndex = danmakus.count - 1;
[danmakus enumerateObjectsUsingBlock:^(HJDanmakuModel *danmaku, NSUInteger idx, BOOL *stop) {
    HJDanmakuAgent *agent = [[HJDanmakuAgent alloc] initWithDanmakuModel:danmaku];
    [danmakuAgents addObject:agent];
    if (idx == lastIndex || danmakuAgents.count % interval == 0) {
        OSSpinLockLock(&_spinLock);
        [self.danmakuAgents addObjectsFromArray:danmakuAgents];
        OSSpinLockUnlock(&_spinLock);
        [danmakuAgents removeAllObjects];
     }
}];

u_int interval = 100;

NSMutableArray *danmakuAgents = [NSMutableArray arrayWithCapacity:interval];

NSUInteger lastIndex = danmakus.count - 1;

[danmakus enumerateObjectsUsingBlock:^(HJDanmakuModel *danmaku, NSUInteger idx, BOOL *stop) {

HJDanmakuAgent *agent = [[HJDanmakuAgent alloc] initWithDanmakuModel:danmaku];

[danmakuAgents addObject:agent];

if (idx == lastIndex || danmakuAgents.count % interval == 0) {

OSSpinLockLock(&_spinLock);

[self.danmakuAgents addObjectsFromArray:danmakuAgents];

OSSpinLockUnlock(&_spinLock);

[danmakuAgents removeAllObjects];

}

}];

通过拆分入库数据分布添加可以避免线程锁的长时间占有，提升系统的稳定性和流畅度

精确度

与1.0版本不同，新版本通过toleranceCount维度判断弹幕是否过期，默认允许最大2秒误差。弹幕刷新频率为0.5秒，即每个弹幕有效等待次数为2/0.5 = 4次，超过4次没有渲染将自动丢弃

- (void)removeExpiredDanmakusForTime:(HJDanmakuTime)time {
    [self.danmakuQueuePool enumerateObjectsWithOptions:NSEnumerationReverse usingBlock:^(HJDanmakuAgent *danmakuAgent, NSUInteger idx, BOOL *stop) {
        danmakuAgent.toleranceCount --;
        if (danmakuAgent.toleranceCount <= 0) {
            [self.danmakuQueuePool removeObjectAtIndex:idx];
        }
    }];
}

- (void)removeExpiredDanmakusForTime:(HJDanmakuTime)time {

[self.danmakuQueuePool enumerateObjectsWithOptions:NSEnumerationReverse usingBlock:^(HJDanmakuAgent *danmakuAgent, NSUInteger idx, BOOL *stop) {

danmakuAgent.toleranceCount --;

if (danmakuAgent.toleranceCount <= 0) {

[self.danmakuQueuePool removeObjectAtIndex:idx];

}

}];

}

弹幕冗余度的设计使得弹幕显示更加平均，优化了弹幕显示效果，但是会降低弹幕显示的精确度，特别对于视频场景，相对于1.0版本有所下降，如果你对精确度要求较高，可以降低tolerance冗余值

碰撞检测

与1.0相同，HJDanmaku2.0仍然使用系统动画的方式提供弹幕动画支持，但是碰撞检测方式略有不同

- (BOOL)checkLRIsWillHitWithPreDanmaku:(HJDanmakuAgent *)preDanmakuAgent danmaku:(HJDanmakuAgent *)danmakuAgent {
    CGFloat width = CGRectGetWidth(self.bounds);
    CGFloat preDanmakuSpeed = (width + preDanmakuAgent.size.width) / self.configuration.duration;
    if (preDanmakuSpeed * (self.configuration.duration - preDanmakuAgent.remainingTime) < preDanmakuAgent.size.width) {
        return YES;
    }
    CGFloat curDanmakuSpeed = (width + danmakuAgent.size.width) / self.configuration.duration;
    if (curDanmakuSpeed * preDanmakuAgent.remainingTime > width) {
        return YES;
    }
    return NO;
}

- (BOOL)checkLRIsWillHitWithPreDanmaku:(HJDanmakuAgent *)preDanmakuAgent danmaku:(HJDanmakuAgent *)danmakuAgent {

CGFloat width = CGRectGetWidth(self.bounds);

CGFloat preDanmakuSpeed = (width + preDanmakuAgent.size.width) / self.configuration.duration;

if (preDanmakuSpeed * (self.configuration.duration - preDanmakuAgent.remainingTime) < preDanmakuAgent.size.width) {

return YES;

}

CGFloat curDanmakuSpeed = (width + danmakuAgent.size.width) / self.configuration.duration;

if (curDanmakuSpeed * preDanmakuAgent.remainingTime > width) {

return YES;

}

return NO;

}

在HJDanmaku2.0中，碰撞检测不再以弹幕时间点为参考维度，渲染的弹幕拥有剩余时间属性，通过剩余时间与速度的关系即可判断两者之间是否碰撞。同时，2.0版本只在添加弹幕和恢复动画时为弹幕视图添加动画，其它时间不再校验

手势

运动视图系统默认无法响应手势交互事件，整个点击事件交由全局统一处理。HJDanmakuCell定义属性selectionStyle控制弹幕能否点击，默认HJDanmakuCellSelectionStyleNone，即不能点击

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {
    self.selectDanmakuAgent = nil;
    HJDanmakuAgent *danmakuAgent = [self danmakuAgentAtPoint:point];
    if (danmakuAgent) {
        if (danmakuAgent.danmakuCell.selectionStyle == HJDanmakuCellSelectionStyleDefault) {
            self.selectDanmakuAgent = danmakuAgent;
            return self;
        }
        CGPoint cellPoint = [self convertPoint:point toView:danmakuAgent.danmakuCell];
        return [danmakuAgent.danmakuCell hitTest:cellPoint withEvent:event];
    }
    return [super hitTest:point withEvent:event];
}

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {

self.selectDanmakuAgent = nil;

HJDanmakuAgent *danmakuAgent = [self danmakuAgentAtPoint:point];

if (danmakuAgent) {

if (danmakuAgent.danmakuCell.selectionStyle == HJDanmakuCellSelectionStyleDefault) {

self.selectDanmakuAgent = danmakuAgent;

return self;

}

CGPoint cellPoint = [self convertPoint:point toView:danmakuAgent.danmakuCell];

return [danmakuAgent.danmakuCell hitTest:cellPoint withEvent:event];

}

return [super hitTest:point withEvent:event];

}

视图整体响应链参考以上代码，当收到点击事情时，优先判断弹幕cell是否响应，如果响应则交由弹幕cell处理，否则交由全局统一处理

总结

时隔两年，HJDanmaku2.0在性能、并发以及定制型方面都有较大的提升，以iphone6设备测试为例，CPU整体使用率稳定在5%左右，大并发100条/秒弹幕的持续输入，FPS可以维持在55帧以上

目前暂时支持OC，swift版本正在开发中，如果你有意贡献swift代码，可以与我联系~

当然，如果你喜欢，可以为本项目点点赞

写在文后：

新建了一个iOS开发QQ交流群（首页右上角入群），欢迎广大iOS开发朋友一同交流学习。当然，你也可以Follow本人GitHub，或者关注我的新浪微博，感谢你的来访，下期再见！

是的，最近很忙！

时光飞逝，转眼又到年末，过去一个多月，主要做了几件事：川藏之旅，辞了阿里，来到新东家—— 比心陪练！

川藏行

中秋国庆期间，陪夫人走了一趟川藏线，这场旅行足足半月之久，为了放空自己，特意选择青藏铁路出行，沿途风景很美，美的让人心醉！

秋天的九寨格外美，喜欢湛蓝天空下红绿相交的美丽，更喜欢大山深处有人家的淳朴与善良

相较于九寨的色彩斑斓，大美西藏似乎更多了一分壮美。都说西藏是离天堂最近的地方，站在通往纳木错的路中央，留下了这张印证我足记的照片，远离城市的嘈杂，生活原本可以不同~

天空之城，大美于行！

阿里，再见

是的，终于还是离开了阿里，一个生活了快三年的地方！无需过多的理由，走了就是走了~

两年前拖着全部家当从武汉迁往上海的场景，依旧历历在目，仿佛就在昨天，而明天就是我离开阿里一个月的纪念日。阿里有句古话：“一年香，三年醇，五年陈”，而我终究没能迈过“三年醇”

怎么说了，非常感谢阿里，感谢曾经的天天，感谢前公司所有的同事、朋友以及小伙伴们。路走对了就不怕远，而我只能陪你们到这里，真心祝福你们！

伴随阿里星球音乐的停服，天天动听终究还是落幕。诺干年后，又有多少朋友记得曾经的天天动听？

谨以此纪念曾经的天天动听，纪念我即将逝去的青春！

比心，我来了

第一次听说比心是在国庆节后的一个上午，当时，大树同学找到我，邀请我加入他们团队，抱着体验的心态下载比心陪练，打开APP的一瞬间，我似乎找到了未来

这是一家用心做产品的公司，当然，我个人也比较追崇工匠精神。物欲横流的今天，能够静心做产品的初创公司实属难得，很荣幸能够加入这个大家庭

期待

凌晨1点23分，夜是如此的安静，而我是如此的清醒

上海，一个从来不缺乏梦想的国际化大都市。在这里，年轻的人们为了各自的梦想疲于奔波。太多的青春热血在这里挥洒，也有太多的辛酸泪水在这里述说

正如蔡崇达在《皮囊》中所言：“北京不只是他想要求医的地方，还是他为自己开出的最后的药方”。或许，我们都生了同一种病，我也是一个来看病的人！

2016年12月8日记于上海

Protocol协议分发器

转载请注明出处：http://www.olinone.com/

Hi，本期跟大家聊聊协议分发，何为协议分发？协议分发可以简单理解为将协议代理交给多个对象实现！

Protocol协议代理在开发中应用频繁，开发者经常会遇到一个问题——事件的连续传递。比如，为了隔离封装，开发者可能经常会把tableview的delegate或者datesource抽离出独立的对象，而其它对象（比如VC）需要获取某些delegate事件时，只能通过事件的二次传递。有没有更简单的方法了？协议分发器正好可以派上用场

话不多说，先上干货：HJProtocolDispatcher是一个协议实现分发器，通过该工具能够轻易实现将协议事件分发给多个实现者。比如最常见的tableview的delegate协议，通过HJProtocolDispatcher，能够非常容易的分发给多个对象，具体可参考Demo

self.tableView.delegate = AOProtocolDispatcher(UITableViewDelegate, self, self.delegateSource);

1	self.tableView.delegate = AOProtocolDispatcher(UITableViewDelegate, self, self.delegateSource);

原理解析

原理并不复杂，协议分发器Dispatcher并不实现Protocol协议，其只需将对应的Protocol事件分发给不同的实现者Implemertor。如何实现分发？

熟悉类Class响应链的童鞋都知道，NSObject对象主要通过以下函数响应未实现的Selector函数调用

- (id)forwardingTargetForSelector:(SEL)aSelector OBJC_AVAILABLE(10.5, 2.0, 9.0, 1.0);
- (void)forwardInvocation:(NSInvocation *)anInvocation OBJC_SWIFT_UNAVAILABLE("");
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector

- (id)forwardingTargetForSelector:(SEL)aSelector OBJC_AVAILABLE(10.5, 2.0, 9.0, 1.0);

- (void)forwardInvocation:(NSInvocation *)anInvocation OBJC_SWIFT_UNAVAILABLE("");

- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector

因此，协议分发器Dispatcher可以在该函数中将Protocol中Selector的调用传递给实现者Implemertor，由实现者Implemertor实现具体的Selector函数即可

- (void)forwardInvocation:(NSInvocation *)anInvocation {
    SEL aSelector = anInvocation.selector;
    if (!ProtocolContainSel(self.prococol, aSelector)) {
        [super forwardInvocation:anInvocation];
        return;
    }
    
    for (ImplemertorContext *implemertorContext in self.implemertors) {
        if ([implemertorContext.implemertor respondsToSelector:aSelector]) {
            [anInvocation invokeWithTarget:implemertorContext.implemertor];
        }
    }
}

- (void)forwardInvocation:(NSInvocation *)anInvocation {

SEL aSelector = anInvocation.selector;

if (!ProtocolContainSel(self.prococol, aSelector)) {

[super forwardInvocation:anInvocation];

return;

}

for (ImplemertorContext *implemertorContext in self.implemertors) {

if ([implemertorContext.implemertor respondsToSelector:aSelector]) {

[anInvocation invokeWithTarget:implemertorContext.implemertor];

}

设计关键

如何做到只对Protocol中Selector函数的调用做分发是设计的关键，系统提供有函数

objc_method_description protocol_getMethodDescription(Protocol *p, SEL aSel, BOOL isRequiredMethod, BOOL isInstanceMethod)

1	objc_method_description protocol_getMethodDescription(Protocol *p, SEL aSel, BOOL isRequiredMethod, BOOL isInstanceMethod)

通过以下方法即可判断Selector是否属于某一Protocol

struct objc_method_description MethodDescriptionForSELInProtocol(Protocol *protocol, SEL sel) {
    struct objc_method_description description = protocol_getMethodDescription(protocol, sel, YES, YES);
    if (description.types) {
        return description;
    }
    description = protocol_getMethodDescription(protocol, sel, NO, YES);
    if (description.types) {
        return description;
    }
    return (struct objc_method_description){NULL, NULL};
}

BOOL ProtocolContainSel(Protocol *protocol, SEL sel) {
    return MethodDescriptionForSELInProtocol(protocol, sel).types ? YES: NO;
}

struct objc_method_description MethodDescriptionForSELInProtocol(Protocol *protocol, SEL sel) {

struct objc_method_description description = protocol_getMethodDescription(protocol, sel, YES, YES);

if (description.types) {

return description;

}

description = protocol_getMethodDescription(protocol, sel, NO, YES);

if (description.types) {

return description;

}

return (struct objc_method_description){NULL, NULL};

}

BOOL ProtocolContainSel(Protocol *protocol, SEL sel) {

return MethodDescriptionForSELInProtocol(protocol, sel).types ? YES: NO;

}

注意事项

协议分发器使用需要了解如何处理带有返回值的函数，比如

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

1	- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

我们知道，iOS中，函数执行返回的结果存在于寄存器R0中，后执行的会覆盖先执行的结果。因此，当遇到有返回结果的函数时，返回结果以后执行的函数返回结果为最终值，以Demo为例

self.tableView.delegate = AOProtocolDispatcher(UITableViewDelegate, self, self.delegateSource);

1	self.tableView.delegate = AOProtocolDispatcher(UITableViewDelegate, self, self.delegateSource);

TableView的DataSource以后面的self.delegateSource中实现函数返回的结果为准

备注

开发完本项目后发现网上已有朋友实现了协议分发器AOMultiproxier，因此，技术版权属于原作者，本文只做宣传，特此说明！

写在文后：

看时间大家可能也发现，项目代码提交已有一段时间，为啥这么久才更新此文章？其实，最近完成了一次长途旅行——川藏行，算作给自己的一次心灵洗涤吧！

如果你喜欢本文章，Demo欢迎你的点赞

ReactNative源码笔记——你知道几条？

转载请注明出处：http://www.olinone.com/

ReactNative是Facebook开源的一种实现移动跨平台开发的解决方案，目前在业界得到广泛应用，这里有非常详细的中文使用指南。本文主要分享RN源码中一些值得大家学习或者借鉴的代码或者编写技巧等，供大家学习参考

整个RN库包含10多个工程，有兴趣的童鞋可以下载源码查看具体细节，在此不再展开

宏定义巧用

整个ReactNative源码工程中用到了大量的宏定义，包括RCT_EXTERN、RCT_NOT_IMPLEMENTED、RCT_EXPORT_METHOD以及RCT_EXPORT_MODULE等申明宏或者功能宏。通过宏定义的方式，可以非常方便嵌入功能代码或者逻辑实现，重用代码的同时又保持了代码的整洁性

比如，ProtocolKit工程中，作者通过宏定义@defs将Protocol接口巧妙的实现在.h文件中，代码简介明了，又不失功能完整性。当然，RN工程中，RCT_NOT_IMPLEMENTED宏也有相似作用，实际项目中各位也可以尝试通过宏定义实现一些常用功能模块

关于iOS宏定义的文章有很多，在此推荐两篇非常不错的文章：RAC中必须要知道的宏、ios宏的使用和技巧

环境变量

iOS开发中，各位对#ifdef DEBUG应该非常熟悉，通过判断该条件，可以区别当前运行环境是Debug环境还是Release环境。比如Release环境下通过重定义NSLog以屏蔽所有日志输出

#ifdef DEBUG  
#define NSLog(...) NSLog(__VA_ARGS__)  
#else  
#define NSLog(...) {}  
#endif

#ifdef DEBUG

#define NSLog(...) NSLog(__VA_ARGS__)

#else

#define NSLog(...) {}

#endif

进一步，是否可以考虑只在联机调试环境下输出日志？此时就涉及联机调试环境的判断，环境变量正好可以解决该问题

Xcode可以在不同环境下自定义环境变量Environment Variables，通过在运行环境Run中自定义变量CI_USE_PACKAGER，此时便可在项目代码中通过getenv()函数判断当前运行环境

if (getenv("CI_USE_PACKAGER")) {
  // to do...
}

if (getenv("CI_USE_PACKAGER")) {

// to do...

}

被忽略的硬键盘

相较于软键盘文字符号的输入，对于APP来说，硬键盘的应用开发似乎很容易被忽视，毕竟，通常情况下，硬键盘输入只会出现在模拟器环境下

iOS7以后，系统定义有硬键盘响应交互类UIKeyCommand，通过UIKeyCommand，APP能够监听硬键盘的特定输入响应，比如Command+D等，当然，前提是APP需要首先监听该输入命令

UIKeyCommand的使用非常简单，当需要在特定场景触发某一事件，但又不想影响界面显示的时候，不妨试试UIKeyCommand，具体使用可以看看这篇文章

_cmd

iOS官方文档中，_cmd表示当前方法的selector，你可以通过下面代码打印输出当前函数名

NSLog(@"Current method: %@", NSStringFromSelector(_cmd));

1	NSLog(@"Current method: %@", NSStringFromSelector(_cmd));

当然，实际项目中，你也可以这样使用

NSNumber *rootTag = objc_getAssociatedObject(self, _cmd) ?: @1;
objc_setAssociatedObject(self, _cmd, @(rootTag.integerValue + 10), OBJC_ASSOCIATION_RETAIN_NONATOMIC);

1 2	NSNumber *rootTag = objc_getAssociatedObject(self, _cmd) ?: @1; objc_setAssociatedObject(self, _cmd, @(rootTag.integerValue + 10), OBJC_ASSOCIATION_RETAIN_NONATOMIC);

瞧，是不是有点意思！

kCFNull

相对于nil NSNull而言，kCFNull笔者接触较少，kCFNull可以理解为NSNull单例对象

id null1 = (id)kCFNull;
id null2 = [NSNull null];

1 2	id null1 = (id)kCFNull; id null2 = [NSNull null];

打印地址

null1=(NSNull *)0x10426eaf0
null2=(NSNull *)0x10426eaf0

1 2	null1=(NSNull )0x10426eaf0 null2=(NSNull )0x10426eaf0

从上面测试结果可以看出它们其实指向同一地址，可以简单理解为 kCFNull === [NSNull null]

文本阴影NSShadow

APP开发中，程序猿可能经常需要在图片或视频上显示文字，由于背景颜色跟文字颜色相近，导致文字看不清，比如时下火热的直播弹幕显示，为了确保文字显示清晰，开发者一般会配上阴影或者文字描边

给文本添加阴影描边，系统提供有NSShadow类，可以这样使用

NSShadow *shadow = [NSShadow new];
shadow.shadowOffset = CGSizeZero;
shadow.shadowBlurRadius = 5.0f;
shadow.shadowColor = [UIColor colorWithWhite:0.0f alpha:0.3f];
NSAttributedString *attString = [[NSAttributedString alloc] initWithString:@"www.olinone.com" attributes:@{NSShadowAttributeName: shadow, NSForegroundColorAttributeName: [UIColor whiteColor]}];
lbl.attributedText = attString;

NSShadow *shadow = [NSShadow new];

shadow.shadowOffset = CGSizeZero;

shadow.shadowBlurRadius = 5.0f;

shadow.shadowColor = [UIColor colorWithWhite:0.0f alpha:0.3f];

NSAttributedString *attString = [[NSAttributedString alloc] initWithString:@"www.olinone.com" attributes:@{NSShadowAttributeName: shadow, NSForegroundColorAttributeName: [UIColor whiteColor]}];

lbl.attributedText = attString;

实际效果是这样的，shadowBlurRadius值越小，文本描边越清晰

主线程判断

判断当前执行线程是否为主线程的方法有很多，比如

[NSThread isMainThread]
pthread_main_np

1 2	[NSThread isMainThread] pthread_main_np

在RN中，它是这样的

BOOL RCTIsMainQueue() {
  static void *mainQueueKey = &mainQueueKey;
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    dispatch_queue_set_specific(dispatch_get_main_queue(), mainQueueKey, mainQueueKey, NULL);
  });
  return dispatch_get_specific(mainQueueKey) == mainQueueKey;
}

BOOL RCTIsMainQueue() {

static void *mainQueueKey = &mainQueueKey;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

dispatch_queue_set_specific(dispatch_get_main_queue(), mainQueueKey, mainQueueKey, NULL);

});

return dispatch_get_specific(mainQueueKey) == mainQueueKey;

}

当然，由于无法查看NSThread内部实现机制，暂时无法了解孰优孰劣，不过，[NSThread isMainThread]貌似足矣！

volatile不简单

在百科中，是这样描述它的：就像大家更熟悉的const一样，volatile是一个类型修饰符，它是被设计用来修饰被不同线程访问和修改的变量。作为指令关键字，确保本条指令不会因编译器的优化而省略，且要求每次直接读值

简单说，被volatile修饰的变量是多线程安全的，其次，不会因为编译器优化导致读值出错。关于编译器编译优化可以看看这篇文章

iOS开发中确保多线程安全的方法有很多，原子操作、线程锁、单线程执行等等，本人也写过相关文章iOS开发多线程同步

在RN中，通过volatile修饰符，巧妙实现了多线程取消操作

__block volatile uint32_t cancelled = 0;
if (!cancelled) {
   // to do...
}
OSAtomicOr32Barrier(1, &cancelled);

__block volatile uint32_t cancelled = 0;

if (!cancelled) {

// to do...

}

OSAtomicOr32Barrier(1, &cancelled);

通过原子性操作访问被volatile修饰的cancelled对象即可保障函数只执行一次。想想大家熟悉的单例dispatch_once_t，现在让你设计单例对象，你又会如何设计了？

+ (instancetype)sharedInstance {
  static RCTWebSocketManager *sharedInstance = nil;
  static dispatch_once_t onceToken;
  dispatch_once(&onceToken, ^{
    sharedInstance = [self new];
  });
  return sharedInstance;
}

+ (instancetype)sharedInstance {

static RCTWebSocketManager *sharedInstance = nil;

static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

sharedInstance = [self new];

});

return sharedInstance;

}

结构体Struct

说起Struct，不知各位对它印象如何？大学C课本中学过？NSObject类class原型貌似有讲？

struct iOSDev {
    NSString *nickName;
};

struct iOSDev {

NSString *nickName;

};

OC中一个简单的结构体，在Swift中，Struct也可以这样写

struct iOSDev {
    var nickName : String
    func getBusinessCard() -> String {
        return "\(nickName)，幽默的iOS开发者！"
    }
};

let iOSOlinone = iOSDev(nickName: "olinone")
print(iOSOlinone.getBusinessCard())

struct iOSDev {

var nickName : String

func getBusinessCard() -> String {

return "\(nickName)，幽默的iOS开发者！"

}

};

let iOSOlinone = iOSDev(nickName: "olinone")

print(iOSOlinone.getBusinessCard())

getBusinessCard为结构体函数，是不是感觉很方便！其实OC中也可以这样写

struct iOSDev {
    NSString *nickName;
    NSString *getBusinessCard() {
        return [NSString stringWithFormat:@"%@，幽默的iOS开发者！", nickName];
    }
};

iOSDev iosDev = iOSDev{@"olinone"};
NSLog(@"%@", iosDev.getBusinessCard());

struct iOSDev {

NSString *nickName;

NSString *getBusinessCard() {

return [NSString stringWithFormat:@"%@，幽默的iOS开发者！", nickName];

}

};

iOSDev iosDev = iOSDev{@"olinone"};

NSLog(@"%@", iosDev.getBusinessCard());

当然，为Struct添加函数并不是C语言特性，而是C++特性，因此，为了编译通过，你需要将.m文件修改成.mm文件

Struct有其使用的特殊场景，相较于Class，合理的使用Struct可以使代码更加整洁。同时，为了适应Swift中Struct强大特性，可以试着在OC项目中尝试Struct

最后，给大家来个段子吧：

话说一美女要在两个男人之间做选择，一个年纪大，长的丑，是个千万富翁，另一个年轻，帅气，iOS开发程序猿。她对他们说，我会给你们一人一张纸条，写着我愿意的那张就是我的选择。富翁打开纸条，看见上面写着我愿意，于是搂着她，坐上豪车高兴的走了。年轻的小伙很伤心，打开纸条看见上面写着：“等我一个月~” ^o^

写在文后：

有些童鞋可能经常会问一个问题，感觉自己技术遇到瓶颈，如何才能进一步提升自己技术能力？其实这个问题，本人也是摸石头过河，不过有一点可以确定，那就是保持一颗不断进取的心吧

新建了一个iOS开发QQ交流群（首页右上角入群），欢迎广大iOS开发朋友一同交流学习。当然，你也可以Follow本人GitHub，或者关注我的新浪微博，感谢你的来访，下期再见！

MVVM奇葩说

转载请注明出处：http://www.olinone.com/

一直想聊聊这个话题，也有朋友跟我留言，让我讲讲MVVM，只可惜一直没整明白，不敢轻易下笔。针对MVVM，网上有很多不错的文章，比如MVVM介绍、被误解的 MVC 和被神化的 MVVM以及Look at MVVM from a different perspective等等

文章前我想先提几个问题

MVVM到底是什么？它和MVC有什么区别？
MVVM中VM到底是个什么角色？它和Controller或者Manager有什么区别？
ViewController在MVVM中扮演怎样角色？Api数据请求放在哪里？数据流向如何？

MVVM简介

关于MVVM，相信大家或多或少都有了解。引用MVVM介绍文中一图

受MVC或MVP架构的影响，对MVVM最初印象以为这是一个以ViewModel为核心，处理View和Model的开发架构。于是乎在原有MVC的基础上，创建了一个所谓的ViewModel对象，然后把ViewController中的代码移到ViewModel中，在ViewModel里面处理View以及Model的所有逻辑。毕竟大家都在说MVVM可以为ViewController瘦身，这ViewController就剩创建ViewModel的代码，嗯，够瘦身，这就是MVVM！

慢慢的，发现有什么地方不对，哪里不对？第一想法就是ViewController的定位，View？不是，Controller？也不是！毕竟它就创建ViewModel，好像与View、Model也没啥关系。抛开ViewController不谈，突然发现这样的ViewModel、Model以及View不就是MVC，一个以ViewModel为中心的MVC！

错在哪里

核心问题就在于对ViewModel角色的定位不清！基于MVVM设计思路，ViewModel存在目的在于抽离ViewController中展示业务逻辑，而不是替代ViewController，其它视图操作业务等还是应该放在ViewController中实现

既然不负责视图操作逻辑，ViewModel中就不应该存在任何View对象，更不应该存在Push/Present等视图跳转逻辑。因此，ViewModel中绝不应该存在任何视图操作相关的代码

@interface ViewModel : NSObject

// viewmodel中切不可存在view对象，更不该出现push或者present代码
- (instancetype)initWithTableView:(UITableView *)tableView;

@end

@interface ViewModel : NSObject

// viewmodel中切不可存在view对象，更不该出现push或者present代码

- (instancetype)initWithTableView:(UITableView *)tableView;

@end

ViewModel做啥

很简单，处理视图展示逻辑，ViewModel负责将数据业务层提供的数据转化为界面展示所需的VO。其与View一一对应，没有View就没有ViewModel

比如，数据业务层传递一个含有性别属性sex的DO对象，0表示男， 1表示女。ViewModel的职责就是将其转化为展示层可显示的VO对象

self.personVO.sex = personDO.sex == 0 ? @"男": @"女";

1	self.personVO.sex = personDO.sex == 0 ? @"男": @"女";

ViewModel和View一起组成DDD(Model-Driven Design)领域驱动架构体系中的Presentation展示层。在iOS中，数据流向可以表示为ViewModel->ViewController->View，ViewController负责连接VO及其对应的View对象

领域驱动设计

领域驱动设计(DDD)对于安卓童鞋可能非常熟悉，有兴趣的童鞋可以参考这篇文章，本文不做过多讲解，借用其描述介绍几个名词

VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来
DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体
PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性
Domain：领域驱动层，是用户与数据库交互的核心中转站，控制用户数据收集，控制请求转向等

MVVM架构中，ViewModel连接视图View和数据业务Model层，而Domain和Data数据持久层共同组成整个Model层。完整结构如图所示

Model并不表示Model

MVVM架构中的M，并不表示Model对象，而是表示整个数据业务层，对应DDD架构中的Domain层以及数据Data层。业务开发中，一般考虑Api或者DB对象，极少考虑Domain层设计，也不会区分DO或者PO对象。笼统定义Model ，将其传递给展示层ViewModel，久而久之，Model对象承载的信息越来越多，更有甚者，在Model中处理业务逻辑，导致项目维护成本增加，代码中出现if..else的概率也会越来越大

@interface PersonModel : NSObject

@property (nonatomic, assign) NSInteger sex;
@property (nonatomic, readonly) NSString *sexDescription;

@end

@implementation PersonModel

// model中不应该存在业务逻辑代码
- (NSString *)sexDescription {
    return self.sex == 0 ? @"男": @"女";
}

@end

@interface PersonModel : NSObject

@property (nonatomic, assign) NSInteger sex;

@property (nonatomic, readonly) NSString *sexDescription;

@end

@implementation PersonModel

// model中不应该存在业务逻辑代码

- (NSString *)sexDescription {

return self.sex == 0 ? @"男": @"女";

}

@end

当然，Domain层并不是必须的，实际开发中，需要根据具体复杂度和需求来决定。比如只是纯粹的请求展示界面，设计过多的层次结构反而会增加项目的维护成本。同时，Domain层不应该存在任何状态变量！

Data数据层

ViewModel负责展示层逻辑，而Data层则对应数据层逻辑，一般以Manager或者Service身份存在，数据来源主要包括Api、DB或者Cache等。Data数据层操作对象主要为PO持久化对象，对象一旦创建，原则上不可修改

Data数据层具有独立可测试性，其不依赖视图层而存在。切记不可在Data层操作任何视图对象！

@implementation PersonDBAccess

// Data层不应该存在任何视图相关代码
- (NSArray *)fetchPersonModels {
    [SVProgressHUD showWithStatus:@"加载中。。。"];
}

@end

@implementation PersonDBAccess

// Data层不应该存在任何视图相关代码

- (NSArray *)fetchPersonModels {

[SVProgressHUD showWithStatus:@"加载中。。。"];

}

@end

MVVM奇葩说

文章到此，想必各位对MVVM架构已经有了大致了解。对比安卓童鞋对MVP架构的钟爱，iOS童鞋也许更加青睐MVVM，拌上ReactiveCocoa或者RxSwift，这道菜可以做的更加绚烂多彩！当然，正如唐巧在文中所言：ReactiveCocoa 和 MVVM 不应该被神化，我们需要保持的是一个拥抱变化的心，以及理性分析的态度。在新技术的面前，不盲从，也不守旧，一切的决策都应该建立在认真分析的基础上，这样才能应对技术的变化！

写在文后：

为期两天的SwiftCon已经落幕，虽然离我只有两站地铁，只可惜依然没能前往聆听各位大师的技术分享，特别还有我同事兼朋友刘冠杉的个人首秀。虽然，现在网上也出现了各种不好的声音，但是我仍然相信，大多数分享者还是为此付出了不少心血，值得我们为之鼓掌！

个人技术的成长不在一朝一夕，而是长年累月的付出积累沉淀的结果！Swift3.0不久即将发布，而我个人也会逐渐转移☞对Swift语言的学习。与此同时，随着公司ReactNative项目的上马，我也会加强对RN技术的专研和学习中

感谢你的来访，你可以Follow我的个人GitHub，也可以关注我的新浪微博，下期再见！

iOS图片圆角优化

转载请注明出处:http://www.olinone.com/

Hi，又到了更新博客的时间，很高兴再次与大家见面。最近，关于图片圆角的话题讨论非常激烈，出现了许多好的文章。恰逢工作需要，用到了大量圆角图片。然而，系统圆角会导致离屏渲染的问题，出于性能考虑，于是有了图片圆角渲染工具HJCornerRadius，其最大优势在于使用简单，一行搞定图片圆角

imageview.aliCornerRadius = 5.0f;

1	imageview.aliCornerRadius = 5.0f;

核心思想就是使用圆角图片替换系统圆角。实际使用时，确保layer对象的masksToBounds属性为NO

imageview.layer.masksToBounds = NO

1	imageview.layer.masksToBounds = NO

支持pod方式安装，如果你在实际使用中遇到什么问题，欢迎在文章后面跟我留言

pod 'HJCornerRadius', :git => "https://github.com/panghaijiao/HJCornerRadius.git"

1	pod 'HJCornerRadius', :git => "https://github.com/panghaijiao/HJCornerRadius.git"

当然，本文的目的不是介绍如何使用该工具，而是想跟大家分享开发时用到的几点设计思想

自观察的巧妙应用

既然要生成圆角图片，首先要解决生成时机问题。可能会有朋友想到swizzle类UIImageView的setImage方法，但我个人并不推荐，毕竟Swizzle类方法影响范围太广，对于大型开发团队，出问题后很难排查定位问题所在。定义UIImageView子类？实用性不强！

还记得我在文章《“自释放”在iOS开发中的应用》中提到的实现自释放的三种方式吗？其中一种方式就是动态属性观察者——通过创建一个动态属性KVO被观察对象的某一属性，从而达到自监控的目的。

通过创建动态属性观察者HJImageObserver，监听UIImageView的image属性，当image发生变化时，能够立即触发圆角图片的生成，从而达到自动实现圆角图片替换的目的，具体实现可以参考源码 HJCornerRadius

RunLoop的适当切换

细心的朋友可能注意到，本工具并不是直接渲染原始Image对象，而是先截取UIImageView视图Layer生成的Image，然后再做渲染。原因很简单，因为UIImageView呈现方式涉及多种ContentMode，通过渲染UIImageView视图Layer生成的图片可以巧妙的解决UIImageView显示模式的问题

此外，由于系统原因，对于像UITableViewCell的UIImageView，第一次创建赋图时，可能无法获取UIImageView视图Layer的图片，此时，可以通过切换异步RunLoop达到延时渲染的目的

众所周知，截图渲染的逻辑是可以运行在工作线程，但是本工具并没有把它们放在工作线程执行，因为放在工作线程会有延迟，从而导致图片闪烁的现象

具体截图渲染代码如下

UIGraphicsBeginImageContextWithOptions(self.originImageView.bounds.size, NO, [UIScreen mainScreen].scale);
    CGContextRef currnetContext = UIGraphicsGetCurrentContext();
    CGContextAddPath(currnetContext, [UIBezierPath bezierPathWithRoundedRect:self.originImageView.bounds cornerRadius:self.cornerRadius].CGPath);
    CGContextClip(currnetContext);
    [self.originImageView.layer renderInContext:currnetContext];
    UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
    UIGraphicsEndImageContext();
    
    if ([image isKindOfClass:[UIImage class]]) {
        image.aliCornerRadius = YES;
        self.originImageView.image = image;
    } else {
        dispatch_async(dispatch_get_main_queue(), ^{
            [self updateImageView];
        });
    }

UIGraphicsBeginImageContextWithOptions(self.originImageView.bounds.size, NO, [UIScreen mainScreen].scale);

CGContextRef currnetContext = UIGraphicsGetCurrentContext();

CGContextAddPath(currnetContext, [UIBezierPath bezierPathWithRoundedRect:self.originImageView.bounds cornerRadius:self.cornerRadius].CGPath);

CGContextClip(currnetContext);

[self.originImageView.layer renderInContext:currnetContext];

UIImage *image = UIGraphicsGetImageFromCurrentImageContext();

UIGraphicsEndImageContext();

if ([image isKindOfClass:[UIImage class]]) {

image.aliCornerRadius = YES;

self.originImageView.image = image;

} else {

dispatch_async(dispatch_get_main_queue(), ^{

[self updateImageView];

});

}

经过实际测试验证，效果还是比较理想的，即使需要显示大量圆角图片，显示帧数也可以稳定在50帧以上。CPU消耗影响较小，以iPhone6测试显示，CPU实际消耗上涨不会超过5%，属于合理范围之内

自从发表博客《生命不息，折腾不止——致敬逝去的2015》后，收到了许多朋友的关注和问候，在此谢谢大家的祝福。新的一年里，希望各位一如既往支持小生，多多为我点赞，本人也会更加努力，争取为大家奉献更多更好的东西。你可以follow本人的Github，也可以关注我的个人微博，再次感谢你的来访

生命不息，折腾不止——致敬逝去的2015

请以此标题致敬逝去的2015，展望全新的2016！

今天元宵节，2015年，算是完全过去了！这一年里，有太多太多的事情注定永远无法忘怀~

过去一年里，随着阿里音乐集团的成立，工作上经历了天天动听8.x和新项目两个大版本的开发和迭代，开发模式也从过去的小而精的团队转变为跨地域跨组织的多团队开发模式。说实话，学到了很多，也沉淀了不少

博客持续更新，本着宁缺毋滥的原则，大致保持着一月更新一篇的节奏。目前博客日访问人数已超过500，同时也收到了很多朋友的反馈和意见，感谢各位朋友的来访，新的一年里，希望能够得到大家更多的支持和帮助

Github开源项目保持着持续的更新和维护，能够得到大家的认可，无比欣慰。个人排名持续上升，oc语言上海区个人排名上升至第14位，大家的认可是我前进的最大动力

同时，很荣幸，受刚刚在线博主的邀请，在iOS开发实战交流VIP群里做了个人的第一次技术分享，各位朋友也提了很多技术或事业上的问题，大家的热情令我非常感动，继续加油

读了不下于10本课外书，完成了年初设定的读书计划。有幸接触hotpatch，能够写得了几句简单的lua补丁，聊胜于无

同时，我结婚啦！一路走来，7年了，从武汉到广州，广州到武汉，又从武汉到上海，非常感谢老婆的支持和理解。没有车，没有房，有的只是对未来的憧憬和向往。还记得当年怀揣着几百元独自去广州实习，跟老婆挤在350一个月租来的民房，如今也只能感叹时间的飞逝，生活的不易

晚上下班，下着雨，回家路上捡到一个钱包，失主很小，只有20岁。电话告诉他捡到钱包时，他很开心，告诉我说他已经找了一个多小时，刚来上海10多天，钱包丢了，身份证、银行卡全没了，都不知道该怎么办。看着这么小就穿着保安制服的他，许久不能平静。他递给我200块表示感谢，我拒绝了，他说等发工资了请我吃饭，我说等你生活稳定了再请我吧，他没再说话…

上海是一座繁华的都市，在这里，有太多的幸福人家，也有太多太多生活在底层的劳苦人民。生活的压力让许多饱含梦想的年轻人走向了现实，而我也不例外

当然，生活不止眼前的苟且，还有诗和远方的田野

2016，新的一年来了

去年看过的哪些书里，印象最深的还属老罗的《生命不息，折腾不止》，当然，我不崇拜老罗的为人，相反，我更欣赏封面倡导的工匠情怀，就像《海贼王》里弗兰奇师父汤姆一样，男子汉要响当当的面对自己造出的船！！

像去年一样，我给自己定了新的计划

认真学好swift
更新不低于5篇高质量技术博客
阅读至少10本书籍
来一次远行
也许会再创业一次，也许吧

阿里有云：“一年香，三年醇，五年陈。”今年是我来阿里的第三个年头，从在校实习到如今也5年有余，路还很长，加油吧~

看着熟睡的老婆，只想说声谢谢你，谢谢你的支持和陪伴，一路走来，没有车没有房，有的只是对未来的憧憬和向往

2016.2.23 记于上海

接口编程那些事

转载请注明出处:http://www.olinone.com/

接口是一系列可调用方法的集合。何为接口编程？接口编程是指当写一个函数或一个方法时，我们应该更加关注具体的接口，而不是实现类。具体理解可以参考这篇文章

在OC中，接口又可以理解为Protocol，面向接口编程又可以理解为面向Protocol编程，或者面向协议编程。在Swift中，苹果大幅强化了 Protocol 在这门语言中的地位，整个 Swift 标准库也是基于 Protocol 来设计的，有兴趣的童鞋可以看看这篇文章。面向接口编程正逐步成为程序开发的主流思想

在实际开发中，大多数朋友都比较熟悉对象编程，比如，使用ASIHttpRequest执行网络请求

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];
[request setDidFinishSelector:@selector(requestDone:)];
[request setDidFailSelector:@selector(requestWrong:)];
[request startAsynchronous];

ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url];

[request setDidFinishSelector:@selector(requestDone:)];

[request setDidFailSelector:@selector(requestWrong:)];

[request startAsynchronous];

request是请求对象，当发起请求时，调用者需要知道给对象赋哪些属性或者调用对象哪些方法。然而，使用AFNetworking请求方式却不尽相同

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
[manager GET:@"www.olinone.com" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
    NSLog(@"好网站，赞一个！");
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
    //to do
}];

AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];

[manager GET:@"www.olinone.com" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {

NSLog(@"好网站，赞一个！");

} failure:^(AFHTTPRequestOperation *operation, NSError *error) {

//to do

}];

同是请求对象，使用AFNetworking发起请求时，调用者可以不需要关心它有哪些属性，只有接口无法满足需求时才需要了解相关属性的定义。两种设计思路完全不同，当然，此处并不是想表明孰优孰劣，只是想通过两种截然不同的请求方式引出本文的思想——面向接口编程（或者面向协议编程）

接口比属性直观

在对象编程中，定义一个对象时，往往需要为其定义各种属性。比如，ReactiveCocoa中RACSubscriber对象定义如下

@interface RACSubscriber ()

@property (nonatomic, copy) void (^next)(id value);
@property (nonatomic, copy) void (^error)(NSError *error);
@property (nonatomic, copy) void (^completed)(void);

@end

@interface RACSubscriber ()

@property (nonatomic, copy) void (^next)(id value);

@property (nonatomic, copy) void (^error)(NSError *error);

@property (nonatomic, copy) void (^completed)(void);

@end

参考AFNetworking的思想，以接口的形式提供访问入口

@interface RACSubscriber 

+ (instancetype)subscriberWithNext:(void (^)(id x))next 
                             error:(void (^)(NSError *error))error 
                         completed:(void (^)(void))completed;

@end

@interface RACSubscriber

+ (instancetype)subscriberWithNext:(void (^)(id x))next

error:(void (^)(NSError *error))error

completed:(void (^)(void))completed;

@end

通过接口的定义，调用者可以忽略对象的属性，聚焦于其提供的接口和功能上。程序猿在首次接触陌生的某个对象时，接口往往比属性更加直观明了，抽象接口往往比定义属性更能描述想做的事情

接口依赖

设计一个APIService对象

@interface ApiService : NSObject

@property (nonatomic, strong) NSURL        *url;
@property (nonatomic, strong) NSDictionary *param;

- (void)execNetRequest;

@end

@interface ApiService : NSObject

@property (nonatomic, strong) NSURL *url;

@property (nonatomic, strong) NSDictionary *param;

- (void)execNetRequest;

@end

正常发起Service请求时，调用者需要直接依赖该对象，起不到解耦的目的。当业务变动需要重构该对象时，所有引用该对象的地方都需要改动。如何做到既能满足业务又能兼容变化？抽象接口也许是一个不错的选择，以接口依赖的方式取代对象依赖，改造代码如下

@protocol ApiServiceProtocol <NSObject>

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param;

@end

@interface NSObject (ApiServiceProtocol) <ApiServiceProtocol>

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    ApiService *apiSrevice = [ApiService new];
    apiSrevice.url = url;
    apiSrevice.param = param;
    [apiSrevice execNetRequest];
}

@end

@protocol ApiServiceProtocol <NSObject>

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param;

@end

@interface NSObject (ApiServiceProtocol) <ApiServiceProtocol>

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

ApiService *apiSrevice = [ApiService new];

apiSrevice.url = url;

apiSrevice.param = param;

[apiSrevice execNetRequest];

}

@end

通过接口的定义，调用者可以不再关心ApiService对象，也无需了解其有哪些属性。即使需要重构替换新的对象，调用逻辑也不受任何影响。调用接口往往比访问对象属性更加稳定可靠

抽象对象

定义ApiServiceProtocol可以隐藏ApiService对象，但是受限于ApiService对象的存在，业务需求发生变化时，仍然需要修改ApiService逻辑代码。如何实现在不修改已有ApiService业务代码的条件下满足新的业务需求？

参考Swift抽象协议的设计理念，可以使用Protocol抽象对象，毕竟调用者也不关心具体实现类。Protocol可以定义方法，可是属性的问题怎么解决？此时，装饰器模式也许正好可以解决该问题，让我们试着继续改造ApiService

@protocol ApiService <ApiServiceProtocol>

// private functions

@end

@interface ApiServicePassthrough : NSObject

@property (nonatomic, strong) NSURL        *url;
@property (nonatomic, strong) NSDictionary *param;

- (instancetype)initWithApiService:(id<ApiService>)apiService;
- (void)execNetRequest;

@end

@protocol ApiService <ApiServiceProtocol>

// private functions

@end

@interface ApiServicePassthrough : NSObject

@property (nonatomic, strong) NSURL *url;

@property (nonatomic, strong) NSDictionary *param;

- (instancetype)initWithApiService:(id<ApiService>)apiService;

- (void)execNetRequest;

@end

@interface ApiServicePassthrough ()

@property (nonatomic, strong) id<ApiService> apiService;

@end

@implementation ApiServicePassthrough

- (instancetype)initWithApiService:(id<ApiService>)apiService {
    if (self = [super init]) {
        self.apiService = apiService;
    }
    return self;
}

- (void)execNetRequest {
    [self.apiService requestNetWithUrl:self.url Param:self.param];
}

@end

@interface ApiServicePassthrough ()

@property (nonatomic, strong) id<ApiService> apiService;

@end

@implementation ApiServicePassthrough

- (instancetype)initWithApiService:(id<ApiService>)apiService {

if (self = [super init]) {

self.apiService = apiService;

}

return self;

}

- (void)execNetRequest {

[self.apiService requestNetWithUrl:self.url Param:self.param];

}

@end

经过Protocol的改造，ApiService对象化身为ApiService接口，其不再依赖于任何对象，做到了真正的接口依赖取代对象依赖，具有更强的业务兼容性

定义一个Get请求对象

@interface GetApiService : NSObject  <ApiService>

@end

@implementation GetApiService

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    // to do
}

@end

@interface GetApiService : NSObject <ApiService>

@end

@implementation GetApiService

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

// to do

}

@end

请求代码也随之改变

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    id<ApiService> apiSrevice = [GetApiService new];
    ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];
    apiServicePassthrough.url = url;
    apiServicePassthrough.param = param;
    [apiServicePassthrough execNetRequest];
}

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

id<ApiService> apiSrevice = [GetApiService new];

ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];

apiServicePassthrough.url = url;

apiServicePassthrough.param = param;

[apiServicePassthrough execNetRequest];

}

@end

对象可以继承对象，Protocol也可以继承Protocol，并且可以继承多个Protocol，Protocol具有更强的灵活性。某一天，业务需求变更需要用到新的Post请求时，可以不用修改 GetApiService一行代码，定义一个新的 PostApiService实现Post请求即可，避免了对象里面出现过多的if-else代码，也保证了代码的整洁性

依赖注入

文章写到这里，细心的童鞋可能已经发现问题——GetApiService依然是以对象依赖的形式存在。如何解决这个问题？没错，那就是依赖注入！

依赖注入是什么？借用博客里面的一句话，其最大的特点就是：帮助我们开发出松散耦合、可维护、可测试的代码和程序。这条原则的做法是大家熟知的面向接口，或者说是面向抽象编程。 objc上这篇文章介绍的不错，有兴趣的童鞋也可以看看，在此就不再累述

基于依赖注入objection开源库的基础上继续改造ApiService

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {
    id<ApiService> apiSrevice = [[JSObjection createInjector] getObject:[GetApiService class]];
    ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];
    apiServicePassthrough.url = url;
    apiServicePassthrough.param = param;
    [apiServicePassthrough execNetRequest];
}

@end

@implementation NSObject (ApiServiceProtocol)

- (void)requestNetWithUrl:(NSURL *)url Param:(NSDictionary *)param {

id<ApiService> apiSrevice = [[JSObjection createInjector] getObject:[GetApiService class]];

ApiServicePassthrough *apiServicePassthrough = [[ApiServicePassthrough alloc] initWithApiService:apiSrevice];

apiServicePassthrough.url = url;

apiServicePassthrough.param = param;

[apiServicePassthrough execNetRequest];

}

@end

调用者关心请求接口，实现者关心需要实现的接口，各司其职，互不干涉

接口和实现分离的设计适用于团队协作开发，实现了系统的松散耦合，便于以后升级扩展。当然，接口编程对开发人员的要求也比较高，需要提前定义好接口，接口一变，全部乱套，这就是所谓的设计比实现难，但是设计接口的人工资都高啊！！！

2015/12/20，许多朋友希望出个demo，特此补上。另阿里音乐正在招聘iOS高级开发工程师，有兴趣的朋友可以微博或者网页下面跟我留言内推哦！

后记：你可以在github找到我，也可以通过微博联系我，感谢你的来访！

iOS开发OpenGL新手入门

转载请注明出处:http://www.olinone.com/

写在前头，好久没有更新博客，感谢老朋友的再次来访，同时也欢迎新朋友~

说起OpenGL，相信大不多数朋友都不会陌生，或多或少都有接触。本文不属于OpenGL提高篇，主要目的在于帮助新手更快熟悉iOS中如何使用OpenGL，关于这方面的介绍，网上也有很多，本文主要任务在于整理，介绍稍有偏重。这里有比较完整的Demo，可以协助大家更快上手

OpenGL版本

iOS系统默认支持OpenGl ES1.0、ES2.0以及ES3.0 3个版本，三者之间并不是简单的版本升级，设计理念甚至完全不同，在开发OpenGL项目前，需要根据业务需求选择合适的版本。这方面的介绍不少，不再展开。在学习OpenGL代码的时候也需要知道它对应着哪个版本，在ES1中执行ES2代码是看不到任何效果的，你可以在初始化EAGLContext时指定ES版本号

EAGLContext *context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];

1	EAGLContext *context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];

OpenGL坐标系

OpenGL坐标系不同于UIKit坐标系，其实它是这样的

除了方向，还有一点需要注意，默认情况各个方向坐标值范围为（-1，1），而不是UIKit中的（0，320）。当绘制点(320，0)，它并不会出现在屏幕右上角。在ES1中，可以通过以下代码将坐标系转化为熟悉的（320，480）

- (void)glkView:(GLKView *)view drawInRect:(CGRect)rect {
    glViewport(0, 0, rect.size.width * 2, rect.size.height * 2);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glOrthof(0, 320, 0, 480, -1024, 1024);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
}

- (void)glkView:(GLKView *)view drawInRect:(CGRect)rect {

glViewport(0, 0, rect.size.width * 2, rect.size.height * 2);

glMatrixMode(GL_PROJECTION);

glLoadIdentity();

glOrthof(0, 320, 0, 480, -1024, 1024);

glMatrixMode(GL_MODELVIEW);

glLoadIdentity();

}

—————————————————— olinone出品 ——————————————————

猥琐的分割线过后，接下来说说iOS中如何使用OpenGL

GLKViewController & GLKView

机智的码农是不是已经发现这两个对象，为了方便大家更快的开发，系统为OpenGL提供了简单的封装，继承GLKViewController定义自己的ViewController，GLKViewController的view为GLKView类，GLKView的delegate定义了绘制回调函数

- (void)glkView:(GLKView *)view drawInRect:(CGRect)rect

1	- (void)glkView:(GLKView *)view drawInRect:(CGRect)rect

GLKViewController定义数据刷新函数，当子类实现-(void)update方法，glkViewControllerUpdate方法将不再被调用

- (void)glkViewControllerUpdate:(GLKViewController *)controller

1	- (void)glkViewControllerUpdate:(GLKViewController *)controller

HJGLKViewControllerDemo模拟了GLKViewController方法实现，有兴趣的童鞋可以查看GLKViewController内部实现机制。需要补充一点，默认情况下，GLKViewController渲染RunLoop并非NSRunLoopCommonModes，而是NSDefaultRunLoopMode，因此在UIKit中使用GLKViewController，当滑动界面时，OpenGL是不会渲染的，为了解决这个问题，可以使用HJGLKViewController替换GLKViewController，HJGLKViewController中默认渲染RunLoop使用NSRunLoopCommonModes模式

EAGLContext

在介绍选择版本时已经提到EAGLContext，与UIKit中CGContextRef相似，EAGLContext相当于OpenGL绘制句柄或者上下文，在绘制试图之前，需要指定使用创建的上下文绘制

[EAGLContext setCurrentContext:view.context];

1	[EAGLContext setCurrentContext:view.context];

当一个APP可能存在多个EAGLContext时，需要处理并存冲突等问题，比如大家所熟知的GPUImage，都会使用到EAGLContext。因此，在使用中要记得及时释放。有兴趣的朋友可以看看这篇文章

Draw

OpenGL绘制本文就不做介绍，HJGLKViewControllerDemo中有大量的示例，顺便推荐几篇相关文章

小贴士：当App退到后台时，切记暂停OpenGL绘制，否则可能导致crash

后记：iOS-Developer-Documents-Chinese是国内第一个苹果文档翻译组织，欢迎有志翻译苹果官方文档的朋友加入，QQ群：486111671

UICollectionView高级进阶篇

转载请注明出处:http://www.olinone.com/

HI，亲爱读者朋友们，又到了博客更新的时间，在经历了大半年的沉淀，目前博客日访问人次已突破400大关，最高峰达到2600人次，非常感谢各位朋友的来访，在以后的博客中争取为大家带来更多的干货。各位朋友如果有好的文章或者题材都可以推荐给我，有什么想了解的知识，都可以在下面跟我留言，或者@庞海礁的个人空间

在聊完几次理论后，今天给大家带来一篇关于UI的文章，看标题大家已经知道了，没错，就是大家所熟悉的UICollectionView。说起github上赫赫有名的卡片展示视图iCarousel，大多数iOS开发人员或多或少都有听过或使用过，其丰富的展示样式经常出现在某些APP的一级路径，其实，苹果公司针对卡片样式祭出了自己的解决方案——UICollectionView

废话少说，先上干货HJCarouselDemo

看完GIF展示的效果，各位是否已经蠢蠢欲动，这不就是iCarousel视图嘛，没错！但是今天我们采用UICollectionView实现这些效果。平常开发中，最熟悉的莫过于UICollectionViewFlowLayout，其实UICollectionViewFlowLayout相当于苹果提前定义的一个特殊UICollectionViewLayout。

先看看UICollectionViewLayout类的官方文档（好吧，原谅我半天打不开苹果网址，最近敏感期，各种和谐)，还是直接看代码吧，总之，自定义UICollectionViewLayout，必须实现以下几个函数

collectionViewContentSize
layoutAttributesForElementsInRect:
layoutAttributesForItemAtIndexPath:
layoutAttributesForSupplementaryViewOfKind:atIndexPath: (if your layout supports supplementary views)
layoutAttributesForDecorationViewOfKind:atIndexPath: (if your layout supports decoration views)
shouldInvalidateLayoutForBoundsChange:

看函数名就可以知道各个函数实现的功能：第一个定位View的contentSize，第二个函数定义屏幕展示的范围和数量，第三个定义cell的布局，第四个和第五个是可选项，定义SupplementaryView以及DecorationView的布局，最后一个定义是否重新布局

UICollectionViewLayout的精髓在于你可以定义每个cell的UICollectionViewLayoutAttributes属性，包括

@property (nonatomic) CGRect frame;
@property (nonatomic) CGPoint center;
@property (nonatomic) CGSize size;
@property (nonatomic) CATransform3D transform3D;
@property (nonatomic) CGRect bounds NS_AVAILABLE_IOS(7_0);
@property (nonatomic) CGAffineTransform transform NS_AVAILABLE_IOS(7_0);
@property (nonatomic) CGFloat alpha;
@property (nonatomic) NSInteger zIndex; // default is 0

@property (nonatomic) CGRect frame;

@property (nonatomic) CGPoint center;

@property (nonatomic) CGSize size;

@property (nonatomic) CATransform3D transform3D;

@property (nonatomic) CGRect bounds NS_AVAILABLE_IOS(7_0);

@property (nonatomic) CGAffineTransform transform NS_AVAILABLE_IOS(7_0);

@property (nonatomic) CGFloat alpha;

@property (nonatomic) NSInteger zIndex; // default is 0

通过定义transform3D属性可以实现视图的旋转、放大以及透视等效果，具体实现参考HJCarouselDemo

在这里格外需要强调的一点，那就是page属性，当滑动停止时，希望UICollectionView滑动到卡片的中心，而不是任意位置

UICollectionViewLayout定义函数

- (CGPoint)targetContentOffsetForProposedContentOffset:(CGPoint)proposedContentOffset withScrollingVelocity:(CGPoint)velocity

其中，proposedContentOffset为系统期望滑动到的位置，velocity为加速度，你可以通过这两个参数以及当前所在的位置计算出你希望它滑动到的位置，具体算法根据需求的不同来实现

有用过我们天天动听iOS客户端或者QQ音乐的朋友，可能都非常熟悉这个动画效果，天天动听的推荐页面以及QQ音乐的电台界面，是不是就这样，嘿嘿！重要的事说三遍，赶快下载天天动听客户端，跟我们一起摇摆起来~~~

番外篇

说完View，接下来聊聊Controller，谈什么了？谈谈它们之间的关系，最近业界对设计模式的话题讨论比较热烈，MVC、MVVM、MVP等等，不知道各位在实际开发中一般使用什么样的设计模式，有什么好的想法都可以在下面留言，下期再见！