美文网首页
iOS 面试题 Objective-C

iOS 面试题 Objective-C

作者: th先生 | 来源:发表于2017-12-05 16:09 被阅读0次
  1. 请说明并比较以下关键词:strong,weak, assign, copy
  • strong表示指向并拥有该对象。其修饰的对象引用计数会增加1。该对象只要引用计数不为0则不会被销毁。当然强行将其设为nil可以销毁它。
  • weak表示指向但不拥有该对象。其修饰的对象引用计数不会增加。无需手动设置,该对象会自行在内存中销毁。
  • assign主要用于修饰基本数据类型,如NSInteger和CGFloat,这些数值主要存在于栈上。
  • weak 一般用来修饰对象,assign一般用来修饰基本数据类型。原因是assign修饰的对象被释放后,指针的地址依然存在,造成野指针,在堆上容易造成崩溃。而栈上的内存系统会自动处理,不会造成野指针。
  • copy与strong类似。不同之处是strong的复制是多个指针指向同一个地址,而copy的复制每次会在内存中拷贝一份对象,指针指向不同地址。copy一般用在修饰有可变对应类型的不可变对象上,如NSString, NSArray, NSDictionary。
  • Objective-C 中,基本数据类型的默认关键字是atomic, readwrite, assign;普通属性的默认关键字是atomic, readwrite, strong。
  1. 请说明并比较以下关键词:__weak__block
  • __weak与weak基本相同。前者用于修饰变量(variable),后者用于修饰属性(property)。__weak主要用于防止block中的循环引用。
  • __block也用于修饰变量。它是引用修饰,所以其修饰的值是动态变化的,即可以被重新赋值的。__block用于修饰某些block内部将要修改的外部变量。
  • __weak和__block的使用场景几乎与block息息相关。而所谓block,就是Objective-C对于闭包的实现。闭包就是没有名字的函数,或者理解为指向函数的指针。
  1. 请说明并比较以下关键词:atomatic, nonatomic
  • atomic修饰的对象会保证setter和getter的完整性,任何线程对其访问都可以得到一个完整的初始化后的对象。因为要保证操作完成,所以速度慢。它比nonatomic安全,但也并不是绝对的线程安全,例如多个线程同时调用set和get就会导致获得的对象值不一样。绝对的线程安全就要用 @synchronize。
  • nonatomic修饰的对象不保证setter和getter的完整性,所以多个线程对它进行访问,它可能会返回未初始化的对象。正因为如此,它比atomic快,但也是线程不安全的。
  1. 什么是ARC?
  • ARC全称是 Automatic Reference Counting,是Objective-C的内存管理机制。简单地来说,就是代码中自动加入了retain/release,原先需要手动添加的用来处理内存管理的引用计数的代码可以自动地由编译器完成了。
  • ARC的使用是为了解决对象retain和release匹配的问题。以前手动管理造成内存泄漏或者重复释放的问题将不复存在。
  • 以前需要手动的通过retain去为对象获取内存,并用release释放内存。所以以前的操作称为MRC (Manual Reference Counting)。
  1. 什么情况下会出现循环引用?
    循环引用是指2个或以上对象互相强引用,导致所有对象无法释放的现象。这是内存泄漏的一种情况。举个例子:
class Father
@interface Father: NSObject
@property (strong, nonatomic) Son *son;
@end
class Son
@interface Son: NSObject
@property (strong, nonatomic) Father *father; 
@end

上述代码有两个类,分别为爸爸和儿子。爸爸对儿子强引用,儿子对爸爸强引用。这样释放儿子必须先释放爸爸,要释放爸爸必须先释放儿子。如此一来,两个对象都无法释放。

解决方法是将Father中的Son对象属性从strong改为weak。

内存泄漏可以用Xcode中的Debug Memory Graph去检查,同时Xcode也会在runtime中自动汇报内存泄漏的问题。

  1. 下面代码中有什么bug?
- (void)viewDidLoad {
  UILabel *alertLabel = [[UILabel alloc] initWithFrame:CGRectMake(100,100,100,100)];
  alertLabel.text = @"Wait 4 seconds...";
  [self.view addSubview:alertLabel];
  NSOperationQueue *backgroundQueue = [[NSOperationQueue alloc] init];
  [backgroundQueue addOperationWithBlock:^{
    [NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:4]];
    alertLabel.text = @"Ready to go!”
  }];
}

Bug在于,在等了4秒之后,alertLabel并不会更新为Ready to Go。

原因是,所有UI的相关操作应该在主线程进行。当我们可以在一个后台线程中等待4秒,但是一定要在主线程中更新alertLabel。

最简单的修正如下:

- (void)viewDidLoad {
  UILabel *alertLabel = [[UILabel alloc] initWithFrame:CGRectMake(100,100,100,100)];
  alertLabel.text = @"Wait 4 seconds...";
  [self.view addSubview:alertLabel];
  NSOperationQueue *backgroundQueue = [[NSOperationQueue alloc] init];
  [backgroundQueue addOperationWithBlock:^{
    [NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:4]];
      [[NSOperationQueue mainQueue] addOperationWithBlock:^{
         alertLabel.text = @"Ready to go!”
      }];
  }];
}
  1. 以scheduledTimerWithTimeInterval的方式触发的timer,在滑动页面上的列表时,timer会暂停,为什么?该如何解决?
    原因在于滑动时当前线程的runloop切换了mode用于列表滑动,导致timer暂停。

runloop中的mode主要用来指定事件在runloop中的优先级,有以下几种:

  • Default(NSDefaultRunLoopMode):默认,一般情况下使用;
  • Connection(NSConnectionReplyMode):一般系统用来处理NSConnection相关事件,开发者一般用不到;
  • Modal(NSModalPanelRunLoopMode):处理modal panels事件;
  • Event Tracking(NSEventTrackingRunLoopMode):用于处理拖拽和用户交互的模式。
  • Common(NSRunloopCommonModes):模式合集。默认包括Default,Modal,Event Tracking三大模式,可以处理几乎所有事件。
    回到题中的情境。滑动列表时,runloop的mode由原来的Default模式切换到了Event Tracking模式,timer原来好好的运行在Default模式中,被关闭后自然就停止工作了。

解决方法其一是将timer加入到NSRunloopCommonModes中。其二是将timer放到另一个线程中,然后开启另一个线程的runloop,这样可以保证与主线程互不干扰,而现在主线程正在处理页面滑动。示例代码如下:

// 方法1
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
// 方法2
dispatch_async(dispatch_get_global_queue(0, 0), ^{
    timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(repeat:) userInfo:nil repeats:true];
    [[NSRunLoop currentRunLoop] run];
});

相关文章

网友评论

      本文标题:iOS 面试题 Objective-C

      本文链接:https://www.haomeiwen.com/subject/qvecixtx.html