使用objc runtime实现iOS懒加载
使用objc runtime实现懒加载
懒加载形式如下
- (id)lazyloadproperty{ if(_lazyloadproperty == nil){ _lazyloadproperty = [xclass ...]; } return _lazyloadproperty; }
一般使用宏定义可以轻松完成。但是没有一致性,移植差。
利用objc runtime的动态性实现懒加载可以实现即可增加又可删除功能,也可以避免污染类型。该三方弥补了目前没有闭环实现懒加载三方的空缺。
主要流程:
- 实例或者类的懒加载
- 如果是实例对象则钩住并修改类型将其子类化
- 对该类型进行method swizzling
- 如果现在进行解绑,则判断是否是自己实现的方法.如果是自己实现的方法->5,否则->6
- 调用method swizzling还原
- 删除这个类型的这个方法
难点:
自己实现method swizzling
- 重新实现objc1时代的方法class_removemethods
- 钩住运行时中的runtimelock,实现修改类型数据时的安全性
我们再实现method swizzling时的两个api
objc_export imp _nullable class_replacemethod(class _nullable cls, sel _nonnull name, imp _nonnull imp, const char * _nullable types) objc_available(10.5, 2.0, 9.0, 1.0, 2.0); objc_export void method_exchangeimplementations(method _nonnull m1, method _nonnull m2) objc_available(10.5, 2.0, 9.0, 1.0, 2.0);
不管使用哪种,如果这个类型没有实现该方法而是父类实现的话,就需要动态增加一个方法。动态增加的方法在objc1时代,是可以通过下列方法删除的:
objc_export void class_removemethods(class _nullable, struct objc_method_list * _nonnull) objc2_unavailable;
objc2时代之后runtime被重写后没有该方法了,并且新的runtime的类结构看起来就没打算让开发者删除方法,所以这里将过程记下。
首先看类读写器的结构class_rw_t
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 };
method_array_t继承于list_array_tt<method_t, method_list_t>,它是数组结构。存储的内容是method_list_t.
method_list_t又继承于entsize_list_tt<method_t, method_list_t, 0x3>,他也是数组结构。
整个method_array_t结构是二维数组。每次删掉一个method_t需要用新method_list_t替换原对象。
然后是线程安全的问题,需要获取到苹果在操作类型的时候使用的读写锁(pthread_rw_lock_t runtimelock)。没有这把锁任何对runtime的修改都是不可靠的。
最终采取的方式是:劫持暴露了符号的系统函数然后阻塞线程
劫持系统c函数使用的是脸书的鱼钩,这个钩子在macos其实也是可以正常工作的。
剩下的就是寻找合适的函数了,这函数要满足两个条件:
- 该函数在符号表中存在
- 函数内部在lock runtimelock之后存在满足条件1的第二个函数
找了半天发现最合适的只有objc_allocateprotocol()了,objc_allocateprotocol内部会调用calloc(),所以第二个被劫持函数就是calloc。为了减小calloc的开销,需要稍微做一些工作。
- 对每次调用进行比较线程id的操作显然比暴力阻塞线程好。
- 减小劫持后的calloc的调用栈。
虽然不是什么吸引人的ui框架还是希望大家点个赞吧。另外,有成都的公司招ios吗