設(shè)計模式

設(shè)計模式分析比較居扒?

1、單例設(shè)計模式:在項目中暂题,單例是必不可少的移剪。比如UIApplication、NSUserDefaults就是蘋果提供的單例敢靡。在項目中經(jīng)常會將用戶數(shù)據(jù)管理封裝成一個單例類挂滓,因此用戶的信息需要全局使用。單例確實給我們帶來的便利啸胧,但是它也會有代價的赶站。單例一旦創(chuàng)建,整個App使用過程都不會釋放纺念,這會占用內(nèi)存贝椿,因此不可濫用單例。首先陷谱,單例寫法有好幾種烙博,通常的寫法是基于線程安全的寫法,結(jié)合dispatch_once來使用烟逊,保證單例對象只會被創(chuàng)建一次渣窜。如果不小心銷毀了單例,再調(diào)用單例生成方法是不會再創(chuàng)建的宪躯。其次乔宿,由于單例是約定俗成的,因此在實際開發(fā)中通常不會去重寫內(nèi)存管理方法访雪。

2详瑞、MVC設(shè)計模式:現(xiàn)在絕大部分項目都是基于MVC設(shè)計模式的,現(xiàn)在有一部分開發(fā)者采用MVVM臣缀、MVP等模式坝橡。

3、通知(NSNotification)模式:通知在開發(fā)中是必不可少的精置,對于跨模塊的類交互计寇,需要使用通知;對于多對多的關(guān)系,使用通知更好實現(xiàn)番宁。

4蹲堂、工廠設(shè)計模式:在我的項目中使用了大量的工廠設(shè)計模式,特別是生成控件的API贝淤,都已經(jīng)封裝成一套,全部是擴展的類方法政供,可簡化很多的代碼播聪。

5、KVC/KVO設(shè)計模式:有的時候需要監(jiān)聽某個類的屬性值的變化而做出相應(yīng)的改變布隔,這時候會使用KVC/KVO設(shè)計模式离陶。在項目中,我需要監(jiān)聽model中的某個屬性值的變化衅檀,當(dāng)變化時招刨,需要更新UI顯示,這時候使用KVC/KVO設(shè)計模式就很方便了哀军。

通知中心沉眶?

本質(zhì)可變數(shù)組,首先創(chuàng)建單例并開辟空間負(fù)責(zé)管理所有的通知杉适,接受已經(jīng)注冊的通知對象谎倔,這個對象的屬性包括觀察者,方法猿推,名字片习,傳遞的對象!每當(dāng)注冊一個新的通知時蹬叭,必須通過NSNotificationCenter這個類創(chuàng)建一個defaultCenter通知中心管理對象通過addObserver藕咏、postNotification、removeObserver來管理所有已經(jīng)注冊的通知秽五!內(nèi)部的實現(xiàn)原理除了傳參就是可變數(shù)組的遍歷孽查,移除通知時傳入?yún)?shù)1(通知名字)和參數(shù)2(傳遞的對象值),原理就是Block方式遍歷可變數(shù)組筝蚕,只不過判斷時不僅要判斷名字卦碾,更要滿足觀察者的對比進(jìn)行比較。

通知中心的本質(zhì)就是兩個類起宽,一個通知數(shù)據(jù)模型類洲胖,一個單例通知中心類,通知數(shù)據(jù)模型類的屬性有發(fā)送通知的方法坯沪、觀察者(控制器)绿映、注冊通知的名字、通知傳遞的對象。通知數(shù)據(jù)模型類的方法主要有帶所有屬性輸入?yún)?shù)的初始化方法叉弦。這個方法主要是為了在普通通知類實例化對象的時候就能給所有的屬性進(jìn)行賦值操作丐一。那么還有一個通知中心單例類,這里面首先有一個可變數(shù)組全局變量用來用來添加所有注冊的通知淹冰。接下來就是一系列方法的聲明和實現(xiàn)库车,聲明包括創(chuàng)建單例的類方法愤估、向通知中心注冊通知的對象方法寒随、輸入注冊名字和傳遞對象發(fā)送通知的方法、輸入觀察者和注冊名字刪除通知的方法剩晴。首先就是實現(xiàn)創(chuàng)建單例的類方法晶乔,使用static初始化一個通知中心的對象為空珍坊,設(shè)置static dispatch_once_t onceToken和dispatch_once(&onceToken,^{});語句讓實例化的通知中心對象只開辟一次內(nèi)存空間。而且最重要的是這里開辟內(nèi)存空間的方式有一些不一樣正罢。采用的是父類調(diào)用allocWithZone:NULL來開辟內(nèi)存空間阵漏。當(dāng)然init初始化方法需要重寫,重寫的意義就在于為前期聲明的全局?jǐn)?shù)組變量開辟內(nèi)存空間翻具。然后就是實現(xiàn)添加注冊的方法履怯,說白了就是添加一個通知版的數(shù)據(jù)模型對象到可變數(shù)組里。實現(xiàn)移除數(shù)組里通知的方法呛占,本質(zhì)就是遍歷這個裝滿通知版數(shù)據(jù)模型對象的可變數(shù)組虑乖,判斷里面的每一個數(shù)據(jù)模型對象的屬性是否與方法輸入的參數(shù)相等。現(xiàn)在就是關(guān)鍵了晾虑,如何實現(xiàn)發(fā)送通知的方法疹味,同樣Block遍歷數(shù)組,找到所有與輸入名字相同的通知版數(shù)據(jù)模型對象帜篇,現(xiàn)在就開始正式的調(diào)用注冊通知里的那個方法了糙捺,將輸入的參數(shù)傳遞給數(shù)據(jù)模型里的其它屬性。包括方法和對象笙隙。然后使用數(shù)據(jù)模型的對象的觀察者屬性(這本質(zhì)上是控制器對象)洪灯,調(diào)用performSelector方法將方法和對象數(shù)據(jù)傳遞出去。

發(fā)送通知竟痰?

就發(fā)送通知時的屬性對象值賦值給可變數(shù)組中的對象的object屬性签钩!同時調(diào)用出數(shù)組對象的方法 SEL sel = noti.selector;現(xiàn)在開始執(zhí)行可變數(shù)組中對象的方法屬性(調(diào)用對象的方法函數(shù))[noti.selector performSelector:sel withObject:noti]

單例?

單例是整個Cocoa中被廣泛使用的核心設(shè)計模式之一坏快,作為一個iOS開發(fā)者铅檩,我們經(jīng)常和單例打交道,比如UIApplication莽鸿、NSFileManager昧旨、NSNotificationCenter拾给、UIDevice等等。Xcode甚至有一個默認(rèn)的"Dispatch Once"代碼片段兔沃,可以使我們非常簡單地在代碼中創(chuàng)建一個單例蒋得。單例,由于其具有全局和多狀態(tài)的特性乒疏,導(dǎo)致隱式地在兩個看起來完全不相關(guān)的模塊之間建立了耦合额衙。單例里最需要注意的一個問題就是要考慮到多線程的影響,由于分線程與主線程的速度差異很大怕吴,也就是說主線程的進(jìn)行過程中不止一次創(chuàng)建分線程去判斷單例類對象的內(nèi)存空間是否已經(jīng)被開辟入偷。第一種方法就是通過上鎖保證在異步創(chuàng)建單例也能保證唯一性@synchronized(self),第二種方法使用static dispatch_once_t onceToken來保證代碼只被執(zhí)行一次械哟。

如果想要在多個控制器使用一個屬性的值,那么并不需要用戶在程序中設(shè)置全局變量殿雪,需要在哪里使用單例類的數(shù)據(jù)暇咆,那么就在哪里創(chuàng)建一個單例類對象,然后進(jìn)行讀或者寫操作丙曙。就是把這個整個工程都需要的用到的屬性值當(dāng)成是單例類對象的屬性爸业,如此哪里要使用到這個屬性里的值,只需要實例化一個單例對象調(diào)用出相應(yīng)的屬性即可亏镰。

KVO觀察者扯旷?

如果類1想要隨時監(jiān)聽類2的屬性是否發(fā)生變化,并把類2變化后的屬性值傳遞到類1里面索抓,只需要三步就可以實現(xiàn)钧忽,第一步:在類1跳轉(zhuǎn)到類2之前,先給類2安裝一個攝像頭逼肯,這個觀察者就是類1的對象self耸黑,而且Key只能指向?qū)ο蟮膶傩裕鳮eyPath則能指向?qū)傩缘膶傩岳捍薄W粤擞^察者之后大刊,自然再實現(xiàn)KVO里的類1觀察者監(jiān)聽到類2的KeyPath屬性值發(fā)生變化會回調(diào)的方法。這個回調(diào)方法幾乎傳遞過來了整個類2的對象三椿,所以對于KeyPath(點語法)觀察的屬性輕輕松松獲取到現(xiàn)在的值缺菌。當(dāng)然最后需要在視圖消失時調(diào)用的dealloc方法里通過類2的對象調(diào)用移除觀察者的方法。還有注意一點就是搜锰,KVO監(jiān)聽只能在一個線程中伴郁,只能觀察一個對象的屬性而不能觀察集合。

KVO的使用場景與通知的使用場景有什么不同纽乱?

1蛾绎、KVO一次性只能實現(xiàn)兩個控制器之間的傳值,而通知能夠?qū)崿F(xiàn)將一個控制器的值傳遞到多個控制器

2、KVO的傳遞的值只能時被監(jiān)聽的控制器的某一個屬性租冠,而通知可以傳遞一個控制器的任何數(shù)據(jù)類型的對象

block的本質(zhì)鹏倘?

1、指向結(jié)構(gòu)體的指針顽爹,調(diào)用block之前纤泵,Block里面的變量是一個值,在調(diào)用block之后镜粤,就會通過block里面的方法對變量的值進(jìn)行改變捏题,也就是說,可以在特定的判斷下執(zhí)行特定的方法肉渴。

block為什么要用copy修飾公荧?

1、我們都知道堆里面的東西不會被系統(tǒng)自動回收同规,因此必須將一個Block放在堆里面循狰。而默認(rèn)情況下任何block被創(chuàng)建時都在棧內(nèi)存空間里面,而棧里面的內(nèi)存隨時可能被系統(tǒng)自動回收券勺,更會在大括號結(jié)束之后被全部釋放绪钥。那我們?nèi)绾尾拍軐lock放在堆內(nèi)存空間里面呢?只要對block做一次copy操作就可以將block指針指向堆內(nèi)存空間里面关炼。這樣block就不會被自動釋放了程腹,可以長期持有block。這樣就能保證只要對象還在儒拂,那么對象的block屬性就會還在寸潦。

為什么不能用MRC中的retain或ARC中的strong?

1、確實retain和strong已經(jīng)能夠保證對象的屬性不會被自動釋放社痛,而且只要對象還在甸祭,那么屬性就一定存在∪煊埃可是retain和strong僅僅是增加了屬性對象引用計數(shù)池户,根本不會改變屬性對象的內(nèi)存地址。只有copy 方法才能改變內(nèi)存地址凡怎。將屬性從默認(rèn)的棧地址改變到堆地址里校焦。

Block使用過程中會出現(xiàn)什么問題?如何解決统倒?

1寨典、block屬性必須使用copy來修飾,既然是copy那就是強引用房匆,然后就會出現(xiàn)一個內(nèi)存泄露的情況耸成,內(nèi)存泄露就是對象在堆內(nèi)存空間的內(nèi)存得不到釋放报亩。

2、當(dāng)初所說的循環(huán)引用就是簡單的對象1強引用對象2井氢,對象2強引用對象1弦追,MRC里一個retain,另一個assign花竞。ARC里一端是strong劲件,另一端使用weak。雖然這里不是對象1直接強引用對象2约急,但是因為block使用copy修飾符又作為對象1的屬性就間接地強引用了對象2零远。解決方案當(dāng)然不能改變block的修飾符,改的只能是如何讓對象2不強引用對象1厌蔽,方法就是在用alloc方法創(chuàng)建了強指針之后牵辣,再聲明一個弱指針將強指針的內(nèi)存地址賦值給弱指針,如此便可以使得對象2不再強引用對象1奴饮。

KVC的本質(zhì)是什么服猪?這是一個問題。跟KVO的區(qū)別又是什么拐云?KVC有與普通意義上的傳值有什么聯(lián)系?

對于任何一個類的實例化的對象來說近她,每一個對象肯定都有許多的屬性叉瘩,當(dāng)然對于一個對象來說,在沒有給屬性賦值以前粘捎,這些屬性都是nil.那么現(xiàn)在能想到的賦值方式就是通過等于號直接進(jìn)行賦值了薇缅。那么KVC就為我們提供了一種給對象的屬性賦值的全新方法!不需在用對象點語法加屬性的方式通過等于號來進(jìn)行賦值攒磨,而是直接以方法[對象 setValue:@"" forKey:@“屬性”/forKeyPath:@"屬性”]來進(jìn)行屬性的賦值泳桦。至于forKey和forKeyPath的區(qū)別,在KVO里面就已經(jīng)說過了娩缰!還有過去來說灸撰,一想到獲取對象的屬性值肯定首先會想到對象點語法屬性,而現(xiàn)在因為有了KVC則提供了一種全新的獲取對象屬性值的全新方法拼坎。即[對象 valueForKey/KeyPath/UndefinedKey:@"屬性”],其實如果發(fā)明KVC的意義就這么點功能的話實在是沒有什么存在的價值浮毯,KVC最大的價值還是在于KVC給對象的屬性批量賦值的功能。這次才是KVC的最大貢獻(xiàn)泰鸡,至于單個給某一個屬性賦值或提取某一單個屬性的值完全不是KVC對于這個世界的貢獻(xiàn)债蓝,批量給對象的屬性賦值才是存在的意義,通過方法[有著批量屬性的對象 setValuesForKeysWithDictionary:字典]實現(xiàn)給對象的屬性批量賦值的前提條件就是對象里的屬性名稱必須與字典里的鍵一模一樣盛龄,原因就在于傳進(jìn)來的是一個字典饰迹,字典決定取哪一個鍵完全是由屬性的名稱來決定芳誓,格式通常就是字典[@“屬性名”]來提取字典里的值來賦值給對象里的屬性,那么經(jīng)常會出現(xiàn)一個問題就是啊鸭,屬性里有的名稱字典里并沒有锹淌,如果只是造成對象里的這個屬性賦值不成共也就罷了,問題是這竟然會導(dǎo)致程序崩潰!唯一的解決方案就是在對象的.m文件里添加方法-(void)setValue:(id)value forUndefinedKey:(NSString *)key{}莉掂。還有一個情況就是在逐個提取對象里屬性的值時葛圃,會出現(xiàn)一種情況就是提前想要提取的屬性在對象里并不存在,這就造成了崩潰憎妙,你可能會問库正,為什么在用點語法來提取對象時并不會發(fā)生崩潰,因為原因就是用點語法提取數(shù)據(jù)的時候厘唾,如果對象沒有這個屬性褥符,就根本連顯示都沒有呀!而通過KVC的[對象 valueForKey/KeyPath/UndefinedKey:@"屬性”]的方法則無法進(jìn)行提前判斷這個對象里到底有沒有這個屬性抚垃。唯一能做的就是事后諸葛亮喷楣,程序崩潰讓你崩潰,你自然就知道了鹤树!

-(id)valueForUndefinedKey:(NSString *)key{ return nil; }

KVO使用方法?

當(dāng)我點擊按鈕時铣焊,會將類2的對象的屬性值傳遞給類1的對象的屬性值。這就相當(dāng)于使用KVO來進(jìn)行反向傳值罕伯,我在使用KVO進(jìn)行反向傳值時遇到了一個很嚴(yán)重的問題,設(shè)置監(jiān)聽通知時必須注意一個問題就是設(shè)置觀察者時務(wù)必注意一個問題曲伊,千萬不要多創(chuàng)建一個觀察者對象,這樣盡管反向傳值時發(fā)現(xiàn)監(jiān)聽發(fā)生了追他,而且也調(diào)用了那個監(jiān)聽到屬性值發(fā)生改變時就會調(diào)用的方法坟募,而且你會發(fā)現(xiàn)盡管這個方法就是我們設(shè)置的那個觀察者控制器里的方法,但要知道這此時的觀察者其實是一個全新的觀察者邑狸!所以原本的觀察者控制器的屬性值全部變?yōu)榭招概础K阅銜l(fā)現(xiàn)盡管程序進(jìn)入了那個監(jiān)聽路徑的內(nèi)容里面,但是奇怪的是你會發(fā)現(xiàn)原本創(chuàng)建的UI視圖的屬性值全部變?yōu)榭盏ノ恚∷赃@其中的問題在那兒呢赚哗?關(guān)鍵就在于當(dāng)控制器1通過導(dǎo)航控制器Push到控制器2時,在控制器2里面注冊監(jiān)聽硅堆,相當(dāng)于在self(控制器2)上注冊監(jiān)聽蜂奸,將控制器1設(shè)置為觀察者,用來監(jiān)聽控制器2里面的KeyPath所對應(yīng)的值是否發(fā)生了變化硬萍。那么問題來了扩所,一定要注意設(shè)置觀察者的時候必須考慮好現(xiàn)在正在設(shè)置的觀察者是否是新創(chuàng)建的控制器1。然后還有一個問題朴乖,就是在監(jiān)聽路徑的時候祖屏,務(wù)必注意控制器的屬性KeyPath必須使用點語法助赞,不能使用下劃線!

那么現(xiàn)在需要整理一下這個思路袁勺,首先就是注冊監(jiān)聽雹食,會出現(xiàn)四個參數(shù),參數(shù)一也就是說是誰調(diào)用通知的這種方法期丰,誰調(diào)用這個注冊監(jiān)聽的方法就相當(dāng)于誰是被監(jiān)聽的對象群叶。舉個例子,如果控制器2的對象調(diào)用這個方法钝荡,就相當(dāng)于在控制器2里面安裝了一個攝像頭用來監(jiān)聽控制器2里面的所有屬性值的變化街立!參數(shù)2就是設(shè)置觀察者,表示已經(jīng)安裝在控制器2里面的攝像頭最終將數(shù)據(jù)的變化情況傳給誰埠通?通常這里填self赎离。也就是說,盡量把KVO的注冊和調(diào)用以及銷毀放在觀察者的這個控制器里端辱。那么問題來了梁剔,為什么我總是會有有一種錯覺就是,要想實現(xiàn)監(jiān)聽功能舞蔽,必須和被監(jiān)聽的控制器里發(fā)生聯(lián)系呢荣病?就有一種錯覺就是,總感覺要想實現(xiàn)決定何時調(diào)用監(jiān)聽方法就必須讓這個KVO里面的某一個方法必須與被監(jiān)聽的控制器發(fā)生某種聯(lián)系渗柿「雠瑁可是,事實上做祝,并非如此,因為有了參數(shù)三:KeyPath,這個參數(shù)直接讓被監(jiān)聽的控制器精確到一個屬性鸡岗,準(zhǔn)確的說混槐,精確到某一個路徑才更正確。精確到屬性只是相當(dāng)于精確到key轩性,而keyPath就相當(dāng)于能夠精確到屬性里面的屬性声登,反正keyPath遠(yuǎn)比key強大!當(dāng)然既然設(shè)計傳值揣苏,其實就少不了SEL方法悯嗓,因為通常來說,反向傳值卸察,會用到幾個常見的方法:方法1就是協(xié)議代理脯厨,就是通過調(diào)用函數(shù)時候。兩個控制器都會出現(xiàn)同一句包含參數(shù)的函數(shù)坑质,這樣就實現(xiàn)了傳值合武,而且可以在函數(shù)的具體實現(xiàn)里對傳入的參數(shù)進(jìn)行處理临梗。方法2就是通過Block來進(jìn)行傳值,同樣也是在block的具體實現(xiàn)里對調(diào)用block時傳入的參數(shù)進(jìn)行編輯和使用稼跳!其實從這個角度來講盟庞,KVO的監(jiān)聽傳值更像是一個協(xié)議呀!

1汤善、[被監(jiān)聽的控制器 addObserver:觀察者控制器 forKeyPath:@“被監(jiān)聽的屬

2什猖、- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context{

(被監(jiān)聽控制器 *)object.被監(jiān)聽屬性;}

3、-(void)dealloc{

[被監(jiān)聽的控制器 removeObserver:so forKeyPath:@“被監(jiān)聽的屬性"]}

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子删窒,更是在濱河造成了極大的恐慌柳骄,老刑警劉巖,帶你破解...
    沈念sama閱讀 218,941評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件旬牲,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機遂黍,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,397評論 3 395
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來俊嗽,“玉大人雾家,你說我怎么就攤上這事∩芑恚” “怎么了芯咧?”我有些...
    開封第一講書人閱讀 165,345評論 0 356
  • 文/不壞的土叔 我叫張陵,是天一觀的道長竹揍。 經(jīng)常有香客問我敬飒,道長,這世上最難降的妖魔是什么芬位? 我笑而不...
    開封第一講書人閱讀 58,851評論 1 295
  • 正文 為了忘掉前任无拗,我火速辦了婚禮,結(jié)果婚禮上昧碉,老公的妹妹穿的比我還像新娘英染。我一直安慰自己,他們只是感情好被饿,可當(dāng)我...
    茶點故事閱讀 67,868評論 6 392
  • 文/花漫 我一把揭開白布四康。 她就那樣靜靜地躺著,像睡著了一般狭握。 火紅的嫁衣襯著肌膚如雪闪金。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,688評論 1 305
  • 那天论颅,我揣著相機與錄音毕泌,去河邊找鬼喝检。 笑死,一個胖子當(dāng)著我的面吹牛撼泛,可吹牛的內(nèi)容都是我干的挠说。 我是一名探鬼主播,決...
    沈念sama閱讀 40,414評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼愿题,長吁一口氣:“原來是場噩夢啊……” “哼损俭!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起潘酗,我...
    開封第一講書人閱讀 39,319評論 0 276
  • 序言:老撾萬榮一對情侶失蹤杆兵,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后仔夺,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體琐脏,經(jīng)...
    沈念sama閱讀 45,775評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,945評論 3 336
  • 正文 我和宋清朗相戀三年缸兔,在試婚紗的時候發(fā)現(xiàn)自己被綠了日裙。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 40,096評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡惰蜜,死狀恐怖昂拂,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情抛猖,我是刑警寧澤格侯,帶...
    沈念sama閱讀 35,789評論 5 346
  • 正文 年R本政府宣布,位于F島的核電站财著,受9級特大地震影響联四,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜撑教,卻給世界環(huán)境...
    茶點故事閱讀 41,437評論 3 331
  • 文/蒙蒙 一朝墩、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧驮履,春花似錦鱼辙、人聲如沸廉嚼。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,993評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽怠噪。三九已至恐似,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間傍念,已是汗流浹背矫夷。 一陣腳步聲響...
    開封第一講書人閱讀 33,107評論 1 271
  • 我被黑心中介騙來泰國打工葛闷, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人双藕。 一個月前我還...
    沈念sama閱讀 48,308評論 3 372
  • 正文 我出身青樓淑趾,卻偏偏與公主長得像,于是被迫代替她去往敵國和親忧陪。 傳聞我的和親對象是個殘疾皇子扣泊,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 45,037評論 2 355

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