(轉(zhuǎn))從ViewController初始化一直談到強(qiáng)制橫屏

轉(zhuǎn)自：http://blog.sina.com.cn/s/blog_76264a170101e5lb.html

標(biāo)簽：轉(zhuǎn)屏 shouldautorotate frame viewcontroller 分類： iOS開發(fā)筆記

文字羅嗦，篇幅較長，只需營養(yǎng)可直接看紅字部分。

一個viewController的初始化大概涉及到如下幾個方法的調(diào)用：

initWithNibName:bundle:

viewDidLoad

viewWillAppear:animated:

viewDidAppear:animated:

viewWillLayoutSubviews

viewDidLayoutSubviews

通常情況這幾個方法是依次被調(diào)用的，我們會在init方法中初始化一些成員變量，做一些與view無關(guān)的事情。而后在viewDidLoad中進(jìn)行view布局相關(guān)的屬性調(diào)整，比如改變一下背景顏色，增加一些subview之類的。不知道大家有沒有想過，這樣不在init中寫view相關(guān)代碼是為了什么？難道僅僅是為了代碼結(jié)構(gòu)清晰？如果我非要在init做一些與view相關(guān)的初始化工作，能不能實現(xiàn)？有什么問題？

@implementation testViewController

- (void)printFrame:(CGRect)frame name:(NSString *)name

{

NSLog(@"%@ :(%f, %f, %f, %f)", name, frame.origin.x, frame.origin.y, frame.size.width, frame.size.height);

}

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil

{

self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];

if (self) {

// Custom initialization

self.view.backgroundColor = [UIColor yellowColor];

[self printFrame:self.view.frame name:@"initFrame"];

}

return self;

}

- (void)viewDidLoad

{

[super viewDidLoad];

// Do any additional setup after loading the view.

[self printFrame:self.view.frame name:@"didloadFrame"];

}

- (void)viewWillLayoutSubviews

{

[super viewWillLayoutSubviews];

[self printFrame:self.view.frame name:@"willLayoutFrame"];

}

-(void)viewDidLayoutSubviews

{

[super viewDidLayoutSubviews];

[self printFrame:self.view.frame name:@"didLayoutFrame"];

}

- (void)viewWillAppear:(BOOL)animated

{

[super viewWillAppear:animated];

[self printFrame:self.view.frame name:@"willAppearFrame"];

}

-(void)viewDidAppear:(BOOL)animated

{

[super viewDidAppear:animated];

[self printFrame:self.view.frame name:@"didappearFrame"];

}

這段代碼在init方法中設(shè)置了一下view的backgroundColor。運(yùn)行結(jié)果很正常，view的背景色被成功地設(shè)定為黃色，但是看控制臺的log輸出，出現(xiàn)了一個不符合預(yù)期的現(xiàn)象：

didloadFrame :(0.000000, 20.000000, 768.000000, 1004.000000)

initFrame :(0.000000, 20.000000, 768.000000, 1004.000000)

willAppearFrame :(0.000000, 0.000000, 768.000000, 960.000000)

didappearFrame :(0.000000, 0.000000, 768.000000, 960.000000)

willLayoutFrame :(0.000000, 0.000000, 768.000000, 960.000000)

didLayoutFrame :(0.000000, 0.000000, 768.000000, 960.000000)

viewDidLoad竟然先于init給出了輸出，經(jīng)過跟蹤發(fā)現(xiàn)，原來當(dāng)程序第一次調(diào)用self.view的時候，viewDidLoad方法就會被執(zhí)行，而不一定非要等到init之后willAppear之前。這給我們敲響了警鐘，這樣的代碼就隱藏了問題：

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil

{

self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];

if (self) {

// Custom initialization

self.view.backgroundColor = [UIColor yellowColor];

aInstanceVariable_= 0; // Custom initialization of an instance variable

}

return self;

}

- (void)viewDidLoad

{

[super viewDidLoad];

// Do any additional setup after loading the view.

aInstanceVariable_ = 10086;

}

這段代碼執(zhí)行完后的aInstanceVariable_是0而不是10086，可能會為一些bug深深地埋下一顆種子。

搞清楚了代碼執(zhí)行順序，下面我們來關(guān)注一下frame和bounds的問題。frame和bounds的定義和區(qū)別在這篇blog里講的很清楚，總結(jié)起來要點就是，frame是相對于父view參照系(是父view而不是父viewController)的，bounds是本地參照系，改frame的時候center和bounds聯(lián)動，但改bounds的時候center不動。

把上面的程序稍微修改一下，來看一組值得研究一下的結(jié)果（此viewController由帶導(dǎo)航條的navigationController推送），實際上不用navigationController而直接加載這個vc，結(jié)果又不一樣，viewDidAppear會在最后viewDidLayoutSubviews之后才調(diào)用，其他順序不變，亂吧……

didLoadFrame :(0.000000, 20.000000, 768.000000, 1004.000000) direction:(1, 1)

didLoadBounds :(0.000000, 0.000000, 768.000000, 1004.000000) direction:(1, 1)

initFrame :(0.000000, 20.000000, 768.000000, 1004.000000) direction:(1, 1)

initBounds :(0.000000, 0.000000, 768.000000, 1004.000000) direction:(1, 1)

willAppearFrame :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

willAppearBounds :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

didAppearFrame :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

didAppearBounds :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

willLayoutFrame :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

willLayoutBounds :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

didLayoutFrame :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

didLayoutBounds :(0.000000, 0.000000, 768.000000, 960.000000) direction:(1, 1)

剛才這個是豎屏的，再來個橫屏的：

didLoadFrame :(0.000000, 0.000000, 748.000000, 1024.000000) direction:(3, 3)

didLoadBounds :(0.000000, 0.000000, 748.000000, 1024.000000) direction:(3, 3)

initFrame :(0.000000, 0.000000, 748.000000, 1024.000000) direction:(3, 3)

initBounds :(0.000000, 0.000000, 748.000000, 1024.000000) direction:(3, 3)

willAppearFrame :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

willAppearBounds :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

didAppearFrame :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

didAppearBounds :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

willLayoutFrame :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

willLayoutBounds :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

didLayoutFrame :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

didLayoutBounds :(0.000000, 0.000000, 1024.000000, 704.000000) direction:(3, 3)

總結(jié)一下不難發(fā)現(xiàn)其特征：1. 在viewWillAppear之前，無論橫屏還是豎屏，view的frame和bounds都是按豎屏方式計算的；2. 在viewWillAppear之前，navigationController（而非父view，實際上這個vc的superview是navigationController的view的一個subview）的導(dǎo)航條并沒有計算在frame和bounds中，但電池條的寬度是一直計算了的；3. 在轉(zhuǎn)屏?xí)r，觸發(fā)的是viewWillLayoutSubview及viewDidLayoutSubview（data not shown）。

由此結(jié)論，我們繼續(xù)往下想，如果我們要改變self.view的frame值，我們應(yīng)當(dāng)在哪個方法中修改呢？很容易想到的是，init和viewDidLoad中是不行的，實踐證明，在viewWillAppear中也是不行的，要在viewDidAppear/viewWillLayoutSubviews/viewDidLayoutSubviews方法中修改才能產(chǎn)生效果。

看起來越來越復(fù)雜了……對了，以上的結(jié)論對iOS5和6是通用的。下面開始研究轉(zhuǎn)屏，轉(zhuǎn)屏對iOS5和6來說，差別就大了。

先看iOS5

iOS5的時候，轉(zhuǎn)屏函數(shù)主要是這幾個：(補(bǔ)：其實還有一個willAnimationRotationToInterfaceOrientation:duration:，調(diào)用時機(jī)在viewDidLayoutSubviews之后，didRotation之前)

-(BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation

{

NSLog(@"shouldRotate");

return YES;

} //以下簡稱shouldRotate

-(void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration

{

NSLog(@"willRotate");

}

-(void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation

{

NSLog(@"didRotate");

}

初始化一個正常viewController時轉(zhuǎn)屏函數(shù)的調(diào)用過程如下：

2012-11-18 16:40:58.090 testRotation[1874:c07] init

2012-11-18 16:40:58.091 testRotation[1874:c07] shouldRotate

2012-11-18 16:40:58.092 testRotation[1874:c07] didLoad

2012-11-18 16:40:58.092 testRotation[1874:c07] shouldRotate

2012-11-18 16:40:58.093 testRotation[1874:c07] willappear

2012-11-18 16:40:58.093 testRotation[1874:c07] shouldRotate

2012-11-18 16:40:58.094 testRotation[1874:c07] willlayout

2012-11-18 16:40:58.095 testRotation[1874:c07] didlayout

2012-11-18 16:40:58.096 testRotation[1874:c07] didappear

我的媽呀，初始化一個vc怎么調(diào)用了三次shouldRotate方法……（別著急，三次算什么，這種情況下調(diào)用幾次都有可能……）

如果初始化vc是在一個navigationController下，看起來還比較正常：

2012-11-19 20:42:42.037 testRotation[462:c07] init

2012-11-19 20:42:42.039 testRotation[462:c07] didload

2012-11-19 20:42:42.040 testRotation[462:c07] willappear

2012-11-19 20:42:42.041 testRotation[462:c07] shouldRotate

2012-11-19 20:42:42.042 testRotation[462:c07] didappear

2012-11-19 20:42:42.042 testRotation[462:c07] willlayout

2012-11-19 20:42:42.043 testRotation[462:c07] didlayout

shouldRotate在willAppear之后調(diào)用一次。

無論有navigationController與否，再轉(zhuǎn)一下屏后，方法調(diào)用過程是一樣的：

2012-11-19 20:51:00.729 testRotation[527:c07] shouldRotate

2012-11-19 20:51:00.730 testRotation[527:c07] willRotate

2012-11-19 20:51:00.731 testRotation[527:c07] willlayout

2012-11-19 20:51:00.731 testRotation[527:c07] didlayout

2012-11-19 20:51:00.732 testRotation[527:c07] shouldRotate

2012-11-19 20:51:01.133 testRotation[527:c07] didRotate

注意，shouldRotate方法依然被調(diào)用了兩次。

為了把shouldRotate方法的調(diào)用次數(shù)以及這幾次調(diào)用的返回值有什么用搞明白，我做了個實驗，詳細(xì)過程不贅述，只說結(jié)論。結(jié)論是一個壞消息和一個好消息：壞消息是，shouldRotate方法可能調(diào)用很多次（只出現(xiàn)在非navigationController方式直接將vc作為rootViewController的情況），我最多遇到過連續(xù)調(diào)用6次的，弄的我一頭霧水，具體原因尚不詳；好消息是，無論在哪個階段調(diào)用多少次，起決定作用的只有willAppear調(diào)用后，willLayoutSubviews調(diào)用前shouldRotate的最后一次調(diào)用，其余階段返回yes還是no都不重要。

再看iOS6

iOS6對轉(zhuǎn)屏邏輯做了修改，去掉了原來的shouldRotate方法，代之以新的幾個方法，具體可看這篇blog，介紹很詳細(xì)，不再贅述，做一些補(bǔ)充：

-(BOOL)shouldAutorotate

{

return YES;

}

-(NSUInteger)supportedInterfaceOrientations

{

return UIInterfaceOrientationMaskAll;

}

-(UIInterfaceOrientation)preferredInterfaceOrientationForPresentation

{

return UIInterfaceOrientationLandscapeRight;

}

這3個方法代替了原來的shouldRotate方法，但并不是換湯不換藥。

iOS6把轉(zhuǎn)屏的邏輯判斷放到了rootViewController里，也就是說，無論當(dāng)前顯示的是那個子vc，都是rootViewController響應(yīng)轉(zhuǎn)屏事件（或者present出來的modalViewController也可以，總之是最根部的vc才行），而且不向下傳遞。直接在一個childViewController里寫這幾個方法，是根本不會被調(diào)用到的。這就帶來一個問題，根vc的轉(zhuǎn)屏邏輯直接決定了子vc的轉(zhuǎn)屏邏輯，如果老子說這個方向支持，那兒子只好支持，而且所有的兒子還都得支持。解決這個專制問題，可以在根vc里這樣寫：

-(BOOL)shouldAutorotate

{

return [self.topViewController shouldAutorotate];

}

-(NSUInteger)supportedInterfaceOrientations

{

return [self.topViewController supportedInterfaceOrientations];

}

讓老子每次轉(zhuǎn)屏被問到的時候，都親自問下他現(xiàn)在正在活躍的子孫。

轉(zhuǎn)屏?xí)r調(diào)用順序跟iOS5一樣，不過shouldRotate被順序拆分為shouldAutoRotate和supported。并且如果shouldAutoRotate返回了NO，則轉(zhuǎn)屏過程中斷，不再繼續(xù)執(zhí)行supported。

最后說到強(qiáng)制橫屏。

iOS5和6都有這個問題，如果我們采用presentViewController的方式展示一個vc，那么我們是可以在進(jìn)入vc的時候控制present的方向的。但是如果我們采用的是pushViewController的方式，問題就出現(xiàn)了，無論我們用何種方式設(shè)置這個vc支持的屏幕方向，都只能在轉(zhuǎn)屏的時候進(jìn)行調(diào)整，而無法在第一次進(jìn)入這個vc的時候調(diào)整。也就是說，豎屏push進(jìn)入一個只支持橫屏的vc，顯示依然是豎屏，但當(dāng)轉(zhuǎn)橫屏之后，就轉(zhuǎn)不回豎屏了。

這顯然不對，解決這個問題，要么用私有API setOrientation: 這個顯然是風(fēng)險太大的。比較好的解決方式就是檢測屏幕方向，然后用view.transform去人工轉(zhuǎn)view，setStatusBarOrientation。這里面要注意幾個要點：

1. view.transform的makeRotation方式轉(zhuǎn)view是中心點center不動，view旋轉(zhuǎn)。

2. 旋轉(zhuǎn)過后view的frame會改變，所以要人工調(diào)整，這里計算frame的新位置和尺寸是重點。由于是人工轉(zhuǎn)屏，改變電池條的方向并不會改變view的坐標(biāo)系，所以一切要在原坐標(biāo)系里算。

3. view轉(zhuǎn)屏退出后要記得用identity恢復(fù)之前view轉(zhuǎn)過的狀態(tài)。

4. 最坑爹的一點是，用setStatusBarOrientation:animated:方法來設(shè)置電池條方向時，在iOS5下沒有問題，但在iOS6下，這個方法會調(diào)用rootvc的shouldAutoRotate（相當(dāng)于一次轉(zhuǎn)屏判斷），如果shouldAutoRotate返回YES（無論supported返回什么），電池條方向都不會被設(shè)定！非常坑，所以邏輯要想好，比如可以通過一個bool值判斷是在改變電池條方向還是系統(tǒng)轉(zhuǎn)屏，如果是前者，返回個NO騙騙它……

5. 在哪個方法里處理轉(zhuǎn)屏，設(shè)置電池條方向，以及在哪個方法里調(diào)整view的frame，都是很重要的，要視你的view是怎么push進(jìn)來的（有rootvc還是本身就是），要具體情況具體分析。中心思想是：比如強(qiáng)制要求橫屏，則在橫屏進(jìn)入的時候，直接用系統(tǒng)轉(zhuǎn)屏邏輯限制方向即可；而在豎屏進(jìn)入時，禁用系統(tǒng)轉(zhuǎn)屏邏輯，人工將view旋轉(zhuǎn)至需要的方向，而后再轉(zhuǎn)為橫屏?xí)r，可采用兩種方式，一是恢復(fù)原本view方向后重新開啟系統(tǒng)轉(zhuǎn)屏邏輯，二是繼續(xù)根據(jù)方向人工轉(zhuǎn)屏。設(shè)計這個過程代碼時，明確之前研究的frame尺寸應(yīng)該什么時候重設(shè)以及各個view方法的執(zhí)行順序，是必須的。

5. iOS5和6要區(qū)分處理。總之，強(qiáng)制橫屏絕對不是網(wǎng)上隨處可見的transform一下然后重設(shè)一下bound就ok了的事情。

附上一種強(qiáng)制橫屏實現(xiàn)的代碼：

// 強(qiáng)制橫屏的一種實現(xiàn)

// 使用方法：

// 在vc的init方法中調(diào)用initLogic

// 在vc關(guān)閉之前調(diào)用cleanRotateTrace方法

-(void)initLogic

{

isPortraitIn_ = NO;

isSettingStatusBar_ = NO;

}

-(BOOL)shouldAutorotate

{

if (isSettingStatusBar_)

{

return NO;

}

return YES;

}

-(NSUInteger)supportedInterfaceOrientations

{

return UIInterfaceOrientationMaskLandscape;

}

-(BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation

{

return ((toInterfaceOrientation == UIInterfaceOrientationLandscapeLeft)||(toInterfaceOrientation == UIInterfaceOrientationLandscapeRight));

}

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration

{

if (isPortraitIn_)

{

self.view.transform = CGAffineTransformIdentity;

isPortraitIn_ = NO;

}

- (void)cleanRotationTrace

{

if (isPortraitIn_)

{

self.view.transform = CGAffineTransformIdentity;

isPortraitIn_ = NO;

UIInterfaceOrientation orientation = [UIApplication sharedApplication].statusBarOrientation;

if (orientation == UIInterfaceOrientationLandscapeRight)

{

isSettingStatusBar_ = YES;

[[UIApplication sharedApplication] setStatusBarOrientation:UIInterfaceOrientationPortrait animated:NO];

isSettingStatusBar_ = NO;

}

else

{

isSettingStatusBar_ = YES;

[[UIApplication sharedApplication] setStatusBarOrientation:UIInterfaceOrientationPortraitUpsideDown animated:NO];

isSettingStatusBar_ = NO;

}

[self.view setFrame:CGRectMake(0, 0, self.view.frame.size.height + 20, self.view.frame.size.width - 20)];

}

-(void)viewDidAppear:(BOOL)animated

{

[super viewDidAppear:animated];

UIInterfaceOrientation orientation = [UIApplication sharedApplication].statusBarOrientation;

if (UIInterfaceOrientationIsPortrait(orientation))

{

isPortraitIn_ = YES;

self.view.transform = CGAffineTransformMakeRotation(M_PI_2);

if (orientation == UIInterfaceOrientationPortrait)

{

isSettingStatusBar_ = YES;

[[UIApplication sharedApplication] setStatusBarOrientation:UIInterfaceOrientationLandscapeRight animated:NO];

isSettingStatusBar_ = NO;

}

else

{

isSettingStatusBar_ = YES;

[[UIApplication sharedApplication] setStatusBarOrientation:UIInterfaceOrientationLandscapeLeft animated:NO];

isSettingStatusBar_ = NO;

}

[self.view setFrame:CGRectMake(0, -20, self.view.frame.size.height - 20, self.view.frame.size.width + 20)];

}

雖然強(qiáng)制橫屏的中心思想都差不多，但具體實現(xiàn)方式可以有很多種，我自己寫過兩種，效果都差不多，代碼簡潔程度不同。這些實現(xiàn)目前我都沒有解決的問題是轉(zhuǎn)屏的動畫，用系統(tǒng)邏輯的部分沒有問題，但如果是豎屏進(jìn)入強(qiáng)制橫屏的，在第一次轉(zhuǎn)到真正橫屏的時候，電池條的轉(zhuǎn)動與view的轉(zhuǎn)動是不同步的，動畫很難看，之后再轉(zhuǎn)就又是系統(tǒng)轉(zhuǎn)屏沒有問題了。

這個動畫問題我至今能夠想到的唯一解決方法是完全不用系統(tǒng)轉(zhuǎn)屏，而是所有的轉(zhuǎn)屏都自己寫。求更好解決方案。

到此為止。

最后編輯于：2017.12.10 10:51:17

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 228,936評論 6贊 535
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機(jī)，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 98,744評論 3贊 421
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事。” “怎么了？”我有些...
開封第一講書人閱讀 176,879評論 0贊 381
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長。經(jīng)常有香客問我，道長，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 63,181評論 1贊 315
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當(dāng)我...
茶點故事閱讀 71,935評論 6贊 410
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 55,325評論 1贊 324
城市分裂傳說
那天，我揣著相機(jī)與錄音，去河邊找鬼。笑死，一個胖子當(dāng)著我的面吹牛，可吹牛的內(nèi)容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 43,384評論 3贊 443
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
開封第一講書人閱讀 42,534評論 0贊 289
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
沈念sama閱讀 49,084評論 1贊 335
?護(hù)林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點故事閱讀 40,892評論 3贊 356
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了。大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 43,067評論 1贊 371
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 38,623評論 5贊 362
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜，卻給世界環(huán)境...
茶點故事閱讀 44,322評論 3贊 347
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 34,735評論 0贊 27
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 35,990評論 1贊 289
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個月前我還...
沈念sama閱讀 51,800評論 3贊 395
代替公主和親
正文我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當(dāng)晚...
茶點故事閱讀 48,084評論 2贊 375

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

(轉(zhuǎn))從ViewController初始化一直談到強(qiáng)制橫屏

(轉(zhuǎn))從ViewController初始化一直談到強(qiáng)制橫屏

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

(轉(zhuǎn))從ViewController初始化一直談到強(qiáng)制橫屏

推薦閱讀更多精彩內(nèi)容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频