iOS多線程 - GCD 詳解

前言


嘿嘿嘿,精品。


之前寫了一篇iOS多線程匯總,地址如下
http://www.lxweimin.com/p/2642138d6bef
這里對GCD進行詳細補充

概述


全稱是Grand Central Dispatch,可譯為“牛逼的中樞調度器”。
純C語言,提供了非常多強大的函數。

優勢


GCD是蘋果公司為多核的并行運算提出的解決方案
GCD會自動利用更多的CPU內核(比如雙核、四核)
GCD會自動管理線程的生命周期(創建線程、調度任務、銷毀線程)
程序員只需要告訴GCD想要執行什么任務,不需要編寫任何線程管理代碼

任務和隊列


GCD中有兩個核心概念

  • 任務:執行什么操作
  • 隊列:用來存放任務

使用GCD兩個步驟

  • 定制任務
    • 確定想做的事
  • 確定想做的事情,將任務添加到隊列中
    • GCD會自動將隊列中的任務取出,放到對應的線程中執行。

GCD會自動將隊列中的任務取出,放到對應的線程中執行
任務的取出遵循隊列的FIFO原則:先進先出,后進后出

執行任務

  • GCD中有兩個用來執行任務的函數
    • 用同步的方式執行任務
// queue:隊列
// block:任務

dispatch_sync(dispatch_queue_t queue, dispatch_block_t block);
  • 用異步的方式執行任務
dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
  • 同步和異步的區別
    • 同步:只能在當前線程中執行任務,不具備開啟新線程的能力

    • 異步:可以在新的線程中執行任務,具備開啟新線程的能力

添加隊列

  • GCD的隊列可以分為兩大類型

    • 并發隊列(Concurrent Dispatch Queue)

      • 可以讓多個任務并發(同時)執行(自動開啟多個線程同時執行任務)
      • 并發功能只有在異步(dispatch_async)函數下才有效
    • 串行隊列(Serial Dispatch Queue)

      • 讓任務一個接著一個地執行(一個任務執行完畢后,再執行下一個任務)

易混術語

  • 有4個術語比較容易混淆:同步、異步、并發、串行

  • 同步和異步主要影響:能不能開啟新的線程

    • 同步:在當前線程中執行任務,不具備開啟新線程的能力

    • 異步:在新的線程中執行任務,具備開啟新線程的能力

  • 并發和串行主要影響:任務的執行方式

    • 并發:多個任務并發(同時)執行

    • 串行:一個任務執行完畢后,再執行下一個任務

并發隊列

  • GCD默認已經提供了全局的并發隊列,供整個應用使用,不需要手動創建

  • 使用dispatch_get_global_queue函數獲得全局的并發隊列

dispatch_queue_t dispatch_get_global_queue(
dispatch_queue_priority_t priority, // 隊列的優先級
unsigned long flags); // 此參數暫時無用,用0即可
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); // 獲得全局并發隊列
  • 手動創建并發隊列
    • 參數1:隊列標識
    • 參數2:隊列類型
dispatch_queue_t concurrentQueue = dispatch_queue_create("CONCURRENT", DISPATCH_QUEUE_CONCURRENT);
  • 全局并發隊列的優先級
#define DISPATCH_QUEUE_PRIORITY_HIGH 2 // 高
#define DISPATCH_QUEUE_PRIORITY_DEFAULT 0 // 默認(中)
#define DISPATCH_QUEUE_PRIORITY_LOW (-2) // 低
#define DISPATCH_QUEUE_PRIORITY_BACKGROUND INT16_MIN // 后臺

串行隊列

  • GCD中獲得串行有兩種途徑

    • 手動創建串行隊列

    • 使用dispatch_queue_create函數創建串行隊列

// "SERIAL" 是一個標識符,可以自己填寫,通常填寫com.公司的域名
dispatch_queue_t serialQueue = dispatch_queue_create("SERIAL", DISPATCH_QUEUE_SERIAL);
// 或者
dispatch_queue_t serialQueue = dispatch_queue_create("SERIAL", NULL);
dispatch_release(queue); // 非ARC需要釋放手動創建的隊列


- 使用主隊列(跟主線程相關聯的隊列)

- 主隊列是GCD自帶的一種特殊的串行隊列

- 放在主隊列中的任務,都會放到主線程中執行

- 使用dispatch_get_main_queue()獲得主隊列

dispatch_queue_t queue = dispatch_get_main_queue();


####各種隊列的執行效果

![](http://upload-images.jianshu.io/upload_images/2595997-971676ca92a8a6fa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

![](http://upload-images.jianshu.io/upload_images/2595997-cf291e35f32f7629.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

- 小知識:同步函數立刻執行,異步函數會等待自身所存在方法結束后才執行。

- 注意:
  - 使用sync函數往當前串行隊列中添加任務,會卡住當前的串行隊列,叫做死鎖(有些像把串行隊列嵌套)(下面會做詳細說明).。

#死鎖
------
#### 搞清線程(Thread)和隊列(Queue)的區別
網上一些講解關于GCD死鎖的文章,有一些非常明顯的錯誤,比如:認為死鎖的原因是線程阻塞造成的,這是非常大的誤解,GCD死鎖的原因是隊列阻塞,而不是線程阻塞!


![](http://upload-images.jianshu.io/upload_images/2595997-e0dbda73028aa1b7.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在開發中,我們會把block,也就是我們想做的任務,交給GCD函數。GCD函數會把任務放進我們指定的隊列(Queue),當然GCD函數內部不止是把任務放進隊列,還包括一些其他不為我們所知的操作。隊列遵循嚴格的先進先出原則,同一個Queue中,最早入列的block,會最早被分配給線程執行。系統(“系統”指所有被蘋果黑盒封裝,未公開源碼,我們不能得知的操作,下同)會依據順序從隊列中取出block,并且交由線程執行。GCD隊列只是組織待執行任務的一個數據結構封裝,而線程,才是執行任務的人。

#### 程序執行順序

要往下面講,不得不回顧一個再基礎不過的知識點,我想,這是每一個程序員,入門就知道的超級簡單的知識。雖然它非常基礎,但是,這正是造成我們GCD死鎖的重要因素。很多困難的問題,它們背后隱藏的東西往往非常簡單,因為事物永遠不會脫離本質。

讓我們來看看下面的這個C程序:

include <stdio.h>

void printFiveNumbers(){
printf("開始執行printFiveNumbers函數了\n");
for (int i = 0; i < 5; i++) {
printf("printFiveNumbers - %d\n",i);
}
printf("執行完printFiveNumbers函數了\n");
}

//main函數是程序的入口
int main(){
printf("main函數開始執行了\n");
printFiveNumbers();
printf("main函數執行完了\n");
return 0;
}



![](http://upload-images.jianshu.io/upload_images/2595997-4579d283d6031841.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

大家都知道,運行的結果是怎么樣了,程序的入口是main函數,于是Run這個程序后,馬上就會進入main函數執行,執行了第一句打印后,會跳入printFiveNumbers這個函數執行,直到printFiveNumbers執行完,才會返回到main函數繼續執行下一句。重點是:外層方法會等待內層方法返回后,再執行下一句指令。就好像把printFiveNumbers函數的所有語句,都復制粘貼到了main方法里一樣。

#### GCD死鎖的本質

讓我們看看下面這個程序:

override func viewDidLoad() {
super.viewDidLoad()
print("Start (NSThread.currentThread())")
//GCD同步函數
dispatch_sync(dispatch_get_main_queue(), {
for i in 0...100{
print("(i) (NSThread.currentThread())")
}
})
print("End (NSThread.currentThread())")
}


![](http://upload-images.jianshu.io/upload_images/2595997-3b6780b255265357.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)


這個程序就是典型的死鎖,可以看到,只打印了“Start”一行,就再也沒有響應了,已經造成了GCD死鎖。為什么會這樣呢?讓我們來解讀一下這段程序的運行順序:首先會打印“Start”,然后將主隊列和一個block傳入GCD同步函數dispatch_sync中,等待sync函數執行,直到它返回,才會執行打印“End”的語句。可是,竟然沒有反應了?block中的101個數字沒有被打印出來任何一個,viewDidLoad()中的End也沒有被打印出來。也就是說,block沒有得到執行的機會,viewDidLoad也沒有繼續執行下去。為什么block不執行呢?因為viewDidLoad也是執行在主隊列的,它是正在被執行的任務,也就是說,viewDidLoad()是主隊列的隊頭。主隊列是串行隊列,任務不能并發執行,同時只能有一個任務在執行,也就是隊頭的任務才能被出列執行。我們現在被執行的任務是viewDidLoad(),然后我們又將block入列到同一個隊列,它比viewDidLoad()后入列,遵循先進先出的原理,它必須等到viewDidLoad()執行完,才能被執行。但是,dispatch_sync函數的特性是,等待block被執行完畢,才會返回,因此,只要block一天不被執行,它就一天不返回。我們知道,內部方法不返回,外部方法是不會執行下一行命令的。不等到sync函數返回,viewDidLoad打死也不會執行print End的語句,因此,viewDidLoad()一直沒有執行完畢。block在等待著viewDidLoad()執行完畢,它才能上,sync函數在等待著block執行完畢,它才能返回,viewDidLoad()在等待著sync函數返回,它才能執行完畢。這樣的三方循環等待關系,就造成了死鎖。


也許文字描述比較抽象,我們再來配一幅圖:

![](http://upload-images.jianshu.io/upload_images/2595997-8ee6429e8fef13b6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

可以這么理解:每一個隊列,有自己的執行室,串行隊列的執行室,只能容納一個任務,并發隊列的執行室,可以同時容納若干個任務。隊頭的任務,只要執行室有空位,就會被放入執行室執行。viewDidLoad任務在執行中,我們的主隊列又是串行隊列,執行室只能容納一個任務,那么隊頭的block就需要等待viewDidLoad執行完畢才能進入執行室,那么就造成了,viewDidLoad永遠不會執行完畢,block永遠不能執行。

![](http://upload-images.jianshu.io/upload_images/2595997-9ab1702b34fc39b9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

sync函數永遠不能返回,最終,就是GCD死鎖。

- 那么我們可以總結出GCD被阻塞(blocking)的原因有以下兩點:
    1. GCD函數未返回,會阻塞正在執行的任務

    2. 隊列的執行室容量太小,在執行室有空位之前,會阻塞同一個隊列中在等待的任務

- 注意:阻塞(blocking)和死鎖(deadlock)是不同的意思,阻塞表示需要等待A事件完成后才能完成B事件,稱作A會阻塞B,通俗來講就是強制等待的意思。而死鎖表示由于某些互相阻塞,也就是互相的強制等待,形成了閉環,導致大家永遠互相阻塞下去了,Always and Forever,也就是死鎖。

#### 解決GCD死鎖
我們已經有結論,造成GCD死鎖,是由于同時具備以下兩點因素:
1. GCD函數未返回,會阻塞正在執行的任務

2. 隊列的執行室容量太小,在執行室有空位之前,會阻塞同一個隊列中在等待的任務

死鎖是由于阻塞閉環造成的,那么我們只用消除其中一個因素,就能打破這個閉環,避免死鎖。

#######方法1: 解決GCD函數未返回造成的阻塞

- 先提出下面兩個知識點:
  - dispatch_sync是同步函數,不具備開啟新線程的能力,交給它的block,只會在當前線程執行,不論你傳入的是串行隊列還是并發隊列,并且,它一定會等待block被執行完畢才返回。
  - dispatch_async是異步函數,具備開啟新線程的能力,但是不一定會開啟新縣城,交給它的block,可能在任何線程執行,開發者無法控制,是GCD底層在控制。它會立即返回,不會等待block被執行。



- 注意:以上兩個知識點,有例外,那就是當你傳入的是主隊列,那兩個函數都一定會安排block在主線程執行。記住,主隊列是最特殊的隊列

只要看懂了以上兩個知識點,大家就知道,sync函數未返回會造成阻塞,只要換成aysnc函數,就會立即返回,而不會等待block執行,那么GCD函數未返回這個阻塞因素就會被解決掉。不用大家也不要盲目的換函數,畢竟兩個函數是有不同之處的,要考慮實際期望。


#######方法2: 解決隊列(Queue)阻塞
解決隊列阻塞,有兩種方法:

1. 為隊列的執行室擴容,讓它可以并發執行多個任務,那么就不會因為A任務,造成B任務被阻塞了。
2. 把A和B任務放在兩個不同的隊列中,A就再也沒有機會阻塞B了。因為每個隊列都有自己的執行室。

首先來說第一個思路,如何為隊列的執行室擴容呢?我們當然沒有辦法為執行室擴容,但是我們可以選擇用容量大的隊列。使用并發隊列替代串行隊列。因為并發隊列的執行室可以同時容納若干任務


再來說第二個思路,我們來看代碼:

override func viewDidLoad() {
super.viewDidLoad()
print("Start (NSThread.currentThread())")
let serialQueue = dispatch_queue_create("這是一個串行隊列", DISPATCH_QUEUE_SERIAL)
dispatch_sync(serialQueue, {
for i in 0...100{
print("(i) (NSThread.currentThread())")
}
})
print("End (NSThread.currentThread())")
}


![](http://upload-images.jianshu.io/upload_images/2595997-85381d8d2ab036b5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

我們自己新建了一個串行隊列,將block放入自己的串行隊列,不再和viewDidLoad()處于一個隊列,解決了隊列阻塞,因此避免了死鎖問題。
網上有一些帖子說“在主線程使用sync函數就會造成死鎖”或者“在主線程使用sync函數,同時傳入串行隊列就會死鎖”,都是非常錯誤的觀念,希望大家能夠真正理解GCD死鎖的原理,而不是死記硬背。


# 其他
-----

 GCD還有一些其他用法,這里也都提一下。

####  線程間通信示例


從子線程回到主線程


dispatch_async(
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 執行耗時的異步操作...
dispatch_async(dispatch_get_main_queue(), ^{
// 回到主線程,執行UI刷新操作
});
});


#### 快速迭代
快速遍歷,當我們需要遍歷一些耗時操作,需要它們同時進行,可以使用dispatch_apply,比如下面的例子是把一個文件夾中的所有文件剪切到另一個文件夾中,所有文件近乎同時剪切。
  • (void)apply
    {
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    NSString *from = @"/Users/Ostkaka/Desktop/From";
    NSString *to = @"/Users/Ostkaka/Desktop/To";

    NSFileManager *mgr = [NSFileManager defaultManager];
    NSArray *subpaths = [mgr subpathsAtPath:from];

    dispatch_apply(subpaths.count, queue, ^(size_t index) {
    NSString *subpath = subpaths[index];
    NSString *fromFullpath = [from stringByAppendingPathComponent:subpath];
    NSString *toFullpath = [to stringByAppendingPathComponent:subpath];
    // 剪切
    [mgr moveItemAtPath:fromFullpath toPath:toFullpath error:nil];

      NSLog(@"%@---%@", [NSThread currentThread], subpath);
    

    });
    }


#### 柵欄
如果不加dispatch_barrier_async()這行代碼,會開辟四條線程無序執行,添加之后會先執行它之前的,結束后執行它之后的。

不過注意一點,這里一定要創建新的并發隊列,用global是不可以的。

  • (void)barrier
    {
    dispatch_queue_t queue = dispatch_queue_create("test", DISPATCH_QUEUE_CONCURRENT);

    dispatch_async(queue, ^{
    NSLog(@"----1-----%@", [NSThread currentThread]);
    });
    dispatch_async(queue, ^{
    NSLog(@"----2-----%@", [NSThread currentThread]);
    });

    dispatch_barrier_async(queue, ^{
    NSLog(@"----barrier-----%@", [NSThread currentThread]);
    });

    dispatch_async(queue, ^{
    NSLog(@"----3-----%@", [NSThread currentThread]);
    });
    dispatch_async(queue, ^{
    NSLog(@"----4-----%@", [NSThread currentThread]);
    });
    }



#### 延時執行

- iOS常見的延時執行有3種方式

  - 調用NSObject的方法

[self performSelector:@selector(run) withObject:nil afterDelay:2.0];
// 2秒后再調用self的run方法

- 使用GCD函數

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2.0 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
// 2秒后異步執行這里的代碼...
});

- NSTimer

[NSTimer scheduledTimerWithTimeInterval:2.0 target:self selector:@selector(run) userInfo:nil repeats:NO];




#### 隊列組

- 有這么1種需求

- 首先:分別異步執行2個耗時的操作

- 其次:等2個異步操作都執行完畢后,再回到主線程執行操作

- 如果想要快速高效地實現上述需求,可以考慮用隊列組

dispatch_group_t group = dispatch_group_create();

dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 執行1個耗時的異步操作
});
dispatch_group_async(group, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 執行1個耗時的異步操作
});
dispatch_group_notify(group, dispatch_get_main_queue(), ^{
// 等前面的異步操作都執行完畢后,回到主線程...
});


#### 一次性代碼

使用dispatch_once函數能保證某段代碼在程序運行過程中只被執行1次

static dispatch_once_t onceToken; //記錄是否被執行
dispatch_once(&onceToken, ^{
// 只執行1次的代碼(這里面默認是線程安全的)
});


#### 單例模式

- 作用
    - 可以保證在程序運行過程,一個類只有一個實例,而且該實例易于供外界訪問,從而方便地控制了實例個數,并節約系統資源

- 使用場合

    - 在整個應用程序中,共享一份資源(這份資源只需要創建初始化1次)

- 單例模式在ARC\MRC環境下的寫法有所不同,需要編寫2套不同的代碼

- 可以用宏判斷是否為ARC環境

if __has_feature(objc_arc)

// ARC

else

// MRC

endif


#### 單例模式(ARC)

// 在.m中保留一個全局的static的實例
static id _instance;

// 重寫allocWithZone:方法,在這里創建唯一的實例(注意線程安全)

  • (id)allocWithZone:(struct _NSZone *)zone
    {
    @synchronized(self) {
    if (!_instance) {
    _instance = [super allocWithZone:zone];
    }
    }
    return _instance;
    }

提供1個類方法讓外界訪問唯一的實例

  • (instancetype)sharedSoundTool
    {
    @synchronized(self) {
    if (!_instance) {
    _instance = [[self alloc] init];
    }
    }
    return _instance;
    }

實現copyWithZone:方法

  • (id)copyWithZone:(struct _NSZone *)zone
    {
    return _instance;
    }

#### 單例模式 – MRC

- MRC里,單例模式的實現(比ARC多了幾個步驟)

- 實現內存管理方法

  • (id)retain { return self; }
  • (NSUInteger)retainCount { return 1; }
  • (oneway void)release {}
  • (id)autorelease { return self; }

# 心靈雞湯
------

禪房里,這個整日被嫉妒、浮躁、憂慮所困擾的年輕人面對慈祥、超然的禪師,一股腦兒倒出了自己的不幸。禪師笑笑,伸出右手,握成拳頭,“你試試看。”年輕人照做。“再握得緊一些。”“再緊一些······”于是年輕人把拳頭握得越來越緊。“感覺如何?”禪師慈祥的問道。年輕人茫然的搖了搖頭。禪師說:好,現在可以上下動了。


海的平凡是因為它源于一點一滴,海的偉大是因為它能容納千江萬河,還有海鮮. 

![](http://upload-images.jianshu.io/upload_images/2595997-bc7155a7fa32a65b.jpg?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,908評論 6 541
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,324評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,018評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,675評論 1 317
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,417評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,783評論 1 329
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,779評論 3 446
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,960評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,522評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,267評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,471評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,009評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,698評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,099評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,386評論 1 294
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,204評論 3 398
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,436評論 2 378

推薦閱讀更多精彩內容