一、UI方面
1. UI卡顿问题
- 原因
- 屏幕垂直信号之间是一帧率,16.7ms
- CPU计算,GPU渲染,这两步要在一帧的时间完成。
- 如果没完成,就会出现卡顿,掉帧情况
- 优化方案
- CPU层面:
- 尽量用更加轻量级的对象,比如不需要处理事件的视图,可以用CALayer代替UIView
- 图片的解码,可以在子线程用CGBitmapContext绘制,然后从Bitmap中创建图片
- 尽量不要对UIView频繁调用属性修改,frame,bounds,transform等修改
- 尽量提前计算好布局,在有需要的时候一次性调整对应的属性
- Autolayout会比直接设置frame消耗更多的CPU资源,所以尽量直接设置frame
- 图片的size最好刚好跟UIImageView的size保持一致
- 控制线程的最大并发数量
- 对象创建、及时销毁
- 文本等预排版(boudingRectWithSize && drawWithRect 这两个方法)
- GPU层面:
- 避免离屏渲染(避免设置圆角带来离屏渲染:贝塞尔曲线绘制)
- 减少视图层级(Texture/ASDK 就是通过pre-composing技术,提前把多个sub-layer合成渲染为一张图片,减少视图层级,大大提高渲染效率)
2. 聊聊WebView?
- 使用
-
- 设置uiDelegate和navigationDelegate
-
- 设置config
- 其中config里面,设置userContentController的时候,注意添加JS脚本监听的时候,防止循环引用
- 通过创建中间类弱引用,让WKScripMessageHandler类设置为弱类型。
-
- 实现代理事件
- uiDelegate: 处理JS脚本,确认框,警告等
- navigationDelegate: 处理跳转,加载页面等
- decisionHandler方法一定要实现,否则点击跳转链接就会崩溃
3. 事件响应链是如何传递的?
事件传递 & 事件响应
- 事件传递: 从UIApplication到UIWindow,再顺着子视图往下找,根据两个方法
- pointInSide: withEvent
- hitTest: withEvent
- 事件响应
- 从传递最后确认的视图开始,验证是否能处理响应事件,如果不能就顺着视图往上找父视图,如果可以处理,就处理了,和事件传递大致相反,根据判断方法- touchesBegan: withEvent
- touchesMoved: withEvent
4. layoutsubviews是在什么时机调用的?
- init初始化是不会触发
- addSubview会触发
- 设置frame且前后值发生变化,frame为zero且不添加到指定视图,不会触发
- 旋转screen会触发父视图的layoutSubviews
- 滚动UIScrollView引起View重新布局时候会触发layoutSubviews
5. sizeThatFits 和 sizeToFit的区别
- UIView如果设置过autolayout约束,则该sizeToFit方法失效
- 调用sizeToFit会自动调用sizeThatFits
- 自定义View的时候,不应该重写sizeToFit方法,应该重写sizeThatFits,在合适的地方只需要调用sizeToFit方法,就会自动触发sizeThatFits方法
- sizeToFit可以改变UIView的frame,sizeThatFit不会改变UIView的frame
- 它们都没有递归,不管subviews,只管自己
- 参考链接
二、网络方面
- 网络请求缓存问题?
- 空间:URLCache是苹果提供的网络请求缓存类,主要用于GET方法,请求资源用的。默认内存是512K,磁盘10M,也可以自己修改
- 策略:6种,使用缓存,不使用缓存,实现,不实现等等。
- 更新缓存内容:
Last-Modified
:服务器会在资源后面有个标记Last-Modified
,表示最后修改时间。第一次请求会缓存这个时间,后面请求时候,发送一个If-Modified-Since
报头。如果返回304
就不会传输资源数据,用本地缓存的即可。否则会传输资源。Etag
:服务器对资源实体用Etag
来标记,就是对实体进行散列计算,得到唯一值。第二次请求,对这个值进行比较。如果返回304
就数据为空,和上述情况一样。
三、安全方面
1. Mach-O
-
- Mach Object的缩写,是mac及iOS上可执行文件的格式,不一定是可执行,只是一种文件格式。
- 包含类型:
-
- OBJECT:
.o
或.a
文件(目标文件)
- OBJECT:
-
- EXECUTE:指的是IPA拆包后的文件(可执行文件)
-
- DYLIB:指的是
.dylib
或.framework
(动态库文件)
- DYLIB:指的是
-
- DYLINKER:指的是动态连接器(动态库连接器文件)
-
- DSYM:(符号表),指的是有保存符号信息用于分析闪退信息的文件(符号表文件)
- 加载过程
-
- 把可执行文件加载到内存中
-
- 从可执行文件中分析
dyld
的路径
- 从可执行文件中分析
-
- 把
dyld
加载到内存中
- 把
-
dyld
递归加载所有的动态连接库dylib
2. ldid重签名
-
-
- 用
ldid -e
命令导出可执行文件的签名文件entitlements
- 用
-
- 用越狱了的手机,导出
SpringBoard
的签名文件entitlements
- 用越狱了的手机,导出
-
- 把
SpringBoard
的签名文件覆盖自己的APP的签名文件entitlements
- 把
-
3. 怎么防止应用crash?不用bugly记录crash?
四、底层原理
1. OC为什么要设计Metaclass?
-
- 这个是要从面向对象设计的哲学去考虑这个问题
- 第一:提取出某一种群体的特性,对这类群体进行划分,从而有基本的
属性成员信息
、方法信息
第二:可以复用消息传递
,在OC的消息传递过程中,只要是这个群体的实体,就不需要关心自身的类型是什么,只需要关心这个接口。在传递消息的时候就可以复用了。
第三:对于描述这个类的类,即元类,对于类的类方法而言,就类似实例的实例方法,也需要这么一个复用消息传递机制
,所以也就产生了针对类的元类,本质上来说,我认为也是消息传递的复用工具
2. 类可以调用对象方法吗?
-
- 可以,因为基类的super-class指针,指向的是类。
3. isa的指针指向?
-
-
- 实例对象的isa指向类对象,类对象的isa指向元类
-
- isa指向,在不同平台(arm64 或 x86)通过掩码计算,来得到真实的地址值。
-
4. KVO? 键值监听
-
-
- 使用:
[self.person addObserver:self forKeyPath:@"age" options:options context:nil];
- 使用:
-
- 本质:
第一:NSKVONotifying_Person
继承Person
类
第二:在set方法里,增加了willChange
和didChange
方法
第三:联想到在swift 里,我们可以写属性监听器
第四:从runtime的角度也可以验证,通过调用methodForSelector
方法,查看实际上调用的方法是什么
第五:从runtime调用class_copyMethodList
方法,也可以获取添加监听后的类的所有的方法列表,打印就会发现与添加之前不一样了。
第六:从runtime调用object_getClass
获取类名,打印也会发现与添加之前不一样
- 本质:
-
- 手动触发KVO?
第一:只需要手动在合适的地方添加willChange
和didChange
方法
第二:通过-> 方式赋值,不会调用set方法,不会触发KVO
- 手动触发KVO?
-
5. KVC 键值编码
-
-
- 使用
[self.person setValue:@10 forKey:@"age"];
[self.person setValue:@20 forKeyPath:@"cat.weight"];
- 使用
-
- 原理
第一:赋值
setKey
_setKey
_key
_isKey
key
isKey
第二:取值
getKey
Key
isKey
_key
- 原理
-
- 所以,KVC是可以触发KVO的,因为会调用set方法
-
6. Category的理解?
-
分类的使用场景:一般业务比较复杂,需要将一部分功能或业务逻辑分模块出来,就可以用分类
-
Category的本质
- 通过runtime加载某个类的所有Category数据
- 把所有的Category的方法、属性、协议,的数据,合并到一个大数组中
- 后编译的Category数据,会在数组的前面,所以后编译的Category会被先调用
- 如果分类中含有和原类的类方法同名的,就会先调用分类的方法
- 通过runtime关联属性
objc_setAssociatedObject
objc_getAssociatedObject
- 关联对象并不是存储在被关联的对象中,而是存储在全局统一的AssociationsManager中
- 设置关联对象为nil,就是相当于移除关联对象
-
Category和Extension的区别(OC里)
- 区别一
- extension在编译期决议,它是类的一部分,在编译期和头文件里的@interface以及实现文件里的@implement一起形成一个完整的类,它伴随类的产生而产生,亦随之一起消亡。
- extension一般用来隐藏类的私有信息,你必须有一个类的源码才能为一个类添加extension,所以你无法为系统的类比如NSString添加extension。
- 区别二
- 但是category则完全不一样,它是在运行期决议的。 就category和extension的区别来看,我们可以推导出一个明显的事实,extension可以添加实例变量,而category是无法添加实例变量的(因为在运行期,对象的内存布局已经确定,如果添加实例变量就会破坏类的内部布局,这对编译型语言来说是灾难性的)。
- 区别三
- 会在APP冷启动第二阶段调用,category附加到类的工作会先于+load方法的执行。
- Runtime给Category动态添加方法、属性
- 关联对象都由AssociationsManager管理。AssociationsManager里面是由一个静态AssociationsHashMap来存储所有的关联对象的。
- 而map的的key是这个对象的指针地址(任意两个不同对象的指针地址一定是不同的),而这个map的value又是另外一个AssociationsHashMap,里面保存了关联对象的kv对。
- runtime的销毁对象函数objc_destructInstance里面会判断这个对象有没有关联对象,如果有,会调用_object_remove_assocations做关联对象的清理工作
- 调用被覆盖的方法?
- 通过class_copyMethodList,把所有的方法列表获取到。
- 然后for循环,把最后一个方法的名字进行匹配。
Class currentClass = [TestClass class];
TestClass *my = [[TestClass alloc] init];
if (currentClass) {
unsigned int methodCount;
Method *methodList = class_copyMethodList(currentClass, &methodCount);
IMP lastImp = NULL;
SEL lastSel = NULL;
for (NSInteger i = 0; i < methodCount; i++) {
Method method = methodList[i];
NSString *methodName = [NSString stringWithCString:sel_getName(method_getName(method))
encoding:NSUTF8StringEncoding];
if ([@"printName" isEqualToString:methodName]) {
lastImp = method_getImplementation(method);
lastSel = method_getName(method);
}
}
typedef void (*fn)(id,SEL);
if (lastImp != NULL) {
fn f = (fn)lastImp;
f(my, lastSel);
}
free(methodList);
}
- class的结构
在oc中打开objc.h
typedef struct objc_class *Class; //Class是指向结构体objc_class的指针
struct objc_class {
Class _Nonnull isa OBJC_ISA_AVAILABILITY; //isa,代表的是该类类对象
#if !__OBJC2__
Class _Nullable super_class OBJC2_UNAVAILABLE; //父类
const char * _Nonnull name OBJC2_UNAVAILABLE; //类名
long version OBJC2_UNAVAILABLE;
long info OBJC2_UNAVAILABLE;
long instance_size OBJC2_UNAVAILABLE; //对象大小
struct objc_ivar_list * _Nullable ivars OBJC2_UNAVAILABLE; //成员变量列表
struct objc_method_list * _Nullable * _Nullable methodLists OBJC2_UNAVAILABLE; //实例方法列表
struct objc_cache * _Nonnull cache OBJC2_UNAVAILABLE; //方法缓存列表(是个hash表),用来消息发送时候,快速查找方法
struct objc_protocol_list * _Nullable protocols OBJC2_UNAVAILABLE; //类实现协议列表
#endif
} OBJC2_UNAVAILABLE;
/* Use `Class` instead of `struct objc_class *` */
7. load、initialize方法
-
- 调用顺序
- load
- 先调用类的load(先编译的先调用),再调用分类的load(也是先编译的先调用)。
- 先调用父类,再调用子类。
- initialize
- 先看父类有没有实现,再调用子类。
- +initialize 方法的调用与普通方法的调用是一样的,走的都是消息发送的流程。
- 如果子类没有实现 +initialize 方法,那么继承自父类的实现会被调用;
- 如果一个类的分类实现了 +initialize 方法,那么就会对这个类中的实现造成覆盖。
- 调用方式
- load是在系统加载的时候,根据函数地址直接调用的
- initialize是通过消息发送调用
- 调用时间
- load是runtime加载类、分类的时候调用,只会调用一次(在APP冷启动的第二阶段就会调用)
- initialize是类在第一次接收到消息的时候调用,每个类只会initialize一次。但是父类的initialize方法可能会被调用多次。
// JHPerson 和 JHTeacher 都是 Person 的子类,并且只有Person这个父类实现了+initialize方法
- (void)testInit {
NSLog(@"--------");
[JHPerson alloc];
[JHPerson alloc];
[JHTeacher alloc];
[JHTeacher alloc];
}
// 伪代码逻辑
if (JHPerson没有初始化) {
if (JHPerson的父类Person没有初始化) {
objc_msgSend([Person class], @selector(initialize)); // 第一次调用父类
}
objc_msgSend([JHPerson class],@selector(initialize)); // 调用子类,子类没实现,去找到父类调用,第二次调用父类
}
if (JHTeacher没有初始化) {
if (JHTeacher的父类Person没有初始化) { // 父类已经初始化了,不会进来
objc_msgSend([Person class], @selector(initialize));
}
objc_msgSend([JHTeacher class],@selector(initialize)); // 调用子类,子类没实现,去找到父类调用,第三次调用父类
}
8. 聊聊block
-
- block的本质是一个OC对象
NSGloabalBlock --> NSBlock --> NSObject
- block的本质是一个OC对象
-
- block类型问题
- GloabalBlock – 没有访问auto变量 – 程序的数据区域
- NSStackBlock – 访问了auto变量 – 栈里面
- NSMallocBlock – NSStackBlock复制 – 堆里面
- NSMallockBlock复制,引用计数+1
-
- 变量捕获
-
- 局部变量会被捕获,全局变量不会被捕获
-
- static修饰的或者是__block修饰的,是指针传递
-
- 默认没有修饰,(即auto)是值传递
-
- 下划线_block修饰后的对象,是一个结构体
struct __Block_byref_age_0 { void *__isa; __Block_byref_age_0 *__forwarding; // 这个指针指向自己 int __flags; int __size; int age; };
- forwarding为什么指向自己?如图,保证当从栈复制到堆时候,也能正确指向属性的指针地址
-
- 循环引用
-
- ARC下
- 用__weak一般是最佳方案,因为安全,对象销毁指针指向nil
- 用_unsafe_unretain,不安全,对象销毁,指针地址不变
- __block 方案,个人取个名字叫
过河拆桥法
,方便记忆。 -
- 首先__block修饰后,变为一个结构体。
-
- 结构体里面有
强指针
指向实例对象
,__block
对实例对象
产生了强引用
- 结构体里面有
-
实例对象
调用block对象
,实例对象
对block
产生了强引用
-
block
再访问了__block对象
的内容,block
对__block
产生了强引用
,如图:
// 1. __block修饰的那部分:__block Person *person = [[Person alloc] init];
struct __Block_byref_person_0 {
void *__isa;
__Block_byref_person_0 *__forwarding;
int __flags;
int __size;
void (*__Block_byref_id_object_copy)(void*, void*);
void (*__Block_byref_id_object_dispose)(void*);
Person *__strong person; // 后面使用的person指针,都是这个指针
};
- 5. 现在我要过河拆桥
,我调用block的时候,通过__block访问到了我想要访问的实例对象的属性(比如,这里我的目的就是访问person.age),那么我的目的已经完成了,所以,我不再需要让__block对象再去强引用实例对象了。
// 1. __block修饰的那部分:__block Person *person = [[Person alloc] init];
struct __Block_byref_person_0 {
void *__isa;
__Block_byref_person_0 *__forwarding;
int __flags;
int __size;
void (*__Block_byref_id_object_copy)(void*, void*);
void (*__Block_byref_id_object_dispose)(void*);
Person *__strong person = nil; // 在这里来过河拆桥,把它变为nil
};
9. 聊聊Runloop
10. 聊聊Runtime
11. 聊聊锁
- 自旋锁、互斥锁比较
- 简单总结:
- 单核的、复杂的操作,用互斥锁
- 多核的、简单的操作,用自旋锁
- 自旋锁:
- 是一种用于保护多线程共享资源的锁,与一般互斥锁(mutex)不同之处在于当自旋锁尝试获取锁时以忙等待(busy waiting)的形式不断地循环检查锁是否可用。当上一个线程的任务没有执行完毕的时候(被锁住),那么下一个线程会一直等待(不会睡眠),当上一个线程的任务执行完毕,下一个线程会立即执行。
在多 CPU 的环境中,对持有锁较短的进程来说,使用自旋锁代替一般的互斥锁往往能够提高进程的性能。
- 是一种用于保护多线程共享资源的锁,与一般互斥锁(mutex)不同之处在于当自旋锁尝试获取锁时以忙等待(busy waiting)的形式不断地循环检查锁是否可用。当上一个线程的任务没有执行完毕的时候(被锁住),那么下一个线程会一直等待(不会睡眠),当上一个线程的任务执行完毕,下一个线程会立即执行。
- 互斥锁:
- 当上一个线程的任务没有执行完毕的时候(被锁住),那么下一个线程会进入睡眠状态等待任务执行完毕,当上一个线程的任务执行完毕,下一个线程会自动唤醒然后执行任务。
- @synchronized 的原理
- 第一步
@synchronized(obj) {
// do work
}
转化成这样的东东:
@try {
objc_sync_enter(obj);
// do work
} @finally {
objc_sync_exit(obj);
}
- 第二步:objc_sync_enter 和 objc_sync_exit 是什么鬼?它们是如何实现的?
// Begin synchronizing on 'obj'.
// Allocates recursive mutex associated with 'obj' if needed.
// Returns OBJC_SYNC_SUCCESS once lock is acquired.
// 开始在obj上执行同步操作, 懒加载生成一个递归锁关联obj, 返回OBJC_SYNC_SUCCESS
int objc_sync_enter(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
// 查找这个obj是否已经生成SyncData,如果没有生成一个
SyncData* data = id2data(obj, ACQUIRE);
assert(data);
data->mutex.lock(); // 调用SyncData的递归锁加锁
} else {
// @synchronized(nil) does nothing
// 如果传入nil, 打印了一个log,然后什么都不做
if (DebugNilSync) {
_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
}
objc_sync_nil();
}
return result;
}
// End synchronizing on 'obj'.
// Returns OBJC_SYNC_SUCCESS or OBJC_SYNC_NOT_OWNING_THREAD_ERROR
// 结束在obj上的同步操作,
int objc_sync_exit(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
//还是找到这个对象所在的结构体SyncData
SyncData* data = id2data(obj, RELEASE);
if (!data) {
// 如果这个结构体在block执行过程中找不到了,会返回error
result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
} else {
// 尝试解锁,解锁失败也会返回error
bool okay = data->mutex.tryUnlock();
if (!okay) {
result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
}
}
} else {
// @synchronized(nil) does nothing
// 如果这个对象在block执行过程中变成nil了,会什么都不做
}
return result;
}
- 第三步:
data->mutex.lock(); // 调用SyncData的递归锁加锁
怎么调?
typedef struct SyncData {
id object;
recursive_mutex_t mutex;
struct SyncData* nextData;
int threadCount;
} SyncData;
typedef struct SyncList {
SyncData *data;
spinlock_t lock;
} SyncList;
// Use multiple parallel lists to decrease contention among unrelated objects.
#define COUNT 16
#define HASH(obj) ((((uintptr_t)(obj)) >> 5) & (COUNT - 1))
#define LOCK_FOR_OBJ(obj) sDataLists[HASH(obj)].lock
#define LIST_FOR_OBJ(obj) sDataLists[HASH(obj)].data
static SyncList sDataLists[COUNT];
----------
SyncData中的recursive_mutex_t最终是recursive_mutex_tt类型,
recursive_mutex_tt内部有个pthread_mutex_t的锁,
这个锁初始化为一个递归锁 PTHREAD_RECURSIVE_MUTEX_INITIALIZER
----------
class recursive_mutex_tt : nocopy_t {
pthread_mutex_t mLock;
public:
recursive_mutex_tt() : mLock(PTHREAD_RECURSIVE_MUTEX_INITIALIZER) {
lockdebug_remember_recursive_mutex(this);
}
recursive_mutex_tt(const fork_unsafe_lock_t unsafe)
: mLock(PTHREAD_RECURSIVE_MUTEX_INITIALIZER)
{ }
void lock()
{
lockdebug_recursive_mutex_lock(this);
int err = pthread_mutex_lock(&mLock);
if (err) _objc_fatal("pthread_mutex_lock failed (%d)", err);
}
void unlock()
{
lockdebug_recursive_mutex_unlock(this);
int err = pthread_mutex_unlock(&mLock);
if (err) _objc_fatal("pthread_mutex_unlock failed (%d)", err);
}
..... 其他方法
};
- 其他问题
- 锁是如何与你传入 @synchronized 的对象关联上的?
- 你调用 sychronized 的每个对象,Objective-C runtime 都会为其分配一个递归锁并存储在哈希表中。
- @synchronized会保持(retain,增加引用计数)被锁住的对象么?
- ARC下会引用计数+1,MRC下不会
- 如果传入@synchronized 的对象值为 nil 将会怎么样?
- @synchronized(nil)不会有任何作用,hash计算为空,加锁失败,代码块不是线程安全的。你可以通过在 objc_sync_nil 上加断点来查看是否发生了这样的事情。
- 假如传入 @synchronized 的对象在 @synchronized 的 block 里面被释放或者被赋值为 nil 将会怎么样?
- 如果在 sychronized 内部对象被释放或被设为 nil 看起来都 OK。不过这没在文档中说明,所以我不会再生产代码中依赖这条。
12. 聊聊多线程
五、聊聊数据持久化
- 本地存储的几种方式
- 数据库(sqlite、coredate、FMDB、WCDB)
六、聊聊路由
- Beehive
- CTMeditor
七、聊聊Swift和OC的区别?
7.1 struct & class
- struct是值引用,更轻量,存放于栈,不可继承
- class是指针引用(或称类型引用),存放于堆区,可以继承
7.2 swift的派发机制
- 直接派发
- 是在struct、enum中,速度快,但是不能继承
- 函数表派发
- swift里函数表叫
Witness Table
,类会有一个数组存储里面的函数指针。 - 一个对象的内存地址前8位存储类的类型信息,类型信息就包括了函数指针。
- 后8位信息是引用计数
- swift里函数表叫
- 消息机制派发
- 消息派发是在运行时,可以改变函数的行为,KVO和CoreData都是对这种机制的运用。OC默认使用消息派发,C语言使用的是直接派发。
- 当一个消息被派发,程序运行时就会按照继承关系向上查找被调用的函数,但是效率不高,所以会通过缓存来提高效率,性能和函数表派发差不多。
- 消息派发是在运行时,可以改变函数的行为,KVO和CoreData都是对这种机制的运用。OC默认使用消息派发,C语言使用的是直接派发。
- 场景:
- 直接派发:
- 值类型
- final
- @inline
- class和协议的extension
- 函数表派发:
- class和协议的初始化声明
- 消息机制派发:
- class和@objc extension
- dynamic:可以让类里面的函数使用消息机制派发,可以重载extension里的函数
- @nonobjc: 来禁止消息机制派发这个函数
- 直接派发:
7.3 对协议的理解?
- 解决面向对象菱形继承问题