KVOController实现的一些思考和疑惑

head first设计模式的第二个设计模式就是观察者模式,非常常见的一个设计思想,很多语言都内置了它的实现。iOS也不例外,键值修改后会通知观察者(KVO)。不过那又臭又长的写法让人很难提起兴趣用它。所以就有了KVOController 前言 这篇文章只是我看完KVOController源码的一些疑惑,就是KVOController为什么要这样做。 系统KVO的实现可以看这篇KVO进阶 —— 源码实现探究 KVOController源码的分析可以看这篇优雅地使用 KVO 用NSMapTable代替NSMutableDictionary NSMapTable和NSHashTable在很多第三方框架或者底层源码里都有用到。类似于更常用的NSDictionary,NSSet。 从他们的初始化方法中就能知道,他们最大的优点就是可以弱引用添加的对象,其实性能还是略差的。 //KVOController默认是强引用 - (instancetype) ...

如何优雅地调试

几乎所有高级语言的编译过程都是预处理>编译>汇编>链接,而gcc是应用最广的编译器了。但是apple嫌弃他太臃肿,于是就有了Clang(编译器前端),LLVM(编译器架构,本质是一个库),LLDB(调试器) 效率低下的调试方法 打断点配合NSLog,这真是最朴素的调试方式。 NSLog效率低下的原因及尝试lldb断点打印Log这篇博客里有个测试,NSLog和printf的效率差了100多倍。调试的NSLog还好,记得自己删掉就行,但是代码里充斥着许多的NSLog日志,肯定是消耗性能的。 一般是这样处理: ...

从一次内存峰值说起

最近把一个游戏内嵌到app里,选用了微信开源的Mars,结果遇到了内存峰值。解决的方法很容易,加上@autoreleasepool就可以了。但是做实验的时候又有了好多疑惑,不停地往深处挖,最终了解了autoreleasepool的实现,Tagged Pointer,和NSString内存管理的特殊性。 Mars 我们做的小游戏需要实时传输数据,数据很小,就选用了Mars。结果内存一直涨,在这里加个autoreleasepool就可以避免内存峰值。 void StnCallBack::OnPush(int32_t _cmdid, const AutoBuffer& ...

多线程单线程,同步异步,并发并行,串行队列并行队列,看这里就对了

多线程开发用了很久,但是一直没去深入了解。长久以来一直有一些迷惑。直到深入了解后,才发现了以前的理解有不少错误的地方。 单线程等于同步,多线程等于异步 这种理解很直观,毕竟只有一个线程怎么异步? Node.js表示不服,我就是单线程,我也能异步。谈一谈Node中的异步和单线程。 看完这篇文章我明白了单线程也能异步,把IO等耗时的操作比作烧水,我可以在这个时候切菜,这就是异步啊。 等等,似乎有点不对,那io又谁来开启,又谁来通知cpu我已经结束了呢? Node.js异步IO的实现,这篇文章解决了我的疑惑。 Node. ...

iOS网络层设计感想

App的开发无外乎从网络端获取数据显示在屏幕上,数据做些缓存或者持久化,所以网络层极为重要。原来只是把AFNetwork二次封装了一下,使得调用变得很简单,并没有深层次的考虑一些问题。 前言 参考: 网络层设计方案 这篇文章提的问题也正是我平时经常纠结的,但是一直没有深入思考。文章给的解决方案和为什么这样做让人茅塞顿开。以下主要就是我的观后感。 三个问题 使用哪种交互模式来跟业务层做对接? 是否有必要将API返回的数据封装成对象然后再交付给业务层? 使用集约化调用方式还是离散型调用方式去调用API? 我的设计 基本上每个网络层都会涉及到这三个问题。 我原先的设计是: //APIClient.h @interface APIClient : AFHTTPSessionManager + (instancetype) ...