runtime相关问题
- 面试题出自掘金的一篇文章《阿里、字节:一套高效的iOS面试题》
- 该面试题解答github 地址版本目前已经完结,可自行下载pdf进行阅读,仅做参考,对于有问题的解答可提 issue,欢迎 star fork。
- 调试好可运行的源码 objc-runtime,官网找 objc4;
- 欢迎转载,转载请注明出处:pmst-swiftgg
结构模型
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_t
的 properties
,先后输出了 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_t
和 class_ro_t
的区别
image
测试发现,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. IMP
、SEL
、Method
的区别和使用场景
三者的定义:
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 |
b num |
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. load
、initialize
方法的区别什么?在继承关系中他们有什么区别
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
关键字修饰的对象有两种情况:栈上和堆上。上图主要解释 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用法:
- 为Class添加私有成员:例如在AFNetworking中,在UIImageView里添加了imageRequestOperation对象,从而保证了异步加载图片。
- 为Class添加共有成员:例如在FDTemplateLayoutCell中,使用Associated Objects来缓存每个cell的高度(代码片段1、代码片段2)。通过分配不同的key,在复用cell的时候即时取出,增加效率。
- 创建KVO对象:建议使用category来创建关联对象作为观察者。可以参考Objective-C 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
下哪些情况会造成内存泄漏
其他
-
Method Swizzle
注意事项 - 属性修饰符
atomic
的内部实现是怎么样的?能保证线程安全吗 - iOS 中内省的几个方法有哪些?内部实现原理是什么
-
class、objc_getClass、object_getclass
方法有什么区别?
NSNotification相关
认真研读、你可以在这里找到答案轻松过面:一文全解iOS通知机制(经典收藏)
- 实现原理(结构设计、通知如何存储的、
name&observer&SEL
之间的关系等) - 通知的发送时同步的,还是异步的
-
NSNotificationCenter
接受消息和发送消息是在一个线程里吗?如何异步发送消息 -
NSNotificationQueue
是异步还是同步发送?在哪个线程响应 -
NSNotificationQueue
和runloop
的关系 - 如何保证通知接收的线程在主线程
- 页面销毁时不移除通知会崩溃吗
- 多次添加同一个通知会是什么结果?多次移除通知呢
- 下面的方式能接收到通知吗?为什么
// 发送通知
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(handleNotification:) name:@"TestNotification" object:@1];
// 接收通知
[NSNotificationCenter.defaultCenter postNotificationName:@"TestNotification" object:nil];
复制代码
Runloop & KVO
runloop
runloop
对于一个标准的iOS开发来说都不陌生,应该说熟悉runloop
是标配,下面就随便列几个典型问题吧
- app如何接收到触摸事件的
- 为什么只有主线程的
runloop
是开启的 - 为什么只在主线程刷新UI
-
PerformSelector
和runloop
的关系 - 如何使线程保活
KVO(Finished)
同runloop
一样,这也是标配的知识点了,同样列出几个典型问题
1. 实现原理
KVO 会为需要observed的对象动态创建一个子类,以NSKVONotifying_
最为前缀,然后将对象的 isa 指针指向新的子类,同时重写 class 方法,返回原先类对象,这样外部就无感知了;其次重写所有要观察属性的setter方法,统一会走一个方法,然后内部是会调用 willChangeValueForKey
和 didChangevlueForKey
方法,在一个被观察属性发生改变之前, willChangeValueForKey:
一定会被调用,这就 会记录旧的值。而当改变发生后,didChangeValueForKey:
会被调用,继而 observeValueForKey:ofObject:change:context:
也会被调用。
那么如何验证上面的说法呢?很简单,借助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会崩溃,怎么防护崩溃
- dealloc 没有移除 kvo 观察者,解决方案:创建一个中间对象,将其作为某个属性的观察者,然后dealloc的时候去做移除观察者,而调用者是持有中间对象的,调用者释放了,中间对象也释放了,dealloc 也就移除观察者了;
- 多次重复移除同一个属性,移除了未注册的观察者
- 被观察者提前被释放,被观察者在 dealloc 时仍然注册着 KVO,导致崩溃。 例如:被观察者是局部变量的情况(iOS 10 及之前会崩溃) 比如 weak ;
- 添加了观察者,但未实现
observeValueForKeyPath:ofObject:change:context:
方法,导致崩溃; - 添加或者移除时
keypath == nil
,导致崩溃;
以下解决方案出自 iOS 开发:『Crash 防护系统』(二)KVO 防护 一文。
解决方案一:
FBKVOController 对 KVO 机制进行了额外的一层封装,框架不但可以自动帮我们移除观察者,还提供了 block 或者 selector 的方式供我们进行观察处理。不可否认的是,FBKVOController 为我们的开发提供了很大的便利性。但是相对而言,这种方式对项目代码的侵入性比较大,必须依靠编码规范来强制约束团队人员使用这种方式。
解决方案二:
-
首先为 NSObject 建立一个分类,利用 Method Swizzling,实现自定义的
BMP_addObserver:forKeyPath:options:context:
、BMP_removeObserver:forKeyPath:
、BMP_removeObserver:forKeyPath:context:
、BMPKVO_dealloc
方法,用来替换系统原生的添加移除观察者方法的实现。 -
然后在观察者和被观察者之间建立一个
KVODelegate 对象
,两者之间通过KVODelegate 对象
建立联系。然后在添加和移除操作时,将 KVO 的相关信息例如observer
、keyPath
、options
、context
保存为KVOInfo 对象
,并添加到KVODelegate 对象
中对应 的关系哈希表
中,对应原有的添加观察者。 关系哈希表的数据结构:{keypath : [KVOInfo 对象1, KVOInfo 对象2, ... ]}
-
在添加和移除操作的时候,利用
KVODelegate 对象
做转发,把真正的观察者变为KVODelegate 对象
,而当被观察者的特定属性发生了改变,再由KVODelegate 对象
分发到原有的观察者上。 -
添加观察者时:通过关系哈希表判断是否重复添加,只添加一次。
-
移除观察者时:通过关系哈希表是否已经进行过移除操作,避免多次移除。
-
观察键值改变时:同样通过关系哈希表判断,将改变操作分发到原有的观察者上。
解决方案三:
XXShield 实现方案和 BayMax 系统类似。也是利用一个 Proxy 对象用来做转发, 真正的观察者是 Proxy,被观察者出现了通知信息,由 Proxy 做分发。不过不同点是 Proxy 里面保存的内容没有前者多。只保存了 _observed(被观察者)
和关系哈希表,这个关系哈希表中只维护了 keyPath
和 observer
的关系。
关系哈希表的数据结构:{keypath : [observer1, observer2 , ...](NSHashTable)}
。
XXShield 在 dealloc 中也做了类似将多余观察者移除掉的操作,是通过关系数据结构和 _observed
,然后调用原生移除观察者操作实现的。
5. kvo的优缺点
优点:
- 运用了设计模式:观察者模式
- 支持多个观察者观察同一属性,或者一个观察者监听不同属性。
- 开发人员不需要实现属性值变化了发送通知的方案,系统已经封装好了,大大减少开发工作量;
- 能够对非我们创建的对象,即内部对象的状态改变作出响应,而且不需要改变内部对象(SDK对象)的实现;
- 能够提供观察的属性的最新值以及先前值;
- 用key paths来观察属性,因此也可以观察嵌套对象;
- 完成了对观察对象的抽象,因为不需要额外的代码来允许观察值能够被观察
缺点:
- 观察的属性键值硬编码(字符串),编译器不会出现警告以及检查;
- 由于允许对一个对象进行不同属性观察,所以在唯一回调方法中,会出现地狱式
if-else if - else
分支处理情况;
References:
Block
-
block
的内部实现,结构体是什么样的 - block是类吗,有哪些类型
- 一个
int
变量被__block
修饰与否的区别?block的变量截获 -
block
在修改NSMutableArray
,需不需要添加__block
- 怎么进行内存管理的
-
block
可以用strong
修饰吗 - 解决循环引用时为什么要用
__strong、__weak
修饰 -
block
发生copy
时机 -
Block
访问对象类型的auto变量
时,在ARC和MRC
下有什么区别
多线程
主要以GCD为主
-
iOS
开发中有多少类型的线程?分别对比 -
GCD
有哪些队列,默认提供哪些队列 -
GCD
有哪些方法api -
GCD
主线程 & 主队列的关系 - 如何实现同步,有多少方式就说多少
-
dispatch_once
实现原理 - 什么情况下会死锁
- 有哪些类型的线程锁,分别介绍下作用和使用场景
-
NSOperationQueue
中的maxConcurrentOperationCount
默认值 -
NSTimer、CADisplayLink、dispatch_source_t
的优劣
视图&图像相关
-
AutoLayout
的原理,性能如何 -
UIView & CALayer
的区别 - 事件响应链
-
drawrect & layoutsubviews
调用时机 - UI的刷新原理
- 隐式动画 & 显示动画区别
- 什么是离屏渲染
- imageName & imageWithContentsOfFile区别
- 多个相同的图片,会重复加载吗
- 图片是什么时候解码的,如何优化
- 图片渲染怎么优化
- 如果GPU的刷新率超过了iOS屏幕60Hz刷新率是什么现象,怎么解决
性能优化
- 如何做启动优化,如何监控
- 如何做卡顿优化,如何监控
- 如何做耗电优化,如何监控
- 如何做网络优化,如何监控
开发证书
- 苹果使用证书的目的是什么
- AppStore安装app时的认证流程
- 开发者怎么在debug模式下把app安装到设备呢
架构设计
典型源码的学习
只是列出一些iOS比较核心的开源库,这些库包含了很多高质量的思想,源码学习的时候一定要关注每个框架解决的核心问题是什么,还有它们的优缺点,这样才能算真正理解和吸收
- AFN
- SDWebImage
- JSPatch、Aspects(虽然一个不可用、另一个不维护,但是这两个库都很精炼巧妙,很适合学习)
- Weex/RN, 笔者认为这种前端和客户端紧密联系的库是必须要知道其原理的
- CTMediator、其他router库,这些都是常见的路由库,开发中基本上都会用到
- 请
圈友
们在评论下面补充吧
架构设计
- 手动埋点、自动化埋点、可视化埋点
-
MVC、MVP、MVVM
设计模式 - 常见的设计模式
- 单例的弊端
- 常见的路由方案,以及优缺点对比
- 如果保证项目的稳定性
- 设计一个图片缓存框架(LRU)
- 如何设计一个
git diff
- 设计一个线程池?画出你的架构图
- 你的app架构是什么,有什么优缺点、为什么这么做、怎么改进
其他问题
-
PerformSelector & NSInvocation
优劣对比 -
oc
怎么实现多继承?怎么面向切面(可以参考Aspects深度解析-iOS面向切面编程) - 哪些
bug
会导致崩溃,如何防护崩溃 - 怎么监控崩溃
-
app
的启动过程(考察LLVM编译过程、静态链接、动态链接、runtime初始化) - 沙盒目录的每个文件夹划分的作用
- 简述下
match-o
文件结构
系统基础知识
- 进程和线程的区别
-
HTTPS
的握手过程 - 什么是
中间人攻击
?怎么预防 -
TCP
的握手过程?为什么进行三次握手,四次挥手 -
堆和栈
区的区别?谁的占用内存空间大 - 加密算法:
对称加密算法和非对称加密算法
区别 - 常见的
对称加密和非对称加密
算法有哪些 -
MD5、Sha1、Sha256
区别 -
charles
抓包过程?不使用charles
,4G
网络如何抓包
数据结构与算法
对于移动开发者来说,一般不会遇到非常难的算法,大多以数据结构为主,笔者列出一些必会的算法,当然有时间了可以去LeetCode上刷刷题
- 八大排序算法
- 栈&队列
- 字符串处理
- 链表
- 二叉树相关操作
- 深搜广搜
- 基本的动态规划题、贪心算法、二分查找
作者:NinthDay
链接:https://www.jianshu.com/p/c1765a6305ab
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
网友评论