今天看到了这位兄弟的面试题总结文章:先是程序员，然后才是iOS程序员 — 写给广大非科班iOS开发者的一篇面试总结,里面的问题确实不错，所以就查资料学习了下，在这给个答案(链接-_-)，以及一些其他的原理和发散。
问题
- 如果让你实现属性的weak，如何实现的？
- 如果让你来实现属性的atomic，如何实现？
- KVO为什么要创建一个子类来实现？
- 类结构体的组成，isa指针指向了什么？（这里应该将元类和根元类也说一下）
- RunLoop有几种事件源？有几种模式？
- 方法列表的数据结构是什么？
- 分类是如何实现的？它为什么会覆盖掉原来的方法？
1. weak原理
这篇文章我觉得写得很好，我用自己的话简单总结下：
weak是啥？在一个对象被释放后，指向它的所有weak指针都跟着被设为nil，所以关键就是怎么从这个对象找到所有指向它的weak指针。
系统使用一张表，用对象的地址做key,值是对象的引用计数和weak指针表。
在类似__weak SomeClass *obj = otherObj这种的时候，调用storeWeak方法把新指针obj和对象otherObj关联起来,实际干的就是：
- 使用指针获取旧的对象，在使用旧对象获取旧对象的weak表，把指针从就旧对象的weak表里移除
- 使用新对象获取新对象的weak表，把指针加入到weak表里
2.实现atomic
简单说，在属性的getter/setter实现里，先加锁然后再对变量进行访问
- (UITextField *) userName {
UITextField *retval = nil;
@synchronized(self) {
retval = [[userName retain] autorelease];
}
return retval;
}
- (void) setUserName:(UITextField *)userName_ {
@synchronized(self) {
[userName_ retain];
[userName release];
userName = userName_;
}
}
发散下
- 首先这样做就会加大开销，因为开锁解锁
- 然后这样做，实际很多时候并不能保证线程同步的作用，除了上面的stackoverflow问题里的第一个答案提到的
firstname+secondname的例子,我可以举一个：比如仓库里有5袋米，然后10个人去拿，每个人就相当于每个线程，每个线程先要check是否还有米，然后决定去拿use。atomic只能保证你check的时候是独立的，use的时候也是独立的，这样可能出现什么？5人check完，第一个人还没有use,那么第6个人check的时候，他以为还有5袋米，然后他也去拿，最后结果就是米的数量变成了负数。
简单说，就是check和use要正整体加锁：
lock->check->use->unlock
而atomic是在属性内部实现的加锁，即相当于：
lock->check->unlock->可能其他线程插入进来...->lock->use->unlock。
- 然后提到
@synchronized,就也说下它的原理,参考这里。
简单说：
@synchronized(obj) {
// do work
}
也是用一张哈希表，在进入这个代码块的时候，使用obj这个对象获取对应的递归锁，然后加锁，在出代码块的时候解锁。所以这是以obj的地址为唯一性的锁。
3. KVO的原理
- 在你给对象a设置观察者之后，假设a的类型为ClassA,那么会从ClassA临时建一个子类subClassA，然后重写你观察的那个属性的方法，把对象a类型改成这个子类subClassA。
- 修改子类的方法使用了runtime里的isa指针的作用
- 回到问题，为什么要实现一个子类？
- 重写属性，是怎么重写的？比如setName会变成：
void setName:(NSString *)name{
[self willChangeValueForKey:@"name"];
[super setName:name];
[self didChangeValueForKey:@"name"];
}
也就是通过willChangeValueForKey和didChangeValueForKey来通知外界的，所以你必须要重写原本的setter方法，否则外界不会收到消息
- 那么重写就有两种选择：改本类和改子类。如果改了本类，就会污染本类的所有其他的对象的方法
- 本来我还想到重写的方法会被反复重写，导致
willChangeValueForKey反复嵌套，但想这个是可以通过设置表示来避免的，比如在类里建个表存储KVO重写的方法 - 其实这里是一个很好的思路，我见过使用method swizzling导致类的其他地方被污染的，可以像KVO里一样，自动创建一个子类，然后就你当前的对象方法被修改了，这样你就不用担心其他地方会因为方法篡改而导致位置bug
4. isa指针的问题
看这个图就好了：
isa指针图
好，下一题！-_-
5. RunLoop
深入理解RunLoop,看这篇就好了
mode有几种：公开的有kCFRunLoopDefaultMode和UITrackingRunLoopMode后一种在scrollView滚动的时候会切换到。这里会牵扯到一个经典考题：滚动导致NSTimer不起作用的问题。上面的文章里有说明白。
事件有：source、timer和observer
struct __CFRunLoopMode {
CFStringRef _name; // Mode Name, 例如 @"kCFRunLoopDefaultMode"
CFMutableSetRef _sources0; // Set
CFMutableSetRef _sources1; // Set
CFMutableArrayRef _observers; // Array
CFMutableArrayRef _timers; // Array
...
};
6. 方法列表的结构
先看类的结构：
struct objc_class {
Class isa OBJC_ISA_AVAILABILITY;
#if !__OBJC2__
Class super_class OBJC2_UNAVAILABLE;
const char *name OBJC2_UNAVAILABLE;
long version OBJC2_UNAVAILABLE;
long info OBJC2_UNAVAILABLE;
long instance_size OBJC2_UNAVAILABLE;
struct objc_ivar_list *ivars OBJC2_UNAVAILABLE;
struct objc_method_list **methodLists OBJC2_UNAVAILABLE;
struct objc_cache *cache OBJC2_UNAVAILABLE;
struct objc_protocol_list *protocols OBJC2_UNAVAILABLE;
#endif
} OBJC2_UNAVAILABLE;
struct objc_method_list **methodLists这个就是方法列表了，首先这里有个不易发现的知识点：为什么methodLists是指针的指针而不是指针？
这个问题里的答案说了一些,简单说：
objc_method_list *代表一个方法链，按理说对于类来说，这个结构就足够了，objc_method_list **这个代表n条方法链，其实是因为Category才会这样。
在合并Category和类的时候，就可以把Category的方法直接放进来，而不用修改原来的方法链。
while (i--) {
//取出category的方法列表
method_list_t *mlist = cat_method_list(cats->list[i].cat, isMeta);
if (mlist) {
//直接放到列的方法列表的列表里，而不修改类本身的方法列表
mlists[mcount++] = mlist;
fromBundle |= cats->list[i].fromBundle;
}
}
attachMethodLists(cls, mlists, mcount, NO, fromBundle, inoutVtablesAffected);
个人认为这样是为了：
- 保持各个方法表的独立，比如category定义了和类本身同样的方法，可以共存
- 修改起来方便些，如果只有一个表，就得增加和删除一大堆的节点，而且还得维护那些节点是category的，哪些是类的。
然后是objc_method_list的结构：
struct objc_method_list {
struct objc_method_list *obsolete OBJC2_UNAVAILABLE;
int method_count OBJC2_UNAVAILABLE;
#ifdef __LP64__
int space OBJC2_UNAVAILABLE;
#endif
/* variable length structure */
struct objc_method method_list[1] OBJC2_UNAVAILABLE;
}
这里没有借鉴，只有自己翻一下runtime的开源代码(这几个问题其实都是对runtime源码的解析吧)
/* These next three functions are the heart of ObjC method lookup. */
static inline Method _findMethodInList(struct objc_method_list * mlist, SEL sel) {
int i;
if (!mlist) return NULL;
for (i = 0; i < mlist->method_count; i++) {
Method m = &mlist->method_list[i];
if (m->method_name == sel) {
return m;
}
}
return NULL;
}
上面这个函数是从里objc_method_list找到对应的Method，可以看出方法存储在method_list里面。没看代码前，我以为是objc_method_list实际是链表的一个节点，每个method_list只存储一个方法，然后用obsolete连接下一个方法。
7. Category的原理
- 把category的方法、属性和协议都和原有类合并;
- 对于属性和协议，把链表衔接起来就好了
newproperties = buildPropertyList(NULL, cats, isMeta);
if (newproperties) {
newproperties->next = cls->data()->properties;
cls->data()->properties = newproperties;
}
newprotos = buildProtocolList(cats, NULL, cls->data()->protocols);
if (cls->data()->protocols && cls->data()->protocols != newprotos) {
_free_internal(cls->data()->protocols);
}
cls->data()->protocols = newprotos;
- 对于方法，先把所有category的方法列表都存在列表的列表（method_list_t **）里，然后把类原本的方法列表放进来
// Copy old methods to the method list array
for (i = 0; i < oldCount; i++) {
newLists[newCount++] = oldLists[i];
}
-
所以为什么会覆盖的问题就得到了解决：并不是覆盖，而是在类本身的方法列表放到了后面，从而被滞后隐藏了。其实也可以猜得到，不可能把原本类的方法去掉，否则原本方法就丢了，而现在这样，在category移除后，原本类的方法又可以暴露出来了。
-
关于category，有个在静态库的加载问题，这篇回答讲得非常好。简单说就是category不是编译器用来确认加载的标识
Categories are a runtime-only feature, categories aren't symbols like classes or functions and that also means a linker cannot determine if a category is in use or not.
解决方案就是在Other Linker Flags里添加-Objc,-force_load或-all_load来加载，-Objc是所有OC代码的文件都加载，-force_load指定文件加载，-all_load全部加载。
其他的一些相关问题
- 自动释放池的原理：
参考这篇
在开始的时候，创建一个AutoreleasePoolPage类型的双向链表，它会保存所有使用__autoreleasing标记的对象(MRC时直接调用autoRelease方法)，实际就是调用了下面的方法，创建一个新节点加进去
static inline id *autoreleaseFast(id obj)
{
AutoreleasePoolPage *page = hotPage();
if (page && !page->full()) {
return page->add(obj);
} else if (page) {
return autoreleaseFullPage(obj, page);
} else {
return autoreleaseNoPage(obj);
}
}
在pool结束后，对每个对象release。
- Associated Objects的原理，同样使用哈希表。
- 对于一些调试，用lldb可以达到特殊效果，参考这篇
网友评论