iOS螢幕旋轉解決方案

1.導航控制器棧內部的VC方向是導航控制器來決定的。nav --- A --- B --- C，C的旋轉方法是不起作用的，靠的是nav的-(BOOL)shouldAutorotate和-(UIInterfaceOrientationMask)supportedInterfaceOrientations。

解決方案是：重寫nav的旋轉方法，把結果指向到topViewController：

-(BOOL)shouldAutorotate{
   return self.topViewController.shouldAutorotate;
}

-(UIInterfaceOrientationMask)supportedInterfaceOrientations{
    return self.topViewController.supportedInterfaceOrientations;
}
複製程式碼

對於UITabBarController,就轉嫁為它的selectedViewController的結果。

2.旋轉的邏輯流是：手機方向改變了 ---> 通知APP ---> 呼叫APP內部的關鍵VC(TabBar或Nav)的旋轉方法 ---> 得到可旋轉並且支援當前裝置方向 ---> 旋轉到指定方向。

邏輯流的初始時物理上手機方向改變了。所有如果A push到 B，A只支援豎屏，而B只支援橫屏，如果這時手機物理方向沒變，那麼B還是會跟A一樣豎屏，哪怕它只支援橫屏並且問題1也解決了的。

解決方案：強制旋轉。

@implementation UIDevice (changeOrientation)

+ (void)changeInterfaceOrientationTo:(UIInterfaceOrientation)orientation
{
   if ([[UIDevice currentDevice] respondsToSelector:@selector(setOrientation:)]) {
       SEL selector             = NSSelectorFromString(@"setOrientation:");
       NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:[UIDevice instanceMethodSignatureForSelector:selector]];
       [invocation setSelector:selector];
       [invocation setTarget:[UIDevice currentDevice]];
       int val                  = orientation;
       [invocation setArgument:&val atIndex:2];
       [invocation invoke];
   }
}


@end
複製程式碼

給UIDevice提供一個category，呼叫setOrientation:這個私有方法來實現。

3.有了問題1和2的解決，對於整個專案的基本方案確定。一般專案會有一個主方向，絕大多數介面都是這個方向，比如豎屏，然後有特定介面是特定方向。

那麼解決方案是：

• 在target --> General --> Development Info裡配置支援所有可能的方向
• 使用baseViewController，專案所有VC都繼承與它，在baseVC裡寫入預設方向設定，這個預設設定就是絕大多數介面支援的方向。
• 然後在特殊方向介面，重寫-(BOOL)shouldAutorotate和-(UIInterfaceOrientationMask)supportedInterfaceOrientations來達到自己的目的。
• 特殊介面因為要強制旋轉，所以在進入介面是旋轉到需要方向：

  -(void)viewWillAppear:(BOOL)animated{
   [UIDevice changeInterfaceOrientationTo:(UIInterfaceOrientationLandscapeLeft)];
}
複製程式碼

4.push和pop的結果測試：

要驗證問題3的方案是否滿足需要，滿足需要的意思是：每個頁面能夠顯示它支援的方向而且不會干擾到其他介面。所以測試一下push和pop的情況。

測試變數有：

• 當前的介面是預設還是特殊，這裡把只有豎屏設為預設，橫屏為特殊情況。預設代表這個VC只需繼承baseVC的方向相關方法，不做任何額外處理。
• 介面是push還是pop
• 下一個介面是預設情況還是特殊情況。
• 下一個介面的shouldAutorate是否為YES。

前後兩個介面方向一致的畫，結果肯定是好的，就不測試 了。最終測試結果如下：

動作	當前	目標	目標可旋轉	結果
push	預設	特殊	✔️	成功
push	預設	特殊	❌	失敗
push	特殊	預設	✔️	失敗(2)
push	特殊	預設	❌	失敗(3)
pop	預設	特殊	✔️	成功
pop	預設	特殊	❌	失敗
pop	特殊	預設	✔️	成功(1)
pop	特殊	預設	❌	成功(1)

• 成功代表目標介面旋轉到了期望的方向
• 標記1：沒有旋轉，直接顯示的預設樣式（豎屏）。
• 標記2：從橫屏到豎屏，沒有切換方向，為什麼？因為UIDevice的方向沒有修改，沒有觸發切換效果。所以在特殊介面離開的時候還要呼叫強制旋轉。其實只要相鄰的方向不同，就要在切換時觸發強制旋轉。
• 新增了viewWillDisappear裡的強制旋轉後，標記2可以解決。但標記3還是失敗，其實push時，下一個介面如果是不可旋轉的，那麼方向一定是不變了。

特殊介面只要保持，進入和離開時都呼叫強制旋轉，並且自身shouldAutorate為YES,那麼push或pop進入特殊介面都沒有問題。關鍵是從特殊介面離開進入預設介面，pop時是成功的，push時如果預設介面是不可旋轉的，就會失敗。

針對這個有兩種方案：

• 在離開前把當前介面旋轉為預設，先旋轉，再push。
• 把預設介面改為可旋轉。

5.特殊方向介面離開前先旋轉到預設

因為特殊介面支援的方向不包含預設方向，所以只是強制旋轉時不起作用的，在強制旋轉前還要修改支援的方向。具體程式碼：

- (IBAction)push:(id)sender {
   
   [self changeOrientationBeforeDisappear];  //離開前先修改方向，其他每個出口都要呼叫這個方法。不能在`viewWillDisappear`裡呼叫，因為這時push等已經觸發了
   TFThirdViewController *thirdVC = [[TFThirdViewController alloc] init];
   [self.navigationController pushViewController:thirdVC animated:YES];
}

-(void)changeOrientationBeforeDisappear{
   _orientation = UIInterfaceOrientationMaskPortrait;  //替換為預設方向
   [UIDevice changeInterfaceOrientationTo:(UIInterfaceOrientationPortrait)];
   _orientation = UIInterfaceOrientationMaskLandscapeLeft; //替換為特殊方向介面自身需要的方向
}

-(UIInterfaceOrientationMask)supportedInterfaceOrientations{
   return _orientation;  //根據變數變化而變化
}

複製程式碼

如果下一個介面不是預設，會是什麼情況？會有兩次旋轉。離開時旋轉到預設，進入下一個介面，它自身又旋轉到指定方向。效果不好，如果想一次到位，怎麼辦？就要離開的時候知道下一個介面期望的方向是什麼，然後preferredInterfaceOrientationForPresentation正好符合這個意圖。 所以修改為：

@interface TFSecondViewController (){
   UIInterfaceOrientationMask _orientation;
   UIInterfaceOrientationMask _needOrientation;
}

@end

@implementation TFSecondViewController

- (void)viewDidLoad {
   [super viewDidLoad];
   
   _needOrientation = UIInterfaceOrientationMaskLandscapeLeft;
   _orientation = _needOrientation;
}

-(void)viewWillAppear:(BOOL)animated{
   [UIDevice changeInterfaceOrientationTo:(UIInterfaceOrientationLandscapeLeft)];
}

-(BOOL)shouldAutorotate{
   return YES;
}

- (IBAction)push:(id)sender {
   
   TFThirdViewController *thirdVC = [[TFThirdViewController alloc] init];
   [self changeOrientationBeforeDisappearTo:thirdVC];  //離開前先修改方向，其他每個出口都要呼叫這個方法。不能在`viewWillDisappear`裡呼叫，因為這時push等已經觸發了
   
   [self.navigationController pushViewController:thirdVC animated:YES];
}

-(void)changeOrientationBeforeDisappearTo:(UIViewController *)nextVC{
   _orientation = UIInterfaceOrientationMaskAll;  //改為任意方向
   [UIDevice changeInterfaceOrientationTo:[nextVC preferredInterfaceOrientationForPresentation]];
   _orientation = _needOrientation; //替換為特殊方向介面自身需要的方向
}

-(UIInterfaceOrientationMask)supportedInterfaceOrientations{
   return _orientation;  //根據變數變化而變化
}

@end

複製程式碼

_needOrientation時當前頁面需要的樣式。

總結起來就是：

• 給絕大多數情況建一個baseVC,裡面設定預設方向。
• 對特殊方向介面：
  • 進入時(viewWillAppear)強制旋轉到需要的方向
  • 離開時，注意並不是viewWillDisappear,而是push操作之前，先修改方向為下一個介面的期望方向。
  • 當然自身的shouldAutorotate保持為YES。
• 方向相關的3個方法全部要實現。因為基類(BaseVC)做了處理，可以省去絕大部分的工作。特殊方向的介面單個處理即可。
• preferredInterfaceOrientationForPresentation的方向要和進入時的方向一致，這樣就不會有2次旋轉。

相比把基類的shouldAutorotate改為YES,這個方案的好處是，把特殊情況的處理基本都壓縮在特殊介面自身內部了，依賴的只有其他介面的supportedInterfaceOrientations,這個方法是一個補充性的，不會干擾其他介面原本的設計。而對shouldAutorotate卻比較麻煩，因為其他介面可能不希望旋轉。

再次測試pop和push情況：

動作	當前	目標	目標可旋轉	結果
push	預設	特殊	✔️	成功
push	特殊	預設	✔️	成功
push	特殊	預設	❌	成功
pop	預設	特殊	✔️	成功
pop	特殊	預設	✔️	成功
pop	特殊	預設	❌	成功
push	特殊1	特殊2	✔️	成功
pop	特殊1	預設2	✔️	成功

• 特殊的都是可旋轉的，所以這種情況剔除了

6.present和dismiss的情況

動作	當前	目標	目標可旋轉	結果
present	預設	特殊	✔️	奔潰(1)
present	特殊	預設	✔️	成功
present	特殊	預設	❌	成功
dismiss	預設	特殊	✔️	成功
dismiss	特殊	預設	✔️	成功
dismiss	特殊	預設	❌	成功
present	特殊1	特殊2	✔️	成功
dismiss	特殊1	預設2	✔️	成功

奔潰1的問題是因為沒有實現preferredInterfaceOrientationForPresentation,而預設結果是當前的statusBar的樣式，從預設過去，那就是豎直方向，而這個介面supportedInterfaceOrientations的樣式又是橫屏，所以優先的方向(preferredxxx)不包含在支援的方向(supportedxxx)裡就奔潰了。按照之前的約定，supportedInterfaceOrientations是必須實現的，實現了就成功了。

所以解決方案通過測試。

最後，present和push的切換方式有個不同：如果A--->B使用present方式，A不可旋轉，但同時支援橫豎屏，B可旋轉，支援橫豎屏，那麼 A豎屏 ---> B豎屏 ---> 旋轉到橫屏 ---> dismiss 這個流程後，A會變成橫屏且不可旋轉。

也就是dismiss時，返回的介面不看你能不能旋轉，如果你支援當前的方向，就會直接變成當前方向的樣式。而supportedInterfaceOrientations預設是3個方向的，所以不實現這個方法而使用預設的，在dismiss的時候會有坑。