作為了iOS project自帶的life cycle管理類，同時也是原生的一個singleton類，AppDelegate其實(shí)很多時候是簡直就是bad code的典范。很多人會直接把所有需要持續(xù)性存在的方法和屬性全部塞到這個類里面，使得很多項(xiàng)目的AppDelegate都有大幾白行甚至上千行，這個給代碼管理和迭代帶來了巨大的困難。作為Tech Lead解決這個問題的方法就是強(qiáng)迫大家遵循一定的設(shè)計(jì)原則，在實(shí)際工作中，我提出的原則就是：“誰污染誰治理” - 每一個模塊或者方法的作者有義務(wù)自行管理模塊或者方法的life cycle。具體實(shí)現(xiàn)方法就是通過將跟App Life Cycle相關(guān)的方法和模塊都抽象成不同的服務(wù)來插入原有的AppDelegate之中。這樣的好處是代碼管理和清理難度大幅度降低，同時代碼的可讀性大幅度上升。

首先設(shè)立一個placeholder來繼承UIApplicationDelegate

import UIKit

protocol ApplicationService:UIApplicationDelegate {}

class LifeCycleService:UIResponder,ApplicationService {
    
    var window: UIWindow?
    
    //Why computed? For AppDelegate to override. It should not be computed property if you don't adopt this structure.
    var services:[ApplicationService] {
        return []
    }
    
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        for service in services {
            service.applicationDidFinishLaunching?(application)
        }
        return true
    }
    
    func applicationWillResignActive(_ application: UIApplication) {
        for service in services {
            service.applicationWillResignActive?(application)
        }
    }
    
    func applicationDidEnterBackground(_ application: UIApplication) {
        for service in services {
            service.applicationDidEnterBackground?(application)
        }
    }
    
    func applicationWillEnterForeground(_ application: UIApplication) {
        for service in services {
            service.applicationWillEnterForeground?(application)
        }
    }
    
    func applicationDidBecomeActive(_ application: UIApplication) {
        for service in services {
            service.applicationDidBecomeActive?(application)
        }
    }
    
    func applicationWillTerminate(_ application: UIApplication) {
        for service in services {
            service.applicationWillTerminate?(application)
        }
    }
    /* To be continued...
       I know you don't like the word technologically, so theoretically, you should (another bad word here) implement all methods in the UIApplicationDelegate!!! Why I don't do it? Yes, you are right, because I am lazy. Although lazy is a good word to describe a developer.
     */
}

這只是一個例子，實(shí)際上，你可以根據(jù)自己需要，把所有UIApplicationDelegate里面的方法全部用這種方法實(shí)現(xiàn)。

然后再根據(jù)自己的需求來設(shè)立想要的Service模塊：

import UIKit

class DependencyLoading:NSObject, ApplicationService {
    
    func applicationDidFinishLaunching(_ application: UIApplication) {
        //Let's pretend to have a Reachability class
        Reachability.shared.checkInternetAccessbility()

    }
    
    func applicationWillResignActive(_ application: UIApplication) {
        Reachability.shared.stopMonitotingReachability()
    }
    
    func applicationDidBecomeActive(_ application: UIApplication) {
        Reachability.shared.startMonitoringReachability()
    }
}

extension DependencyLoading:ReachabilityDelegate {
    
    func didLostInternetConnection() {
        /*
         Please Remember this name, next time anything breaks including you forgot your AD-ENT password, make sure you call 
         this guy before step 2.
         */
        print("Siri, call Andrew Martinez...")
    }
}

你可以用這種方法把各種不同的功能抽象成不同的模塊，比如Push Notification 相關(guān)的方法和屬性就可以抽象成NotificationService。LocalNotification的方法抽象成LocationNotificationService。CoreData相關(guān)的方法和屬性抽象成PersistentService之類的。

最后我們來看一下系統(tǒng)自帶的AppDelegate：

import UIKit

@UIApplicationMain
class AppDelegate: LifeCycleService {
    override var services: [ApplicationService] {
        return [    /*
                       Here is checkin list and checkin is mandatory for every one!
                    */
                    LifeCycleService(),
                    DependencyLoading()
               ]
    }
}