作者：AceDong&&juejin.im/post/5b3c40f4e51d45191a0d0aae
- 对mrc和arc的理解
- 谈谈对自动释放池的理解
- 自动释放池在mrc和arc区别
- 多层自动释放池嵌套的对象在哪一层释放
- 对于block，理解，mrc和arc下有什么区别，使用注意事项
- 对于深拷贝和浅拷贝的理解
- 对于strong weak，atomic等等理解
- weak原理
- 如果属性完全不加修饰词入weak，atomic，系统会怎么处理
- 简述下block的实现
- 描述下IM系统如何保证消息不丢
- IM数据库如何设计表
- C++引用和指针有什么区别
- Http协议30x的错误是什么
- 谈谈你懂runloop得理解：由浅入深
- 谈谈对多线程理解:由浅入深
- 谈谈category和extension区别，系统如何底层实现category
- 谈谈消息转发机制实现
- 谈谈事件响应链，如何响应view之外的事件
- 界面性能优化
- 先简单自我介绍一下自己
- 从我脸上看到什么：帅
参考内容
- MRC的优势及劣势
- ARC的工作原理参考
参考内容
-
autorelease方法会把对象存储到AutoreleasePoolPage的链表里。等到auto release pool被释放的时候，把链表内存储的对象删除。所以，AutoreleasePoolPage就是自动释放池的内部实现。
public: static inline id autorelease(id obj)
{
assert(obj);
assert(!obj->isTaggedPointer());
id *dest __unused = autoreleaseFast(obj);
assert(!dest || dest == EMPTY_POOL_PLACEHOLDER || *dest == obj);
return obj;
}
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);
}
}
id *add(id obj)
{
assert(!full());
unprotect();
id *ret = next; // faster than `return next-1` because of aliasing
*next++ = obj;
protect();
return ret;
}
参考内容
自动释放池是oc提供的一种自动回收的机制，具有延迟释放的特性，即当我们创建了一个对象，并把他加入到了自动释放池中时，他不会立即被释放，会等到一次runloop结束或者作用域超出{}或者超出[pool release]之后再被释放
- MRC: 通过手动创建的方式来创建自动释放池，这种方式创建的自动释放池需要手动调用release（引用计数环境下，调用release和drain的效果相同，但是在CG下，drain会触发GC,release不会）
- ARC下除了NSAutoreleasePool不可用以外，其他的同MRC
参考内容
嵌套的autoreleasepool
@autoreleasepool {//DragonLi被放在该自动释放池里面
XXClass *DragonLi = [[XXClass alloc]init];
@autoreleasepool {//p2被放在该自动释放池里面
XXClass * DragonLi = [[XXClass alloc]init];
}
}
autorelease对象被添加进离他最近的自动释放池，多层的pool会有多个哨兵对象。
参考内容
- 浅拷贝：只创建一个新的指针，指向原指针指向的内存
- 深拷贝：创建一个新的指针，并开辟新的内存空间，内容拷贝自原指针指向的内存，并指向它
- 如果用strong修饰，当我们给它传一个NSMutableString类型的数据时，它的指针指向了该数据，之后会随NSMutableString的特性去改变
参考内容
- 默认为atomic，Strong，ReadWrite
参考内容
本质：引用是别名，指针是地址，具体的：
参考内容
-
1xx - 信息提示
- 这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个 1xx 响应。 • 100 - 继续。
-
2xx - 成功
- 这类状态代码表明服务器成功地接受了客户端请求。
- • 200 - 确定。客户端请求已成功。
- • 201 - 已创建。
- • 202 - 已接受。
- • 203 - 非权威性信息。
- • 204 - 无内容。
- • 205 - 重置内容。
- • 206 - 部分内容。
-
3xx - 重定向
- 客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。
- • 302 - 对象已移动。
- • 304 - 未修改。
- • 307 - 临时重定向。
-
4xx - 客户端错误
- • 401 - 访问被拒绝。IIS 定义了许多不同的 401 错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示：
- • 401.1 - 登录失败。
- • 403.1 - 执行访问被禁止。
- • 403.2 - 读访问被禁止。
- • 403.3 - 写访问被禁止。
-
5xx - 服务器错误
- 服务器由于遇到错误而不能完成该请求。
- • 500 - 内部服务器错误。
- • 500.12 - 应用程序正忙于在 Web 服务器上重新启动。
- • 503 - 服务不可用。这个错误代码为 IIS 6.0 所专用。
参考内容
参考内容
从objc-os.mm文件的_objc_init函数开始-->map_images-->map_images_nolock-->_read_images-->remethodizeClass-->attachCategories-->attachLists-->realloc、memmove、 memcpy。
- 合并后分类的方法在前面(最后参与编译的那个分类的方法列表在最前面)，本类的方法列表在最后面。所以当分类中有和本类同名的方法时，调用这个方法执行的就是分类中的方法。从这个现象来看，就好像本类的方法被分类中同名的方法给覆盖了，实际上并没有覆盖，只是调用方法时最先查找到了分类的方法所以就执行分类的方法
// 定义在objc-runtime-new.h文件中
struct category_t {
const char *name; // 比如给Student添加分类，name就是Student的类名
classref_t cls;
struct method_list_t *instanceMethods; // 分类的实例方法列表
struct method_list_t *classMethods; // 分类的类方法列表
struct protocol_list_t *protocols; // 分类的协议列表
struct property_list_t *instanceProperties; // 分类的实例属性列表
struct property_list_t *_classProperties; // 分类的类属性列表
};
参考内容
-
函数调用（pointinside，hittest）入手
- 就说了上个项目做类似朋友圈的优化思路，谈到了空间换时间，缓存，渲染相关的技术点
- 需求痛点：界面卡顿，体验不好 解决方案：探索的思路-》解决方案
- 该模块引申到的新话题还涉及到了增量更新，内存缓存，本地缓存
- 细节上还谈到了富文本绘制，Coretext框架的使用
- 上个项目中存在视频裁剪，录制等功能。
面试官对这块有些兴趣，就聊到了视频裁剪的实现，因为我们项目中使用了ffmpeg做的裁剪功能。包括视频下载，数据裁剪封装，引申聊到了边预览边裁剪，因为我之前的项目并没有做到预览裁剪这块。也就没有深入聊下去了。期间简单谈到了rstp协议，和HLS，rtmp等协议的对比，信令协议。虽然之前都有看过协议的大致实现和预览，但是实际使用的是SDK，没有实践加持。这部分知识是很容易忘记的。大致聊了下总体差别 - 项目中有用到过DLNA投屏协议 说来又是惭愧，自己完整做过的项目，过去了两年，居然连流程，协议都只是零零散散的记起来了，很勉强的说出了大概实现流程。知道最后才记起来是soap协议。当初为了做这个可是研究了整整两周的。面试官应该也实现过这个需求，提到了视频盒子断线如何检测做处理，什么原因导致的。由于之前我们的产品需求比较简单，没有特别完善。这里我也只能说了大概 - 项目做过视频播放需求，使用的AVPlayer框架（重点聊） 面试官问到，AVPlayer怎么监听视频缓冲状态的，有哪几种状态。说来又是惭愧，我只记得是KVO监听的。具体的API已经记不清了。 接着面试官问到这个需求遇到过哪些坑，怎么解决的。 这个还真的有，首先是回调播放进度在拖动时候错乱，加载某些小视频的适配，首帧出图很慢。KVO的模式不灵活。缓冲进度不受我们控制。短视频可能直接迅速缓冲到底。还是之前的思路,需求痛点有了.解决方案：探索的思路-》解决方案。 不得不说之前做的产品，都是需求驱动，解决了需求，很多时候就没有极客精神，在深入的去探讨。这块真的是差！ - 如果网络不好，首帧出图之后，如何优化后续播放不卡顿 当时已经一脸懵逼了：就提到了可以适当加大缓冲区，等到足够的I帧数据再开始播放
-
项目聊完了之后，又追问了iOS的一些基础问题，属性和成员变量区别，strong，atomic关键字，怎么理解runloop，runloop有几种状态等等
-
非常有意思的算法题
- 有15个瓶子，其中最多有一瓶有毒，现在有四只老鼠，喝了有毒的水之后，第二天就会死。如何在第二天就可以判断出哪个瓶子有毒 答：开始我想到的是常规思路二分法，717，和面试官说了，发现四只老鼠根本不够，面试官友好的提示从老鼠面去想，这时候很快想到了一个老鼠有死和不死，也就0和1两个状态，四只老鼠有16个组合，正好是足够的。但是怎么分配瓶子，还没想好，演算了一会儿，因为面试官这边时间有限，就说思路是正确的。下面有兴趣在看怎么分哈。面试就到此结束了。
- 面试题系列目录
- 上一份: 阿里腾讯百度头条美团iOS面试题2018年4月
- 下一份: 腾讯音乐iOS面试题2018年7月