阿里、字节 一套高效的iOS面试题解答(完结)

[TOC]

runtime相关问题

结构模型

1. 介绍下runtime的内存模型(isa、对象、类、metaclass、结构体的存储信息等)

2. 为什么要设计metaclass

3. class_copyIvarList & class_copyPropertyList区别

class_copyIvarList 获取类对象中的所有实例变量信息,从 class_ro_t 中获取:

Ivar *
class_copyIvarList(Class cls, unsigned int *outCount)
{
    const ivar_list_t *ivars;
    Ivar *result = nil;
    unsigned int count = 0;

    if (!cls) {
        if (outCount) *outCount = 0;
        return nil;
    }

    mutex_locker_t lock(runtimeLock);

    assert(cls->isRealized());
    
    if ((ivars = cls->data()->ro->ivars)  &&  ivars->count) {
        result = (Ivar *)malloc((ivars->count+1) * sizeof(Ivar));
        
        for (auto& ivar : *ivars) {
            if (!ivar.offset) continue;  // anonymous bitfield
            result[count++] = &ivar;
        }
        result[count] = nil;
    }
    
    if (outCount) *outCount = count;
    return result;
}

class_copyPropertyList 获取类对象中的属性信息, class_rw_tproperties,先后输出了 category / extension/ baseClass 的属性,而且仅输出当前的类的属性信息,而不会向上去找 superClass 中定义的属性。

objc_property_t *
class_copyPropertyList(Class cls, unsigned int *outCount)
{
    if (!cls) {
        if (outCount) *outCount = 0;
        return nil;
    }

    mutex_locker_t lock(runtimeLock);

    checkIsKnownClass(cls);
    assert(cls->isRealized());
    
    auto rw = cls->data();

    property_t **result = nil;
    unsigned int count = rw->properties.count();
    if (count > 0) {
        result = (property_t **)malloc((count + 1) * sizeof(property_t *));

        count = 0;
        for (auto& prop : rw->properties) {
            result[count++] = ∝
        }
        result[count] = nil;
    }

    if (outCount) *outCount = count;
    return (objc_property_t *)result;
}

Q1: class_ro_t 中的 baseProperties 呢?

Q2: class_rw_t 中的 properties 包含了所有属性,那何时注入进去的呢? 答案见 5.

4. class_rw_tclass_ro_t 的区别

class_rw_t_class_ro_t.png

测试发现,class_rw_t 中的 properties 属性按顺序包含分类/扩展/基类中的属性。

struct class_ro_t {
    uint32_t flags;
    uint32_t instanceStart;
    uint32_t instanceSize;
#ifdef __LP64__
    uint32_t reserved;
#endif

    const uint8_t * ivarLayout;
    
    const char * name;
    method_list_t * baseMethodList;
    protocol_list_t * baseProtocols;
    const ivar_list_t * ivars;

    const uint8_t * weakIvarLayout;
    property_list_t *baseProperties;

    method_list_t *baseMethods() const {
        return baseMethodList;
    }
};

struct class_rw_t {
    // Be warned that Symbolication knows the layout of this structure.
    uint32_t flags;
    uint32_t version;

    const class_ro_t *ro;

    method_array_t methods;
    property_array_t properties;
    protocol_array_t protocols;

    Class firstSubclass;
    Class nextSiblingClass;

    char *demangledName;

#if SUPPORT_INDEXED_ISA
    uint32_t index;
#endif
}

5. category如何被加载的,两个category的load方法的加载顺序,两个category的同名方法的加载顺序

... -> realizeClass -> methodizeClass(用于Attach categories)-> attachCategories 关键就是在 methodizeClass 方法实现中

static void methodizeClass(Class cls)
{
    runtimeLock.assertLocked();

    bool isMeta = cls->isMetaClass();
    auto rw = cls->data();
    auto ro = rw->ro;
    
    // =======================================
        // 省略.....
    // =======================================
  
    property_list_t *proplist = ro->baseProperties;
    if (proplist) {
        rw->properties.attachLists(&proplist, 1);
    }

    // =======================================
        // 省略.....
    // =======================================

    // Attach categories.
    category_list *cats = unattachedCategoriesForClass(cls, true /*realizing*/);
    attachCategories(cls, cats, false /*don't flush caches*/);

    // =======================================
        // 省略.....
    // =======================================
    
    if (cats) free(cats);

}

上面代码能确定 baseProperties 在前,category 在后,但决定顺序的是 rw->properties.attachLists 这个方法:

property_list_t *proplist = ro->baseProperties;
if (proplist) {
  rw->properties.attachLists(&proplist, 1);
}

/// category 被附加进去
void attachLists(List* const * addedLists, uint32_t addedCount) {
        if (addedCount == 0) return;

        if (hasArray()) {
            // many lists -> many lists
            uint32_t oldCount = array()->count;
            uint32_t newCount = oldCount + addedCount;
            setArray((array_t *)realloc(array(), array_t::byteSize(newCount)));
            array()->count = newCount;
            
            // 将旧内容移动偏移量 addedCount 然后将 addedLists copy 到起始位置
            /*
                struct array_t {
                        uint32_t count;
                        List* lists[0];
                        };
            */
            memmove(array()->lists + addedCount, array()->lists, 
                    oldCount * sizeof(array()->lists[0]));
            memcpy(array()->lists, addedLists, 
                   addedCount * sizeof(array()->lists[0]));
        }
        else if (!list  &&  addedCount == 1) {
            // 0 lists -> 1 list
            list = addedLists[0];
        } 
        else {
            // 1 list -> many lists
            List* oldList = list;
            uint32_t oldCount = oldList ? 1 : 0;
            uint32_t newCount = oldCount + addedCount;
            setArray((array_t *)malloc(array_t::byteSize(newCount)));
            array()->count = newCount;
            if (oldList) array()->lists[addedCount] = oldList;
            memcpy(array()->lists, addedLists, 
                   addedCount * sizeof(array()->lists[0]));
        }
    }

所以 category 的属性总是在前面的,baseClass的属性被往后偏移了。

Q1:那么多个 category 的顺序呢?答案见6

2020/03/18 补充下应用程序 image 镜像加载到内存中时, Category 解析的过程,注意下面的 while(i--) 这里倒叙将 category 中的协议 方法 属性添加到了 rw = cls->data() 中的 methods/properties/protocols 中。

static void 
attachCategories(Class cls, category_list *cats, bool flush_caches)
{
    if (!cats) return;
    if (PrintReplacedMethods) printReplacements(cls, cats);

    bool isMeta = cls->isMetaClass();

    // fixme rearrange to remove these intermediate allocations
    method_list_t **mlists = (method_list_t **)
        malloc(cats->count * sizeof(*mlists));
    property_list_t **proplists = (property_list_t **)
        malloc(cats->count * sizeof(*proplists));
    protocol_list_t **protolists = (protocol_list_t **)
        malloc(cats->count * sizeof(*protolists));

    // Count backwards through cats to get newest categories first
    int mcount = 0;
    int propcount = 0;
    int protocount = 0;
    int i = cats->count;
    bool fromBundle = NO;
    while (i--) {
        auto& entry = cats->list[i];

        method_list_t *mlist = entry.cat->methodsForMeta(isMeta);
        if (mlist) {
            mlists[mcount++] = mlist;
            fromBundle |= entry.hi->isBundle();
        }

        property_list_t *proplist = 
            entry.cat->propertiesForMeta(isMeta, entry.hi);
        if (proplist) {
            proplists[propcount++] = proplist;
        }

        protocol_list_t *protolist = entry.cat->protocols;
        if (protolist) {
            protolists[protocount++] = protolist;
        }
    }
    auto rw = cls->data();
        
    // 注意下面的代码,上面采用倒叙遍历方式,所以后编译的 category 会先add到数组的前部
    prepareMethodLists(cls, mlists, mcount, NO, fromBundle);
    rw->methods.attachLists(mlists, mcount);
    free(mlists);
    if (flush_caches  &&  mcount > 0) flushCaches(cls);

    rw->properties.attachLists(proplists, propcount);
    free(proplists);

    rw->protocols.attachLists(protolists, protocount);
    free(protolists);
}

6. category & extension区别,能给NSObject添加Extension吗,结果如何

category:

  • 运行时添加分类属性/协议/方法
  • 分类添加的方法会“覆盖”原类方法,因为方法查找的话是从头至尾,一旦查找到了就停止了
  • 同名分类方法谁生效取决于编译顺序,image 读取的信息是倒叙的,所以编译越靠后的越先读入
  • 名字相同的分类会引起编译报错;

extension:

  • 编译时决议
  • 只以声明的形式存在,多数情况下就存在于 .m 文件中;
  • 不能为系统类添加扩展

7. 消息转发机制,消息转发机制和其他语言的消息机制优劣对比

8. 在方法调用的时候,方法查询-> 动态解析-> 消息转发 之前做了什么

9. IMPSELMethod的区别和使用场景

三者的定义:

typedef struct method_t *Method;

using MethodListIMP = IMP;

struct method_t {
    SEL name;
    const char *types;
    MethodListIMP imp;
};

Method 同样是个对象,封装了方法名和实现,关于 Type Encodings

Code Meaning
c A char
i An int
s A short
l A long``l is treated as a 32-bit quantity on 64-bit programs.
q A long long
C An unsigned char
I An unsigned int
S An unsigned short
L An unsigned long
Q An unsigned long long
f A float
d A double
B A C++ bool or a C99 _Bool
v A void
* A character string (char *)
@ An object (whether statically typed or typed id)
# A class object (Class)
: A method selector (SEL)
[array type] An array
{name=type...} A structure
(name=type...) A union
bnum A bit field of num bits
^type A pointer to type
? An unknown type (among other things, this code is used for function pointers)

-(void)hello:(NSString *)name encode 下就是 v@:@

10. loadinitialize方法的区别什么?在继承关系中他们有什么区别

load 方法调用时机,而且只调用当前类本身,不会调用superClass 的 +load 方法:

void
load_images(const char *path __unused, const struct mach_header *mh)
{
    // Return without taking locks if there are no +load methods here.
    if (!hasLoadMethods((const headerType *)mh)) return;

    recursive_mutex_locker_t lock(loadMethodLock);

    // Discover load methods
    {
        mutex_locker_t lock2(runtimeLock);
        prepare_load_methods((const headerType *)mh);
    }

    // Call +load methods (without runtimeLock - re-entrant)
    call_load_methods();
}

void call_load_methods(void)
{
    static bool loading = NO;
    bool more_categories;

    loadMethodLock.assertLocked();

    // Re-entrant calls do nothing; the outermost call will finish the job.
    if (loading) return;
    loading = YES;

    void *pool = objc_autoreleasePoolPush();

    do {
        // 1. Repeatedly call class +loads until there aren't any more
        while (loadable_classes_used > 0) {
            call_class_loads();
        }

        // 2. Call category +loads ONCE
        more_categories = call_category_loads();

        // 3. Run more +loads if there are classes OR more untried categories
    } while (loadable_classes_used > 0  ||  more_categories);

    objc_autoreleasePoolPop(pool);

    loading = NO;
}

+initialize 实现

void _class_initialize(Class cls)
{
    assert(!cls->isMetaClass());

    Class supercls;
    bool reallyInitialize = NO;

    // Make sure super is done initializing BEFORE beginning to initialize cls.
    // See note about deadlock above.
    supercls = cls->superclass;
    if (supercls  &&  !supercls->isInitialized()) {
        _class_initialize(supercls);
    }
    
    // Try to atomically set CLS_INITIALIZING.
    {
        monitor_locker_t lock(classInitLock);
        if (!cls->isInitialized() && !cls->isInitializing()) {
            cls->setInitializing();
            reallyInitialize = YES;
        }
    }
    
    if (reallyInitialize) {
        // We successfully set the CLS_INITIALIZING bit. Initialize the class.
        
        // Record that we're initializing this class so we can message it.
        _setThisThreadIsInitializingClass(cls);

        if (MultithreadedForkChild) {
            // LOL JK we don't really call +initialize methods after fork().
            performForkChildInitialize(cls, supercls);
            return;
        }
        
        // Send the +initialize message.
        // Note that +initialize is sent to the superclass (again) if 
        // this class doesn't implement +initialize. 2157218
        if (PrintInitializing) {
            _objc_inform("INITIALIZE: thread %p: calling +[%s initialize]",
                         pthread_self(), cls->nameForLogging());
        }

        // Exceptions: A +initialize call that throws an exception 
        // is deemed to be a complete and successful +initialize.
        //
        // Only __OBJC2__ adds these handlers. !__OBJC2__ has a
        // bootstrapping problem of this versus CF's call to
        // objc_exception_set_functions().
#if __OBJC2__
        @try
#endif
        {
            callInitialize(cls);

            if (PrintInitializing) {
                _objc_inform("INITIALIZE: thread %p: finished +[%s initialize]",
                             pthread_self(), cls->nameForLogging());
            }
        }
#if __OBJC2__
        @catch (...) {
            if (PrintInitializing) {
                _objc_inform("INITIALIZE: thread %p: +[%s initialize] "
                             "threw an exception",
                             pthread_self(), cls->nameForLogging());
            }
            @throw;
        }
        @finally
#endif
        {
            // Done initializing.
            lockAndFinishInitializing(cls, supercls);
        }
        return;
    }
    
    else if (cls->isInitializing()) {
        // We couldn't set INITIALIZING because INITIALIZING was already set.
        // If this thread set it earlier, continue normally.
        // If some other thread set it, block until initialize is done.
        // It's ok if INITIALIZING changes to INITIALIZED while we're here, 
        //   because we safely check for INITIALIZED inside the lock 
        //   before blocking.
        if (_thisThreadIsInitializingClass(cls)) {
            return;
        } else if (!MultithreadedForkChild) {
            waitForInitializeToComplete(cls);
            return;
        } else {
            // We're on the child side of fork(), facing a class that
            // was initializing by some other thread when fork() was called.
            _setThisThreadIsInitializingClass(cls);
            performForkChildInitialize(cls, supercls);
        }
    }
    
    else if (cls->isInitialized()) {
        // Set CLS_INITIALIZING failed because someone else already 
        //   initialized the class. Continue normally.
        // NOTE this check must come AFTER the ISINITIALIZING case.
        // Otherwise: Another thread is initializing this class. ISINITIALIZED 
        //   is false. Skip this clause. Then the other thread finishes 
        //   initialization and sets INITIALIZING=no and INITIALIZED=yes. 
        //   Skip the ISINITIALIZING clause. Die horribly.
        return;
    }
    
    else {
        // We shouldn't be here. 
        _objc_fatal("thread-safe class init in objc runtime is buggy!");
    }
}

void callInitialize(Class cls)
{
    ((void(*)(Class, SEL))objc_msgSend)(cls, SEL_initialize);
    asm("");
}

注意看上面的调用了 callInitialize(cls) 然后又调用了 lockAndFinishInitializing(cls, supercls)

摘自iOS App冷启动治理 一文中对 Dyld 在各阶段所做的事情:

阶段 工作
加载动态库 Dyld从主执行文件的header获取到需要加载的所依赖动态库列表,然后它需要找到每个 dylib,而应用所依赖的 dylib 文件可能会再依赖其他 dylib,所以所需要加载的是动态库列表一个递归依赖的集合
Rebase和Bind - Rebase在Image内部调整指针的指向。在过去,会把动态库加载到指定地址,所有指针和数据对于代码都是对的,而现在地址空间布局是随机化,所以需要在原来的地址根据随机的偏移量做一下修正 - Bind是把指针正确地指向Image外部的内容。这些指向外部的指针被符号(symbol)名称绑定,dyld需要去符号表里查找,找到symbol对应的实现
Objc setup - 注册Objc类 (class registration) - 把category的定义插入方法列表 (category registration) - 保证每一个selector唯一 (selector uniquing)
Initializers - Objc的+load()函数 - C++的构造函数属性函数 - 非基本类型的C++静态全局变量的创建(通常是类或结构体)

最后 dyld 会调用 main() 函数,main() 会调用 UIApplicationMain(),before main()的过程也就此完成。

11. 说说消息转发机制的优劣

内存管理

1.weak的实现原理?SideTable的结构是什么样的

解答参考自瓜神的 weak 弱引用的实现方式

NSObject *p = [[NSObject alloc] init];
__weak NSObject *p1 = p;
// ====> 底层是runtime的 objc_initWeak
// xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc -fobjc-arc -fobjc-runtime=ios-13.2 main.m 得不到下面的代码,还是说命令参数不对。
NSObject objc_initWeak(&p, 对象指针);

通过 runtime 源码可以看到 objc_initWeak 实现:

id
objc_initWeakOrNil(id *location, id newObj)
{
    if (!newObj) {
        *location = nil;
        return nil;
    }

    return storeWeak<DontHaveOld, DoHaveNew, DontCrashIfDeallocating>
        (location, (objc_object*)newObj);
}

SideTable 结构体在 runtime 底层用于引用计数和弱引用关联表,其数据结构是这样:

struct SideTable {
    // 自旋锁
    spinlock_t slock;
    // 引用计数
    RefcountMap refcnts;
    // weak 引用
    weak_table_t weak_table;
}

struct weak_table_t {
    // 保存了所有指向指定对象的 weak 指针
    weak_entry_t *weak_entries;
    // 存储空间
    size_t    num_entries;
    // 参与判断引用计数辅助量
    uintptr_t mask;
    // hash key 最大偏移值
    uintptr_t max_hash_displacement;
};

根据对象的地址在缓存中取出对应的 SideTable 实例:

static SideTable *tableForPointer(const void *p)

或者如上面源码中 &SideTables()[newObj] 方式取表,这里的 newObj 是实例对象用其指针作为 key 拿到 从全局的 SideTables 中拿到实例自身对应的那张 SideTable

static StripedMap<SideTable>& SideTables() {
    return *reinterpret_cast<StripedMap<SideTable>*>(SideTableBuf);
}

取出实例方法的实现中,使用了 C++ 标准转换运算符 reinterpret_cast ,其表达方式为:

reinterpret_cast <new_type> (expression)

每一个 weak 关键字修饰的对象都是用 weak_entry_t 结构体来表示,所以在实例中声明定义的 weak 对象都会被封装成 weak_entry_t 加入到该 SideTable 中 weak_table

typedef objc_object ** weak_referrer_t;

struct weak_entry_t {
    DisguisedPtr<objc_object> referent;
    union {
        struct {
            weak_referrer_t *referrers;
            uintptr_t        out_of_line : 1;
            uintptr_t        num_refs : PTR_MINUS_1;
            uintptr_t        mask;
            uintptr_t        max_hash_displacement;
        };
        struct {
            // out_of_line=0 is LSB of one of these (don't care which)
            weak_referrer_t  inline_referrers[WEAK_INLINE_COUNT];
        };
 }

旧对象解除注册操作 weak_unregister_no_lock 和 新对象添加注册操作 weak_register_no_lock ,具体实现可前往 runtime 源码中查看或查看瓜的博文。

weak_store_pic.png

weak 关键字修饰的对象有两种情况:栈上和堆上。上图主要解释 id referent_id 和 id *referrer_id

  • 如果是栈上, referrer 值为 0x77889900,referent 值为 0x11223344
  • 如果是堆上 , referrer 值为 0x1100000+ offset(也就是 weak a 所在堆上的地址),referent 值为 0x11223344。

如此现在类 A 的实例对象有两个 weak 变量指向它,一个在堆上,一个在栈上。

void
weak_unregister_no_lock(weak_table_t *weak_table, id referent_id, 
                        id *referrer_id)
{
    objc_object *referent = (objc_object *)referent_id;   //  0x11223344
    objc_object **referrer = (objc_object **)referrer_id; //  0x77889900

    weak_entry_t *entry;

    if (!referent) return;
        
    // 从 weak_table 中找到 referent 也就是上面类A的实例对象
    if ((entry = weak_entry_for_referent(weak_table, referent))) {
        // 在 entry 结构体中的 referrers 数组中找到指针 referrer 所在位置
        // 将原本存储 referrer 值的位置置为 nil,相当于做了一个解绑操作
        // 因为 referrer 要和其他对象建立关系了
        remove_referrer(entry, referrer);
        bool empty = true;
        if (entry->out_of_line()  &&  entry->num_refs != 0) {
            empty = false;
        }
        else {
            for (size_t i = 0; i < WEAK_INLINE_COUNT; i++) {
                if (entry->inline_referrers[i]) {
                    empty = false; 
                    break;
                }
            }
        }

        if (empty) {
            weak_entry_remove(weak_table, entry);
        }
    }

    // Do not set *referrer = nil. objc_storeWeak() requires that the 
    // value not change.
}

weak 关键字修饰的属性或者变量为什么在对应类实例dealloc后会置为nil,那是因为在类实例释放的时候,dealloc 会从全局的引用计数和weak计数表sideTables中,通过实例地址去找到属于自己的那张表,表中的 weak_table->weak_entries 存储了所有 entry 对象——其实就是所有指向这个实例对象的变量,weak_entry_t 中的 referrers 数组存储的就是变量或属性的内存地址,逐一置为nil即可。

关联对象基本使用方法:

#import <objc/runtime.h>

static NSString * const kKeyOfImageProperty;

@implementation UIView (Image)

- (UIImage *)pt_image {
    return objc_getAssociatedObject(self, &kKeyOfImageProperty);
}

- (void)setPTImage:(UIImage *)image {
    objc_setAssociatedObject(self, &kKeyOfImageProperty, image,OBJC_ASSOCIATION_RETAIN);
}
@end

objc_AssociationPolicy 关联对象持有策略有如下几种 :

Behavior @property Equivalent Description
OBJC_ASSOCIATION_ASSIGN @property (assign) 或 @property (unsafe_unretained) 指定一个关联对象的弱引用。
OBJC_ASSOCIATION_RETAIN_NONATOMIC @property (nonatomic, strong) 指定一个关联对象的强引用,不能被原子化使用。
OBJC_ASSOCIATION_COPY_NONATOMIC @property (nonatomic, copy) 指定一个关联对象的copy引用,不能被原子化使用。
OBJC_ASSOCIATION_RETAIN @property (atomic, strong) 指定一个关联对象的强引用,能被原子化使用。
OBJC_ASSOCIATION_COPY @property (atomic, copy) 指定一个关联对象的copy引用,能被原子化使用。
OBJC_ASSOCIATION_GETTER_AUTORELEASE 自动释放类型

摘自瓜地:OBJC_ASSOCIATION_ASSIGN类型的关联对象和weak有一定差别,而更加接近于unsafe_unretained,即当目标对象遭到摧毁时,属性值不会自动清空。(翻译自Associated Objects

同样是Associated Objects文中,总结了三个关于Associated Objects用法:

源码实现非常简单,我添加了完整注释,对c++语法也做了一定解释:

id _object_get_associative_reference(id object, void *key) {
    id value = nil;
    uintptr_t policy = OBJC_ASSOCIATION_ASSIGN;
    {
        AssociationsManager manager;
        // manager.associations() 返回的是一个 `AssociationsHashMap` 对象(*_map)
        // 所以这里 `&associations` 中用了 `&`
        AssociationsHashMap &associations(manager.associations());
        // intptr_t 是为了兼容平台,在64位的机器上,intptr_t和uintptr_t分别是long int、unsigned long int的别名;在32位的机器上,intptr_t和uintptr_t分别是int、unsigned int的别名
        // DISGUISE 内部对指针做了 ~ 取反操作,“伪装”?
        disguised_ptr_t disguised_object = DISGUISE(object);
        /*
         AssociationsHashMap 继承自 unordered_map,存储 key-value 的组合
         iterator find ( const key_type& key ),如果 key 存在,则返回key对象的迭代器,
         如果key不存在,则find返回 unordered_map::end;因此可以通过 `map.find(key) == map.end()`
         判断 key 是否存在于当前 map 中。
         */
        AssociationsHashMap::iterator i = associations.find(disguised_object);
        if (i != associations.end()) {
            /*
                unordered_map 的键值分别是迭代器的first和second属性。
                所以说上面先通过 object 对象(实例对象or类对象) 找到其所有关联对象
                i->second 取到又是一个 ObjectAssociationMap
                此刻再通过我们自己设定的 key 来查找对应的关联属性值,不过使用
                `ObjcAssociation` 封装的
             */
            ObjectAssociationMap *refs = i->second;
            ObjectAssociationMap::iterator j = refs->find(key);
            if (j != refs->end()) {
                ObjcAssociation &entry = j->second;
                value = entry.value();
                policy = entry.policy();
                // 如果策略是 getter retain ,注意这里留个坑
                // 平常 OBJC_ASSOCIATION_RETAIN = 01401
                // OBJC_ASSOCIATION_GETTER_RETAIN = (1 << 8)
                if (policy & OBJC_ASSOCIATION_GETTER_RETAIN) {
                    // TODO: 有学问
                    objc_retain(value);
                }
            }
        }
    }
    if (value && (policy & OBJC_ASSOCIATION_GETTER_AUTORELEASE)) {
        objc_autorelease(value);
    }
    return value;
}

对应的set操作实现同样简单,耐心看下源码注释,即使不同c++都没问题:

void _object_set_associative_reference(id object, void *key, id value, uintptr_t policy) {
    // retain the new value (if any) outside the lock.
    ObjcAssociation old_association(0, nil);
    // 如果value对象存在,则进行retain or copy 操作
    id new_value = value ? acquireValue(value, policy) : nil;
    {
        AssociationsManager manager;
        // manager.associations() 返回的是一个 `AssociationsHashMap` 对象(*_map)
        // 所以这里 `&associations` 中用了 `&`
        AssociationsHashMap &associations(manager.associations());
        // intptr_t 是为了兼容平台,在64位的机器上,intptr_t和uintptr_t分别是long int、unsigned long int的别名;在32位的机器上,intptr_t和uintptr_t分别是int、unsigned int的别名
        // DISGUISE 内部对指针做了 ~ 取反操作,“伪装”
        disguised_ptr_t disguised_object = DISGUISE(object);
        if (new_value) {
            // break any existing association.
            /*
             AssociationsHashMap 继承自 unordered_map,存储 key-value 的组合
             iterator find ( const key_type& key ),如果 key 存在,则返回key对象的迭代器,
             如果key不存在,则find返回 unordered_map::end;因此可以通过 `map.find(key) == map.end()`
             判断 key 是否存在于当前 map 中。
             */
            AssociationsHashMap::iterator i = associations.find(disguised_object);
            // 这里和get操作不同,set操作时如果查询到对象没有关联对象,那么这一次设值是第一次,
            // 所以会创建一个新的 ObjectAssociationMap 用来存储实例对象的所有关联属性
            if (i != associations.end()) {
                // secondary table exists
                /*
                    unordered_map 的键值分别是迭代器的first和second属性。
                    所以说上面先通过 object 对象(实例对象or类对象) 找到其所有关联对象
                    i->second 取到又是一个 ObjectAssociationMap
                    此刻再通过我们自己设定的 key 来查找对应的关联属性值,不过使用
                    `ObjcAssociation` 封装的
                 */
                ObjectAssociationMap *refs = i->second;
                ObjectAssociationMap::iterator j = refs->find(key);
                // 关联属性用 ObjcAssociation 结构体封装
                if (j != refs->end()) {
                    old_association = j->second;
                    j->second = ObjcAssociation(policy, new_value);
                } else {
                    (*refs)[key] = ObjcAssociation(policy, new_value);
                }
            } else {
                // create the new association (first time).
                ObjectAssociationMap *refs = new ObjectAssociationMap;
                associations[disguised_object] = refs;
                (*refs)[key] = ObjcAssociation(policy, new_value);
                // 知识点是:newisa.has_assoc = true;
                object->setHasAssociatedObjects();
            }
        } else {
            // setting the association to nil breaks the association.
            AssociationsHashMap::iterator i = associations.find(disguised_object);
            if (i !=  associations.end()) {
                ObjectAssociationMap *refs = i->second;
                ObjectAssociationMap::iterator j = refs->find(key);
                if (j != refs->end()) {
                    old_association = j->second;
                    refs->erase(j);
                }
            }
        }
    }
    // release the old value (outside of the lock).
    if (old_association.hasValue()) ReleaseValue()(old_association);
}

3. 关联对象的如何进行内存管理的?关联对象如何实现weak属性

使用了 policy 设置内存管理策略,具体见上。

4. Autoreleasepool的原理?所使用的的数据结构是什么

5. ARC的实现原理?ARC下对retain & release做了哪些优化

6. ARC下哪些情况会造成内存泄漏

其他

  1. Method Swizzle注意事项
  2. 属性修饰符atomic的内部实现是怎么样的?能保证线程安全吗
  3. iOS 中内省的几个方法有哪些?内部实现原理是什么
  4. class、objc_getClass、object_getclass 方法有什么区别?

NSNotification相关

认真研读、你可以在这里找到答案轻松过面:一文全解iOS通知机制(经典收藏)

  1. 实现原理(结构设计、通知如何存储的、name&observer&SEL之间的关系等)
  2. 通知的发送时同步的,还是异步的
  3. NSNotificationCenter接受消息和发送消息是在一个线程里吗?如何异步发送消息
  4. NSNotificationQueue是异步还是同步发送?在哪个线程响应
  5. NSNotificationQueuerunloop的关系
  6. 如何保证通知接收的线程在主线程
  7. 页面销毁时不移除通知会崩溃吗
  8. 多次添加同一个通知会是什么结果?多次移除通知呢
  9. 下面的方式能接收到通知吗?为什么
// 发送通知
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:@"TestNotification" object:@1];
// 接收通知
[NSNotificationCenter.defaultCenter postNotificationName:@"TestNotification" object:nil];
复制代码

Runloop & KVO

runloop

runloop对于一个标准的iOS开发来说都不陌生,应该说熟悉runloop是标配,下面就随便列几个典型问题吧

  1. app如何接收到触摸事件的
  2. 为什么只有主线程的runloop是开启的
  3. 为什么只在主线程刷新UI
  4. PerformSelectorrunloop的关系
  5. 如何使线程保活

KVO(Finished)

runloop一样,这也是标配的知识点了,同样列出几个典型问题

1. 实现原理

KVO 会为需要observed的对象动态创建一个子类,以NSKVONotifying_ 最为前缀,然后将对象的 isa 指针指向新的子类,同时重写 class 方法,返回原先类对象,这样外部就无感知了;其次重写所有要观察属性的setter方法,统一会走一个方法,然后内部是会调用 willChangeValueForKeydidChangevlueForKey 方法,在一个被观察属性发生改变之前, willChangeValueForKey:一定会被调用,这就 会记录旧的值。而当改变发生后,didChangeValueForKey:会被调用,继而 observeValueForKey:ofObject:change:context: 也会被调用。

kvo.png

那么如何验证上面的说法呢?很简单,借助runtime 即可,测试代码请点击这里:

- (void)viewDidLoad {
    [super viewDidLoad];
    self.person = [[Person alloc] initWithName:@"pmst" age:18];
    self.teacher = [[Teacher alloc] initWithName:@"ppp" age:28];
    self.teacher.work = @"数学";
    self.teacher.numberOfStudent = 10;
    
    NSKeyValueObservingOptions options = NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld;
    
    RuntimeUtil *utils = [RuntimeUtil new];
    [utils logClassInfo:self.person.class];
    [self.person addObserver:self forKeyPath:@"age" options:options context:nil];
    [utils logClassInfo:object_getClass(self.person)];
    
    
    [utils logClassInfo:self.teacher.class];
    [self.teacher addObserver:self forKeyPath:@"age" options:options context:nil];
    [self.teacher addObserver:self forKeyPath:@"name" options:options context:nil];
    [self.teacher addObserver:self forKeyPath:@"work" options:options context:nil];
    [utils logClassInfo:object_getClass(self.teacher)];
}

这里 object_getClass() 方法实现也贴一下,如果直接使用 .class 那么因为被重写过,返回的还是原先对象的类对象,而直接用 runtime 方法的直接返回了 isa 指针。

Class object_getClass(id obj)
{
    if (obj) return obj->getIsa();
    else return Nil;
}

通过日志确实可以看到子类重写了对应属性的setter方法:

2020-03-25 23:11:00.607820+0800 02-25-KVO[28370:1005147] LOG:(NSKVONotifying_Teacher) INFO
2020-03-25 23:11:00.608190+0800 02-25-KVO[28370:1005147] ==== OUTPUT:NSKVONotifying_Teacher properties ====
2020-03-25 23:11:00.608529+0800 02-25-KVO[28370:1005147] ==== OUTPUT:NSKVONotifying_Teacher Method ====
2020-03-25 23:11:00.608876+0800 02-25-KVO[28370:1005147] method name:setWork:
2020-03-25 23:11:00.609219+0800 02-25-KVO[28370:1005147] method name:setName:
2020-03-25 23:11:00.646713+0800 02-25-KVO[28370:1005147] method name:setAge:
2020-03-25 23:11:00.646858+0800 02-25-KVO[28370:1005147] method name:class
2020-03-25 23:11:00.646971+0800 02-25-KVO[28370:1005147] method name:dealloc
2020-03-25 23:11:00.647088+0800 02-25-KVO[28370:1005147] method name:_isKVOA
2020-03-25 23:11:00.647207+0800 02-25-KVO[28370:1005147] =========================

疑惑点:看到有文章提出 KVO 之后,setXXX 方法转而调用 _NSSetBoolValueAndNotify、_NSSetCharValueAndNotify、_NSSetFloatValueAndNotify、_NSSetLongValueAndNotify 等方法,但是通过 runtime 打印 method 是存在的,猜测 SEL 是一样的,但是 IMP 被换掉了,关于源码的实现还未找到。TODO下。

2. 如何手动关闭kvo

KVO 和 KVC 相关接口太多,实际开发中直接查看接口文档即可。

+(BOOL)automaticallyNotifiesObserversForKey:(NSString *)key{
    if ([key isEqualToString:@"name"]) {
        return NO;
    }else{
        return [super automaticallyNotifiesObserversForKey:key];
    }
}

-(void)setName:(NSString *)name{
    
    if (_name!=name) {
        
        [self willChangeValueForKey:@"name"];
        _name=name;
        [self didChangeValueForKey:@"name"];
    }
      
}

3. 通过KVC修改属性会触发KVO么

会触发 KVO 操作,KVC 时候会先查询对应的 getter 和 setter 方法,如果都没找到,调用

+ (BOOL)accessInstanceVariablesDirectly {
    return NO;
}

如果返回 YES,那么可以直接修改实例变量。

  • KVC 调用 getter 流程:getKEY,KEY,isKEY, _KEY,接着是实例变量 _KEY,_isKEY, KEY, isKEY;

  • KVC 调用 setter 流程:setKEY_setKEY,实例变量顺序 _KEY,_isKEY, KEY, isKEY,没找到就调用 setValue: forUndefinedKey:

4. 哪些情况下使用kvo会崩溃,怎么防护崩溃

  1. dealloc 没有移除 kvo 观察者,解决方案:创建一个中间对象,将其作为某个属性的观察者,然后dealloc的时候去做移除观察者,而调用者是持有中间对象的,调用者释放了,中间对象也释放了,dealloc 也就移除观察者了;
  2. 多次重复移除同一个属性,移除了未注册的观察者
  3. 被观察者提前被释放,被观察者在 dealloc 时仍然注册着 KVO,导致崩溃。 例如:被观察者是局部变量的情况(iOS 10 及之前会崩溃) 比如 weak ;
  4. 添加了观察者,但未实现 observeValueForKeyPath:ofObject:change:context:方法,导致崩溃;
  5. 添加或者移除时 keypath == nil,导致崩溃;

以下解决方案出自 iOS 开发:『Crash 防护系统』(二)KVO 防护 一文。

解决方案一:

FBKVOController 对 KVO 机制进行了额外的一层封装,框架不但可以自动帮我们移除观察者,还提供了 block 或者 selector 的方式供我们进行观察处理。不可否认的是,FBKVOController 为我们的开发提供了很大的便利性。但是相对而言,这种方式对项目代码的侵入性比较大,必须依靠编码规范来强制约束团队人员使用这种方式。

解决方案二:

  1. 首先为 NSObject 建立一个分类,利用 Method Swizzling,实现自定义的 BMP_addObserver:forKeyPath:options:context:BMP_removeObserver:forKeyPath:BMP_removeObserver:forKeyPath:context:BMPKVO_dealloc方法,用来替换系统原生的添加移除观察者方法的实现。

  2. 然后在观察者和被观察者之间建立一个 KVODelegate 对象,两者之间通过 KVODelegate 对象 建立联系。然后在添加和移除操作时,将 KVO 的相关信息例如 observerkeyPathoptionscontext 保存为 KVOInfo 对象,并添加到 KVODelegate 对象 中对应 的 关系哈希表 中,对应原有的添加观察者。 关系哈希表的数据结构:{keypath : [KVOInfo 对象1, KVOInfo 对象2, ... ]}

  3. 在添加和移除操作的时候,利用 KVODelegate 对象 做转发,把真正的观察者变为 KVODelegate 对象,而当被观察者的特定属性发生了改变,再由 KVODelegate 对象 分发到原有的观察者上。

  4. 添加观察者时:通过关系哈希表判断是否重复添加,只添加一次。

  5. 移除观察者时:通过关系哈希表是否已经进行过移除操作,避免多次移除。

  6. 观察键值改变时:同样通过关系哈希表判断,将改变操作分发到原有的观察者上。

解决方案三:

XXShield 实现方案和 BayMax 系统类似。也是利用一个 Proxy 对象用来做转发, 真正的观察者是 Proxy,被观察者出现了通知信息,由 Proxy 做分发。不过不同点是 Proxy 里面保存的内容没有前者多。只保存了 _observed(被观察者) 和关系哈希表,这个关系哈希表中只维护了 keyPathobserver 的关系。

关系哈希表的数据结构:{keypath : [observer1, observer2 , ...](NSHashTable)}

XXShield 在 dealloc 中也做了类似将多余观察者移除掉的操作,是通过关系数据结构和 _observed ,然后调用原生移除观察者操作实现的。

5. kvo的优缺点

优点:

  1. 运用了设计模式:观察者模式
  2. 支持多个观察者观察同一属性,或者一个观察者监听不同属性
  3. 开发人员不需要实现属性值变化了发送通知的方案,系统已经封装好了,大大减少开发工作量;
  4. 能够对非我们创建的对象,即内部对象的状态改变作出响应,而且不需要改变内部对象(SDK对象)的实现;
  5. 能够提供观察的属性的最新值以及先前值;
  6. 用key paths来观察属性,因此也可以观察嵌套对象;
  7. 完成了对观察对象的抽象,因为不需要额外的代码来允许观察值能够被观察

缺点:

  1. 观察的属性键值硬编码(字符串),编译器不会出现警告以及检查;
  2. 由于允许对一个对象进行不同属性观察,所以在唯一回调方法中,会出现地狱式 if-else if - else 分支处理情况;

References:

Block

  1. block的内部实现,结构体是什么样的
  2. block是类吗,有哪些类型
  3. 一个int变量被 __block 修饰与否的区别?block的变量截获
  4. block在修改NSMutableArray,需不需要添加__block
  5. 怎么进行内存管理的
  6. block可以用strong修饰吗
  7. 解决循环引用时为什么要用__strong、__weak修饰
  8. block发生copy时机
  9. Block访问对象类型的auto变量时,在ARC和MRC下有什么区别

多线程

主要以GCD为主

  1. iOS开发中有多少类型的线程?分别对比
  2. GCD有哪些队列,默认提供哪些队列
  3. GCD有哪些方法api
  4. GCD主线程 & 主队列的关系
  5. 如何实现同步,有多少方式就说多少
  6. dispatch_once实现原理
  7. 什么情况下会死锁
  8. 有哪些类型的线程锁,分别介绍下作用和使用场景
  9. NSOperationQueue中的maxConcurrentOperationCount默认值
  10. NSTimer、CADisplayLink、dispatch_source_t 的优劣

视图&图像相关

  1. AutoLayout的原理,性能如何
  2. UIView & CALayer的区别
  3. 事件响应链
  4. drawrect & layoutsubviews调用时机
  5. UI的刷新原理
  6. 隐式动画 & 显示动画区别
  7. 什么是离屏渲染
  8. imageName & imageWithContentsOfFile区别
  9. 多个相同的图片,会重复加载吗
  10. 图片是什么时候解码的,如何优化
  11. 图片渲染怎么优化
  12. 如果GPU的刷新率超过了iOS屏幕60Hz刷新率是什么现象,怎么解决

性能优化

  1. 如何做启动优化,如何监控
  2. 如何做卡顿优化,如何监控
  3. 如何做耗电优化,如何监控
  4. 如何做网络优化,如何监控

开发证书

  1. 苹果使用证书的目的是什么
  2. AppStore安装app时的认证流程
  3. 开发者怎么在debug模式下把app安装到设备呢

架构设计

典型源码的学习

只是列出一些iOS比较核心的开源库,这些库包含了很多高质量的思想,源码学习的时候一定要关注每个框架解决的核心问题是什么,还有它们的优缺点,这样才能算真正理解和吸收

  1. AFN
  2. SDWebImage
  3. JSPatch、Aspects(虽然一个不可用、另一个不维护,但是这两个库都很精炼巧妙,很适合学习)
  4. Weex/RN, 笔者认为这种前端和客户端紧密联系的库是必须要知道其原理的
  5. CTMediator、其他router库,这些都是常见的路由库,开发中基本上都会用到
  6. 圈友们在评论下面补充吧

架构设计

  1. 手动埋点、自动化埋点、可视化埋点
  2. MVC、MVP、MVVM设计模式
  3. 常见的设计模式
  4. 单例的弊端
  5. 常见的路由方案,以及优缺点对比
  6. 如果保证项目的稳定性
  7. 设计一个图片缓存框架(LRU)
  8. 如何设计一个git diff
  9. 设计一个线程池?画出你的架构图
  10. 你的app架构是什么,有什么优缺点、为什么这么做、怎么改进

其他问题

  1. PerformSelector & NSInvocation优劣对比
  2. oc怎么实现多继承?怎么面向切面(可以参考Aspects深度解析-iOS面向切面编程
  3. 哪些bug会导致崩溃,如何防护崩溃
  4. 怎么监控崩溃
  5. app的启动过程(考察LLVM编译过程、静态链接、动态链接、runtime初始化)
  6. 沙盒目录的每个文件夹划分的作用
  7. 简述下match-o文件结构

系统基础知识

  1. 进程和线程的区别
  2. HTTPS的握手过程
  3. 什么是中间人攻击?怎么预防
  4. TCP的握手过程?为什么进行三次握手,四次挥手
  5. 堆和栈区的区别?谁的占用内存空间大
  6. 加密算法:对称加密算法和非对称加密算法区别
  7. 常见的对称加密和非对称加密算法有哪些
  8. MD5、Sha1、Sha256区别
  9. charles抓包过程?不使用charles4G网络如何抓包

数据结构与算法

对于移动开发者来说,一般不会遇到非常难的算法,大多以数据结构为主,笔者列出一些必会的算法,当然有时间了可以去LeetCode上刷刷题

  1. 八大排序算法
  2. 栈&队列
  3. 字符串处理
  4. 链表
  5. 二叉树相关操作
  6. 深搜广搜
  7. 基本的动态规划题、贪心算法、二分查找
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,347评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,435评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,509评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,611评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,837评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,987评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,730评论 0 267
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,194评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,525评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,664评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,334评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,944评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,764评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,997评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,389评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,554评论 2 349

推荐阅读更多精彩内容

  • 1.设计模式是什么? 你知道哪些设计模式,并简要叙述? 设计模式是一种编码经验,就是用比较成熟的逻辑去处理某一种类...
    司马DE晴空阅读 1,281评论 0 7
  • 面向对象的三大特性:封装、继承、多态 OC内存管理 _strong 引用计数器来控制对象的生命周期。 _weak...
    运气不够技术凑阅读 1,092评论 0 10
  • 图文/风_逸轩 我们总是会有很多的自以为:自以为自己很帅很酷,自以为别人总在看自己,自以为自己很重要……...
    桃木梓阅读 359评论 0 6
  • 还是会想起你,但是想起来更多的是感谢。感谢你给到我的所有的。让我知道对我来讲,最珍贵的是什么?让我清楚我的价值观是...
    陆宁阅读 155评论 0 0
  • ·做饭的哲学 想象下,如果你想做一顿秀色可餐的丰盛晚餐,这之前的食材准备工作是不是着实让你觉得比做菜辛苦很多。但是...
    Demi仔阅读 1,247评论 0 3