1、声明的 delegate
属性不总是 weak
策略
委托 delegation
是 iOS
开发的常用设计模式,为了避免对象与其代理之间的因为相互 retain 导致循环引用的发生,delegate
属性在如今的 ARC
时代通常声明为 weak
策略,然而在早期的手动管理内存的时代,还未引入 strong/weak
关键字,使用 assign
策略保证 delegate
的引用计数不增加, 在 Swift
中是 unowned(unsafe)
, UIApplication
的 delegate
声明如下:
// OC@property(nullable, nonatomic, assign) iddelegate;复制代码
// Swiftunowned(unsafe) open var delegate: UIApplicationDelegate?复制代码
assign
和 weak
都只复制一份对象的指针,而不增加其引用计数,区别是:weak
的指针在对象释放时会被系统自动设为 nil
,而 assign
却仍然保存了 delegate
的旧内存地址,潜在的风险就是:如果 delegate
已销毁,而对象再通过协议向 delegate
发送消息调用,则会导致野指针异常 exc_bad_access
,这在使用 CLLocationMananger
的 delegate
时尤其需要注意。如果使用了 delegate
为 assign
策略,则需要效仿系统对 weak
的处理,在 delegate
对象释放时将 delegate
手动设置为 nil
。
@implementation XViewController- (void)viewDidLoad { [super viewDidLoad]; self.locationManager = [[CLLocationManager alloc] init]; self.locationManager.delegate = self; [self.locationManager startUpdatingLocation];}/// 必须手动将其 delegate 设为 nil- (void)dealloc { [self.locationManager stopUpdatingLocation]; self.locationManager.delegate = nil;}@end复制代码
除了 assgin
的情况,还有一些情况下 delegate
是被对象强引用 retain
的,比如 NSURLSession
,delegate
将被 retain
到 session
对象失效为止。
/* ..... * If you do specify a delegate, the delegate will be retained until after * the delegate has been sent the URLSession:didBecomeInvalidWithError: message. */+ (NSURLSession *)sessionWithConfiguration:(NSURLSessionConfiguration *)config delegate:(nullable id)delegate delegateQueue:(nullable NSOperationQueue *)queue;复制代码
对于这种情况,处理方式,循环引用是肯定存在的,解决的方式是通过移除引用的方式来手动打破,因此 NSURLSession
提供了 session
失效的两个方法:
- (void)finishTasksAndInvalidate;- (void)invalidateAndCancel;复制代码
作为 NSURLSession
的第三方封装 AFNetworking
,其 AFURLSessionManager
对应地提供了失效方法:
/** Invalidates the managed session, optionally canceling pending tasks. @param cancelPendingTasks Whether or not to cancel pending tasks. */- (void)invalidateSessionCancelingTasks:(BOOL)cancelPendingTasks;复制代码
此外,CAAnimation
的 delegate
也是 strong
引用,如果因为业务需要发生了循环引用,需要在合适的时机提前手动打破。
@interface CAAnimation//.../* The delegate of the animation. This object is retained for the * lifetime of the animation object. Defaults to nil. See below for the * supported delegate methods. */@property(nullable, strong) iddelegate;复制代码
总之,使用 delegate
时需要留意其声明方式,因地制宜地处理。
2、既然是 assign
, 那么 AppDelegate
为什么不会销毁
上文讨论 UIApplication
对 delegate
,也就是 AppDelegate
类的实例,其声明为 assign
策略,AppDelegate
实例没有其他对象引用,在应用的整个声明周期中是一直存在的,原因是什么?
在 stackoverflow
的一个回答 中可以了解到一些情况,大意是:
- 从
main.m
中初始化了第一个AppDelegate
实例,被系统内部隐式地retain
- 直到下一次
application
被赋值一个新的delegate
时系统才将第一个AppDelegate
实例释放 - 对于新创建的
application
的delegate
对象,由创建者负责保证其不会立即销毁,举例如下:
// 声明为静态变量,长期持有static AppDelegate *retainDelegate = nil;/// 切换 application 的 delegate 对象- (IBAction)buttonClickToChangeAppDelegate:(id)sender { AppDelegate *delegate = [[AppDelegate alloc] init]; delegate.window.rootViewController = [[ViewController alloc] init]; [delegate.window makeKeyAndVisible]; retainDelegate = delegate; [UIApplication sharedApplication].delegate = retainDelegate;}复制代码
application
的 delegate
可以在必要时切换(通常不这样做),UIApplication
单例的类型同样是支持定制的,这个从 main.m
的启动函数可以看出:
// If nil is specified for principalClassName, // the value for NSPrincipalClass from the Info.plist is used. If there is no// NSPrincipalClass key specified, the UIApplication class is used. // The delegate class will be instantiated using init.UIKIT_EXTERN int UIApplicationMain(int argc, char *argv[], NSString * __nullable principalClassName, NSString * __nullable delegateClassName);复制代码
通过 UIApplicationMain()
函数传参或者在 info.plist
中注册特定的 key
值,自定义应用的 Application
和 AppDelegate
的类是可行的。
@interface XAppDelegate : UIResponder@property (nonatomic, strong) UIWindow *window;@end@interface XApplication : UIApplication@endint main(int argc, char * argv[]) { @autoreleasepool { return UIApplicationMain(argc, argv, NSStringFromClass([XApplication class]), NSStringFromClass([XAppDelegate class])); }}复制代码
又或者,干脆使用 runtime
在必要时将 application
对象替换为其子类。
/// runtime, isa-swizzling,置换应用单例的类为特定子类object_setClass([UIApplication sharedApplication], [XApplication class]);复制代码
3、使用 Notification
和 category
避免 AppDelegate
的臃肿
因为 AppDelegate
是应用的 delegate
,其充当了应用内多个事件的监听者,包括应用启动、收到推送、打开 URL
、出入前后台、收到通知、蓝牙和定位等等。随着项目的迭代,AppDelegate
将越发臃肿,因为 UIApplication
除了 delegate
外,还同时有发送很多通知 NSNotification
,因而可以从两个方面去解决:
- 尽可能地通过
UIApplication
通知监听来处理事件,比如应用启动时会发送UIApplicationDidFinishLaunchingNotification
通知 - 没有通知但是特定业务的
UIApplicaiondDelegate
协议方法,可以按根据不同的业务类型,比如通知、openURL
分离到不同的AppDelegate
的category
中
进一步地,对于应用启动时,就需要监听的通知,合适时机是在某个特定类的 load
方法中开始。针对性地,可以为这种 Launch
监听的情况进行封装,称为 AppLaunchLoader
:
- 在
AppLaunchLoader
的load
方法中监听应用启动的通知 - 在
AppLaunchLoader
的category
的load
方法中注册启动时需要执行的任务block
- 当监听到应用启动通知时执行注册的所有
block
,完成启动事件与AppDelegate
的分离。
typedef void(^GSLaunchWorker)(NSDictionary *launchOptions);@interface GSLaunchLoader : NSObject/// 注册启动时需要进行的配置工作+ (void)registerWorker:(GSLaunchWorker)worker;@end@implementation GSLaunchLoader+ (void)load { NSNotificationCenter *c = [NSNotificationCenter defaultCenter]; [c addObserver:self selector:@selector(appDidLaunch:) name:UIApplicationDidFinishLaunchingNotification object:nil];}+ (void)appDidLaunch:(NSNotification *)notification { [self handleLaunchWorkersWithOptions:notification.userInfo];}#pragma mark - Launch workersstatic NSMutableArray*_launchWorkers = nil;+ (void)registerWorker:(GSLaunchWorker)worker { [[self launchWorkers] addObject:worker]; }+ (void)handleLaunchWorkersWithOptions:(NSDictionary *)options { for (GSLaunchWorker worker in [[self class] launchWorkers]) { worker(options); } [self cleanUp];}+ (void)cleanUp { _launchWorkers = nil; NSNotificationCenter *c = [NSNotificationCenter defaultCenter]; [c removeObserver:self name:UIApplicationDidFinishLaunchingNotification object:nil];}+ (NSMutableArray *)launchWorkers { if (!_launchWorkers) { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _launchWorkers = [NSMutableArray array]; }); } return _launchWorkers;}@end复制代码
源代码
推荐阅读 苏合的