干凈優雅的做iOS應用內全局交互屏蔽
01、交互屏蔽的需求
很多應用開發者都會遇到這樣一個需求，當程序需要處理某個敏感的核心任務，或者執行某些動畫時，需要杜絕一切外部干擾，優先保證任務的完成，之后再去處理其它任務。否則如果在處理過程中受到外部事件的干擾，可能會引入嚴重的問題，而規避這些問題需要額外編寫過多的邏輯。
例如，當程序在忙著清理應用內緩存的過程中去處理其它任務，這時候由于其它任務可能會產生新的緩存，這就會和現有的任務沖突。所以在清理緩存的過程中，app 一般會暫時中斷用戶和非用戶的請求，優先保證緩存清理的完成。
所以，為了簡化產品設計邏輯，開發者一般會選擇在處理任務時暫時屏蔽其它任務，優先保障現有任務的完成。
舉例來說，當用戶點擊清理緩存時，應用程序可能會彈出一個帶有進度條的清理界面，在該界面下，清理工作緊張的進行著，并且告知用戶正在清理任務，請稍候。
另一個需求是和動畫有關，有時候我們在應用內可能會執行一些小動畫，例如按鈕的淡入淡出，整個頁面的切換等。這些動畫可能不會因為用戶做快速的操作導致程序崩潰，但是因為每個動畫都要時間完成，如果用戶快速亂點的話，有可能會出現意想不到的情況。
例如，假設用戶點擊某個開關切換按鈕，開關狀態為開時，屏幕側邊以動畫形式彈出側邊欄，當開關狀態為關時，屏幕側邊欄以動畫形式消失。那么如果用戶快速反復點擊按鈕，而開發者沒有處理好開關切換間隙的邏輯的話，那么就會出現側邊欄彈出動畫還沒執行完，就立刻消失的情況。
值得注意的是，這一類事件包括但不限于用戶觸摸事件，還有屏幕重力感應的變化等非用戶輸入事件，這就意味著這一類問題如果要優雅解決的話，不能單靠添加一個"觸摸屏蔽層"。
02、常見的解決辦法
對于以上問題，開發者選擇的解決辦法主要是兩種：
第一個辦法，設計一個布爾變量記錄當前是否正在執行任務（或處理動畫），處理這個過程中的交互邏輯。
這個辦法本身沒什么問題，但是開發者不得不針對每個任務去編寫對應的邏輯，這樣寫起來就特別容易散亂。
第二個辦法，設置 UIView 或者控件的 userInteractionEnabled 為 false，并在合適的時機重新變為 true 。
這樣做有個好處是，將整個 UIView 設置不可交互后，用戶點擊其它按鈕也不會造成影響，但同時，如果對每個 UIView 去處理類似的邏輯，一不小心很容易出現 bug，最后導致整個 UIView 都卡住無法點擊。
另外，應用可能存在多個 UIView，你鎖住了一個 UIView，其它 UIView 的點擊情況是否要考慮呢？
有些開發者用了更好的辦法，他們直接用 UIViewController 的 UIView 來做 userInteractionEnabled 的處理，這樣的解決方案更進步了，但是同樣存在多個 UIViewController 這個問題，雖然有效，但還欠缺優雅。
另一方面，如上述的所有方法，僅僅能攔截"觸摸事件"，而不能攔截非觸摸事件，例如加速器，攝像頭事件等，如果代碼針對這些事件會做出響應，而開發者不希望在任務期間去響應他們，將被迫去添加邏輯來屏蔽才行。
03、重新理解 UIApplication
我們對 UIApplication 不陌生了，我們經常需要通過調用UIApplication.sharedApplication。
在 iOS 的應用層 API 中，UIKit 最頂層的交互機制是通過 UIApplication 的 方法下發的 sendEvent ：
- (void)sendEvent: (UIEvent*)eventUIEvent 不止包括觸摸事件，它還支持例如加速度事件等別的事件類型。
// UIEvent 的事件類型
typedef NS_ENUM(NSInteger, UIEventType) {
UIEventTypeTouches,
UIEventTypeMotion,
UIEventTypeRemoteControl,
UIEventTypePresses,
UIEventTypeScroll,
UIEventTypeHover,
UIEventTypeTransform,
};以上是 UIApplication 中的事件類型，其中最值得關注的是 UIEventTypeTouches 和 UIEventTypeMotion，因為這是開發者最常用于響應輸入的事件。
04、如何攔截 sendEvent，先搞懂 UIApplicationMain
要攔截 sendEvent，就要了解 UIApplicationMain，幾乎每個 iOS 開發者都會碰到它，因為它就在 main 函數里：
int main(int argc, char * argv[]) {
NSString* appDelegateClassName;
@autoreleasepool {
appDelegateClassName = NSStringFromClass([AppDelegate class]);
}
return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}UIApplicationMain 相當于 iOS 應用自己的 main 函數，它的參數有 4 個，分別為 argc， argv，principalClassName 和 delegateClassName 。
其中前兩個參數就是 C 語言 main 函數的參數，appDelegateClassName 傳入的是 AppDelegate 的類名，第三個參數則傳入用戶自定義的 UIApplication 子類。
我們定義一個繼承自 UIApplication 的 MyApplication 類后，main 函數就可以傳入 MyApplication 類了。
int main(int argc, char * argv[]) {
NSString* appDelegateClassName;
NSString* applicationClassName;
@autoreleasepool {
appDelegateClassName = NSStringFromClass([AppDelegate class]);
applicationClassName = NSStringFromClass([MyApplication class]);
}
return UIApplicationMain(argc, argv, applicationClassName, appDelegateClassName);
}還有一個方法可以不通過修改 main 函數來指定 MyApplication，在 XCode 的 Info.plist 中，新建字符串鍵 “Principal class”，其值填入子類名，即本例的 MyApplication，那么當 main 函數傳入的參數是 nil 時，Info.plist 所注冊的 “Principal class” 將會作為指定類。如果全部沒有指定，則默認為 UIApplication 。
05、sendEvent 攔截實現
在 MyApplication 類的實現部分，我們可以開始繼承 sendEvent ：
- (void)sendEvent: (UIEvent*)event {
[super sendEvent: event];
}當應用產生了 UIEvent 事件時，系統會調用 sendEvent，此時因為我們注冊了 MyApplication，所以調用的是我們定義的 sendEvent 方法。在上個例子里，sendEvent 直接調用了父類的 sendEvent，相當于對所有事件都采取了默認處理。
接下來，如果我們打算屏蔽所有的加速器事件，那么可以這么寫:
- (void)sendEvent: (UIEvent*)event {
if (event.type == UIEventTypeMotion) {
NSLog(@"UIEventTypeMotion");
return;
}
[super sendEvent: event];
}這樣，如果應用內有處理搖一搖的功能，以上方法可以保證搖一搖事件不會下發。
06、交互屏蔽的接口設計
顯然，我們需要更彈性的處理 sendEvent，直接屏蔽的辦法是“一刀切”，更恰當的做法是需要屏蔽的時候才讓它屏蔽。因此，我們可以為 MyApplication 設計一個布爾屬性 eventdisabled：
@interface MyApplication()
@property (nonatomic) BOOL eventDisabled;
@end該屬性默認值是 false，即允許所有 event ，這樣，sendEvent 方法的實現更改如下：
- (void)sendEvent: (UIEvent*)event {
if (self.eventDisabled && (event.type == UIEventTypeTouches || event.type == UIEventTypeMotion)) {
return;
}
[super sendEvent: event];
}當 eventdisabled 為真時，app 在全局范圍內禁用了用戶的觸摸和加速器輸入事件，只有當 eventdisabled 為假時，一切照常進行。
雖然現在可以通過變量讓 app 實現交互的禁用和啟用了，但是我們可以設計的更彈性一點，做一個延時機制，保證延時過后交互可以恢復正常，不然開發者四處寫布爾值設置的代碼，一旦稍有不慎，整個界面卡住就糟了，為了程序的健壯性，可以設計如下方法：
- (void)disableUserInteraction: (NSTimeInterval)duration {
self.userInteractionEnabled = NO;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, duration*NSEC_PER_SEC), dispatch_get_main_queue(), ^{
self.userInteractionEnabled = YES;
});
}然后，我們把該方法放到 UIApplication 的擴展中，在 MyApplication.h 加入：
@interface UIApplication()
- (void)disableUserInteraction: (NSTimeInterval)duration;
@end這樣，當我們需要臨時禁用用戶輸入時，可以這么調用：
[UIApplication.sharedApplication disableUserInteraction: 0.3];此時應用會在 0.3 秒內處于禁用狀態，并在稍后自動恢復。
07、如何進一步優化
以上介紹的屏蔽方案已經可以解決大部分日常需求，但是還有優化空間。
例如，當有多次調用 disableUserInteraction 時，例如：
[UIApplication.sharedApplication disableUserInteraction: 0.3];
[UIApplication.sharedApplication disableUserInteraction: 1.3];我們會發現，0.3 秒后應用就恢復了交互，而 1.3 秒的屏蔽"失效"了。
本文轉載自微信公眾號「搜狐技術產品」，可以通過以下二維碼關注。轉載本文請聯系搜狐技術產品公眾號。
