iOS的Block

存取變量

Block將使用到的咒彤、作用域附近的變量的值建立一份快照拷貝到棧上。

1劈伴、讀取和Block pointer同一個Scope的變量值：

{  
    int outA = 8;  
    int (^myPtr)(int) = ^(int a){ return outA + a;};  
    //block里面可以讀取同一類型的outA的值  
    int result = myPtr(3);  // result is 11  
    NSLog(@"result=%d", result);  
}

下面這一段代碼就不一樣了

{
    int outA = 8;  
    int (^myPtr)(int) = ^(int a){ return outA + a;}; //block里面可以讀取同一類型的outA的值  
    outA = 5;  //在調(diào)用myPtr之前改變outA的值  
    int result = myPtr(3);  // result的值仍然是11密末，并不是8  
    NSLog(@"result=%d", result);  
}

為什么result 的值仍然是11握爷？而不是8呢？事實上严里，myPtr在其主體中用到的outA這個變量值的時候做了一個copy的動作新啼，把outA的值copy下來，在Block中作為常量使用刹碾。所以燥撞，之后outA即使換成了新的值，對于myPtr里面copy的值是沒有影響的迷帜。（類似于深拷貝）

需要注意的是物舒，這里copy的值是變量的值，如果它是一個記憶體的位置（地址）戏锹，換句話說冠胯，就是這個變量是個指針的話，它的值是可以在block里被改變的锦针。(相當于淺拷貝荠察，拷貝的只是一個指針地址，對象地址還是沒變的)

{  
    NSMutableArray \*mutableArray = [NSMutableArray arrayWithObjects:@"one", @"two", @"three", nil];  
    int result = ^(int a){[mutableArray removeLastObject]; return a*a;}(5);  
    NSLog(@"test array :%@", mutableArray);  
}  
    
//原本mutableArray的值是{@"one",@"two",@"three"}奈搜，在block里面被更改mutableArray后悉盆，就變成{@"one", @"two"}了。

2媚污、直接存取static類型的變量

因為全局變量或靜態(tài)變量在內(nèi)存中的地址是固定的舀瓢，Block在讀取該變量值的時候是直接從其所在內(nèi)存讀出，獲取到的是最新值耗美，而不是在定義時copy的常量京髓。

{  
    static int outA = 8;  
    int (^myPtr)(int) = ^(int a){return outA + a;};  
    outA = 5;  
    int result = myPtr(3);  
    //result的值是8，因為outA是static類型的變量 (該變量在全局數(shù)據(jù)區(qū)分配內(nèi)存,但作用域還是局部作用域) 
    NSLog(@"result=%d", result);     
}

3商架、Block Variable類型的變量

在某個變量前面如果加上修飾字“__block”的話（注意堰怨，block前面有兩個下劃線），這個變量就稱作block variable蛇摸”竿迹基本類型的Block變量等效于全局變量、或靜態(tài)變量赶袄。

那么在block里面就可以任意修改此變量的值揽涮，如下代碼：

{  
    __block int num = 5;  
      
    int (^myPtr)(int) = ^(int a){return num++;};  
    int (^myPtr2)(int) = ^(int a){return num++;};  
    int result = myPtr(0);   //result的值為5，num的值為6  
    result = myPtr2(0);      //result的值為6饿肺，num的值為7  
    NSLog(@"result=%d", result);      
}

4蒋困、weak–strong dance（避免循環(huán)引用）

  • 使用方將self或成員變量加入block之前要先將self變?yōu)開_weak
  • 在多線程環(huán)境下（block中的weakSelf有可能被析構(gòu)的情況下），需要先將self轉(zhuǎn)為strong指針敬辣，避免在運行到某個關(guān)鍵步驟時self對象被析構(gòu)雪标。
    以上兩條合起來有個名詞叫weak–strong dance

以下是使用weak–strong dance的經(jīng)典代碼

__weak __typeof(self)weakSelf = self和
__strong __typeof(weakSelf)strongSelf = weakSelf

//AFNetworking經(jīng)典代碼
__weak __typeof(self)weakSelf = self;
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
    __strong __typeof(weakSelf)strongSelf = weakSelf;
    strongSelf.networkReachabilityStatus = status;
    if (strongSelf.networkReachabilityStatusBlock) {
        strongSelf.networkReachabilityStatusBlock(status);
    }
};

其中用到了__typeof(self)零院，這里涉及幾個知識點：

  • __typeof、___typeof___ 村刨、typeof的區(qū)別
    恩~~他們沒有區(qū)別告抄，但是這牽扯一段往事，在早期C語言中沒有typeof這個關(guān)鍵字嵌牺，__typeof打洼、__typeof__是在C語言的擴展關(guān)鍵字的時候出現(xiàn)的。typeof是現(xiàn)代GNU C++的關(guān)鍵字髓梅，從Objective-C的根源說拟蜻，他其實來自于C語言，所以AFNetworking使用了繼承自C的關(guān)鍵字枯饿。

  • 對于老的LLVM編譯器上面這句話會編譯報錯，所以在很早的ARC使用者中流行__typeof(&*self)這種寫法诡必，原因如下

第四奢方、五、六行爸舒，如果不轉(zhuǎn)成strongSelf而使用weakSelf蟋字，后面幾句話中，有可能在第四句執(zhí)行之后self的對象可能被析構(gòu)掉扭勉，然后后面的StausBlock沒有執(zhí)行鹊奖，導致邏輯錯誤。

大致說法是老LLVM編譯器會將__typeof轉(zhuǎn)義為 XXX類名 const __strong的__strong和前面的__weak關(guān)鍵字對指針的修飾又沖突了涂炎，所以加上&對指針的修飾忠聚。

為了使用方便我們可以用一份宏定義

#ifndef weakify
    #if DEBUG
        #if __has_feature(objc_arc)
        #define weakify(object) autoreleasepool{} __weak __typeof__(object) weak##_##object = object;
        #else
        #define weakify(object) autoreleasepool{} __block __typeof__(object) block##_##object = object;
        #endif
    #else
        #if __has_feature(objc_arc)
        #define weakify(object) try{} @finally{} {} __weak __typeof__(object) weak##_##object = object;
        #else
        #define weakify(object) try{} @finally{} {} __block __typeof__(object) block##_##object = object;
        #endif
    #endif
#endif

#ifndef strongify
    #if DEBUG
        #if __has_feature(objc_arc)
        #define strongify(object) autoreleasepool{} __typeof__(object) object = weak##_##object;
        #else
        #define strongify(object) autoreleasepool{} __typeof__(object) object = block##_##object;
        #endif
    #else
        #if __has_feature(objc_arc)
        #define strongify(object) try{} @finally{} __typeof__(object) object = weak##_##object;
        #else
        #define strongify(object) try{} @finally{} __typeof__(object) object = block##_##object;
        #endif
    #endif
#endif

//使用方法
@weakify(self);
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
    @strongify(self)
    if(!self)return; 
    self.networkReachabilityStatus = status; 
    if (self.networkReachabilityStatusBlock) {
        self.networkReachabilityStatusBlock(status);
    }
};

因為對象obj在Block被copy到堆上的時候自動retain了一次。因為Block不知道obj什么時候被釋放唱捣，為了不在Block使用obj前被釋放两蟀，Block retain了obj一次，在Block被釋放的時候震缭，obj被release一次赂毯。

retain cycle問題的根源在于Block和obj可能會互相強引用，互相retain對方拣宰，這樣就導致了retain cycle党涕，最后這個Block和obj就變成了孤島，誰也釋放不了誰巡社。

黑幕背后的__block修飾符

我們知道在Block使用中膛堤，Block內(nèi)部能夠讀取外部局部變量的值。但我們需要改變這個變量的值時重贺，我們需要給它附加上__block修飾符骑祟。

__block另外一個比較多的使用場景是回懦，為了避免某些情況下Block循環(huán)引用的問題，我們也可以給相應對象加上__block 修飾符次企。

為什么不使用__block就不能在Block內(nèi)部修改外部的局部變量怯晕？

我們把以下代碼通過 clang -rewrite-objc 源代碼文件名重寫：

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        int val = 10;
        void (^block)(void) = ^{
            NSLog(@"%d", val);
        };
        block();
    }
    return 0;
}

得到如下代碼:

struct __main_block_impl_0 {
  struct __block_impl impl;
  struct __main_block_desc_0* Desc;
  int val;
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int _val, int flags=0) : val(_val) {
    impl.isa = &_NSConcreteStackBlock;
    impl.Flags = flags;
    impl.FuncPtr = fp;
    Desc = desc;
  }
};
static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
  int val = __cself->val; // bound by copy
  NSLog((NSString *)&__NSConstantStringImpl__val_folders_gm_0jk35cwn1d3326x0061qym280000gn_T_main_41daf1_mi_0, val);
}
static struct __main_block_desc_0 {
  size_t reserved;
  size_t Block_size;
} __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0)};

int main(int argc, const char * argv[]) {
    /* @autoreleasepool */ { __AtAutoreleasePool __autoreleasepool; 
        int val = 10;
        void (*block)(void) = (void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, val);
        ((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);
    }
    return 0;
}

我們注意到Block實質(zhì)被轉(zhuǎn)換成了一個__main_block_impl_0的結(jié)構(gòu)體實例，其中__main_block_impl_0結(jié)構(gòu)體的成員包括局部變量val缸棵。在__main_block_impl_0結(jié)構(gòu)體的構(gòu)造方法中舟茶，val作為第三個參數(shù)傳遞進入。

但執(zhí)行我們的Block時堵第，通過block找到Block對應的方法執(zhí)行部分__main_block_func_0吧凉，并把當前block作為參數(shù)傳遞到__main_block_func_0方法中。

__main_block_func_0的第一個參數(shù)聲明如下：
struct __main_block_impl_0 *__cself
它和Objective－C的self相同踏志，不過它是指向 __main_block_impl_0 結(jié)構(gòu)體的指針阀捅。這個時候我們就可以通過__cself->val對該變量進行訪問。

因為int val變量定義在棧上针余，在block調(diào)用時其實已經(jīng)被銷毀饲鄙，但是我們還可以正常訪問這個變量。但是試想一下圆雁，如果我希望在block中修改變量的值忍级，那么受到影響的是int val而非__cself->val，事實上即使是__cself->val伪朽，也只是截獲的自動變量的副本轴咱，要想修改在block定義之外的自動變量，是不可能的事情烈涮。

所以朴肺，對于auto類型的局部變量，不允許block進行修改是合理的跃脊。

__block 到底是怎么工作的?

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        __block NSInteger val = 0;
        void (^block)(void) = ^{
            val = 1;
        };
        block();
        NSLog(@"val = %ld", val);
    }
    return 0;
}

可得到如下代碼：

struct __Block_byref_val_0 {
     void *__isa;
     __Block_byref_val_0 *__forwarding;
     int __flags;
     int __size;
     NSInteger val;
};
struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      __Block_byref_val_0 *val; // by ref
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, __Block_byref_val_0 *_val, int flags=0) : val(_val->__forwarding) {
        impl.isa = &_NSConcreteStackBlock;
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
};
static void __main_block_func_0 (struct __main_block_impl_0 *__cself) {
  __Block_byref_val_0 *val = __cself->val; // bound by ref
  (val->__forwarding->val) = 1;
}
static void __main_block_copy_0 (struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {
    _Block_object_assign((void*)&dst->val, (void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}
static void __main_block_dispose_0 (struct __main_block_impl_0*src)     {
    _Block_object_dispose((void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}
static struct __main_block_desc_0 {
  size_t reserved;
  size_t Block_size;
  void (*copy)(struct __main_block_impl_0*, struct __main_block_impl_0*);
  void (*dispose)(struct __main_block_impl_0*);
} __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0), __main_block_copy_0, __main_block_dispose_0};

int main(int argc, const char * argv[]) {
    {   __AtAutoreleasePool __autoreleasepool; 
        __attribute__((__blocks__(byref))) __Block_byref_val_0 val = {(void*)0,(__Block_byref_val_0 *)&val, 0, sizeof(__Block_byref_val_0), 0};
        void (*block)(void) = (void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, (__Block_byref_val_0 *)&val, 570425344);
        ((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);
        NSLog((NSString *)&__NSConstantStringImpl__val_folders_gm_0jk35cwn1d3326x0061qym280000gn_T_main_d7fc4b_mi_0, (val.__forwarding->val));
    }
    return 0;
}

我們發(fā)現(xiàn)由__block修飾的變量變成了一個__Block_byref_val_0結(jié)構(gòu)體類型的實例宇挫。該結(jié)構(gòu)體的聲明如下：

struct __Block_byref_val_0 {
     void *__isa;
     __Block_byref_val_0 *__forwarding;
     int __flags;
     int __size;
     NSInteger val;
};

我們從上述被轉(zhuǎn)化的代碼中可以看出 Block 本身也一樣被轉(zhuǎn)換成了 __main_block_impl_0 結(jié)構(gòu)體實例，該實例持有__Block_byref_val_0結(jié)構(gòu)體實例的指針酪术。
我們再看一下賦值和執(zhí)行部分代碼被轉(zhuǎn)化后的結(jié)果：

static void __main_block_func_0 (struct __main_block_impl_0 *__cself) {
  __Block_byref_val_0 *val = __cself->val; // bound by ref
  (val->__forwarding->val) = 1;
}
((void (*)(__block_impl *))((__block_impl *)block)->FuncPtr)((__block_impl *)block);

我們從__cself找到__Block_byref_val_0結(jié)構(gòu)體實例器瘪，然后通過該實例的__forwarding訪問成員變量val。成員變量val是該實例自身持有的變量绘雁，指向的是原來的局部變量橡疼。如圖所示：

。
1420513789717076.jpg

上面部分我們展示了__block變量在Block查看和修改的過程庐舟，那么問題來了：

當block作為回調(diào)執(zhí)行時欣除，局部變量val已經(jīng)出棧了，這個時候代碼為什么還能正常工作呢?

  • 我們?yōu)槭裁词峭ㄟ^成員變量__forwarding而不是直接去訪問結(jié)構(gòu)體中我們*
  • 需要修改的變量呢? __forwarding被設計出來的原因又是什么呢?

存儲域

通過上面的描述我們知道Block和__block變量實質(zhì)就是一個相應結(jié)構(gòu)體的實例挪略。我們在上述轉(zhuǎn)換過的代碼中可以發(fā)現(xiàn) __main_block_impl_0 結(jié)構(gòu)體構(gòu)造函數(shù)中历帚， isa指向的是 _NSConcreteStackBlock滔岳。Block還有另外兩個與之相似的類:

  • _NSConcreteStackBlock 保存在棧中的block，出棧時會被銷毀
  • _NSConcreteGlobalBlock 全局的靜態(tài)block挽牢，不會訪問任何外部變量
  • _NSConcreteMallocBlock 保存在堆中的block谱煤，當引用計數(shù)為0時會被銷毀

上述示例代碼中，Block是被設為_NSConcreteStackBlock禽拔，在棧上生成刘离。當我們把Block作為全局變量使用時，對應生成的Block將被設為_NSConcreteGlobalBlock睹栖，如:

void (^block)(void) = ^{NSLog(@"This is a Global Block");};
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        block();
    }
    return 0;
}

該代碼轉(zhuǎn)換后的代碼中硫惕，Block結(jié)構(gòu)體的成員變量isa的初始化如下:
impl.isa = &_NSConcreteGlobalBlock;

而_block變量中結(jié)構(gòu)體成員__forwarding就在此時保證了從棧上復制到堆上能夠正確訪問__block變量。在這種情況下野来，只要棧上的_block變量的成員變量__forwarding指向堆上的實例恼除，我們就能夠正確訪問。

我們一般可以使用copy方法手動將 Block 或者 __block變量從棧復制到堆上梁只。比如我們把Block做為類的屬性訪問時缚柳，我們一般把該屬性設為copy。有些情況下我們可以不用手動復制,比如Cocoa框架中使用含有usingBlock方法名的方法時搪锣，或者GCD的API中傳遞Block時。

當一個Block被復制到堆上時彩掐，與之相關(guān)的__block變量也會被復制到堆上构舟，此時堆上的Block持有相應堆上的__block變量。當堆上的__block變量沒有持有者時堵幽，它才會被廢棄狗超。(這里的思考方式和objc引用計數(shù)內(nèi)存管理完全相同。)

而在棧上的__block變量被復制到堆上之后朴下，會將成員變量__forwarding的值替換為堆上的__block變量的地址努咐。這個時候我們可以通過以下代碼訪問:

val.__forwarding->val

如下面:

1420513884222794.jpg

__block變量和循環(huán)引用問題

__block修飾符可以指定任何類型的局部變量，上面的轉(zhuǎn)換代碼中殴胧，有如下代碼:

static void __main_block_copy_0 (struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {
    _Block_object_assign((void*)&dst->val, (void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}
static void __main_block_dispose_0 (struct __main_block_impl_0*src)     {
    _Block_object_dispose((void*)src->val, 8/*BLOCK_FIELD_IS_BYREF*/);
}

當Block從棧復制到堆時渗稍，會使用_Block_object_assign函數(shù)持有該變量(相當于retain)。當堆上的Block被廢棄時团滥，會使用_Block_object_dispose函數(shù)釋放該變量(相當于release)竿屹。

由上文描述可知，我們可以使用下述代碼解除Block循環(huán)引用的問題:

__block id tmp = self;
void(^block)(void) = ^{
    tmp = nil;
};
block();
  • 通過執(zhí)行block方法灸姊，nil被賦值到_block變量tmp中拱燃。這個時候_block變量對 self 的強引用失效，從而避免循環(huán)引用的問題力惯。使用__block變量的優(yōu)點是:
  • 通過__block變量可以控制對象的生命周期碗誉。
    在不能使用__weak修飾符的環(huán)境中召嘶，我們可以避免使用* __unsafe_unretained修飾符。
  • 在執(zhí)行Block時可動態(tài)地決定是否將nil或者其它對象賦值給__block變量哮缺。但是這種方法有一個明顯的缺點就是弄跌，我們必須去執(zhí)行Block才能夠解除循環(huán)引用問題，否則就會出現(xiàn)問題蝴蜓。

參考資料

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末碟绑，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子茎匠，更是在濱河造成了極大的恐慌格仲，老刑警劉巖，帶你破解...
    沈念sama閱讀 218,858評論 6贊 508
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件诵冒，死亡現(xiàn)場離奇詭異凯肋，居然都是意外死亡，警方通過查閱死者的電腦和手機汽馋，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,372評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門侮东，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人豹芯，你說我怎么就攤上這事悄雅。” “怎么了铁蹈？”我有些...
    開封第一講書人閱讀 165,282評論 0贊 356
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵宽闲，是天一觀的道長。 經(jīng)常有香客問我握牧，道長容诬，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 58,842評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任沿腰，我火速辦了婚禮览徒，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘颂龙。我一直安慰自己习蓬，他們只是感情好，可當我...
    茶點故事閱讀 67,857評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布厘托。 她就那樣靜靜地躺著友雳，像睡著了一般。 火紅的嫁衣襯著肌膚如雪铅匹。 梳的紋絲不亂的頭發(fā)上押赊，一...
    開封第一講書人閱讀 51,679評論 1贊 305
  • 城市分裂傳說
    那天，我揣著相機與錄音，去河邊找鬼流礁。 笑死涕俗，一個胖子當著我的面吹牛，可吹牛的內(nèi)容都是我干的神帅。 我是一名探鬼主播再姑，決...
    沈念sama閱讀 40,406評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼找御！你這毒婦竟也來了元镀？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 39,311評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤霎桅，失蹤者是張志新（化名）和其女友劉穎栖疑，沒想到半個月后，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體滔驶，經(jīng)...
    沈念sama閱讀 45,767評論 1贊 315
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡遇革，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,945評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了揭糕。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片萝快。...
    茶點故事閱讀 40,090評論 1贊 350
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖著角，靈堂內(nèi)的尸體忽然破棺而出揪漩，到底是詐尸還是另有隱情，我是刑警寧澤吏口，帶...
    沈念sama閱讀 35,785評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布氢拥，位于F島的核電站，受9級特大地震影響锨侯，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜冬殃，卻給世界環(huán)境...
    茶點故事閱讀 41,420評論 3贊 331
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一囚痴、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧审葬，春花似錦深滚、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,988評論 0贊 22
  • 一樁弒父案痴荐，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至官册，卻和暖如春生兆，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背膝宁。 一陣腳步聲響...
    開封第一講書人閱讀 33,101評論 1贊 271
  • 情欲美人皮
    我被黑心中介騙來泰國打工鸦难， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留根吁，地道東北人。 一個月前我還...
    沈念sama閱讀 48,298評論 3贊 372
  • 代替公主和親
    正文 我出身青樓合蔽，卻偏偏與公主長得像击敌，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子拴事，可洞房花燭夜當晚...
    茶點故事閱讀 45,033評論 2贊 355