iOS面試題必考問題

iOS面試必考問題

1、多態、繼承、封裝

封裝:就是對類中的一些字段,方法進行保護,不被外界所訪問到,有一種權限的控制功能,四種訪問權限修飾符:public,default,protected,private,訪問權限一次遞減的,這樣我們在定義類的時候,哪些字段和方法不想暴露出去,哪些字段和方法可以暴露,可以通過修飾符來完成,這就是封裝;

繼承:使得我們沒必要別寫重復的代碼,可重用性很高。缺點:繼承提高了代碼的耦合性.優點: 提高復用性,維護性

多態:定義類型和實際類型,一般是基于接口的形式實現的

2、代理模式、單例模式、觀察者模式、工廠模式

代理這是iOS中一種消息傳遞的方式,也可以通過這種方式來傳遞一些參數
協議:用來指定代理雙方可以做什么,必須做什么。
代理:根據指定的協議,完成委托方需要實現的功能。
委托:根據指定的協議,指定代理去完成什么功能。

協議是什么?有什么作用?
協議:聲明一系列的方法,可由任何類實施,即使遵守該協議的類沒有共同的超類。協議方法定義了獨立于任何特定類的行為。簡單的說,協議就是定義了一個接口,其他類負責來實現這些接口。如果你的類實現了一個協議的方法時,則說該類遵循此協議。
協議的作用:
1.定義一套公用的接口(Public)
@required:必須實現的方法
@optional:可選實現的方法(可以全部都不實現)
2.委托代理(Delegate)傳值:
它本身是一個設計模式,它的意思是委托別人去做某事。
比如:兩個類之間的傳值,類A調用類B的方法,類B在執行過程中遇到問題通知類A,這時候我們需要用到代理(Delegate)。

單例:確保某一個類只有一個實例,而且自行實例化并向整個系統提供整個實例。
優點:
1、減少內存開支和系統性能開銷;
2、避免對資源的多重占用;
3、優化和共享資源訪問。
缺點:
1、單例模式沒有接口,擴展很困難;
2、單例模式與單一職責有沖突。
通過GCD實現單例方法:

 (.h文件中)
+(DBManager *)sharedManager;   
.m文件中的實現:
+(DBManager *)sharedManager{
 Static DBManager *manager = nil;
  static dispatch_once_t token;
  dispatch_once(&token,^{
         if(manager == nil){
           manager = [[DBManager alloc]init];
   }
} );
return manager;
}

3、事件響應連

hit-Testing:找出這個觸摸點下面的hit-test view的過程,HitTest會檢測這個點擊的點是不是發生在這個View上,如果是的話,就會去遍歷這個View的subviews,直到找到最小的能夠處理事件的view,如果整了一圈沒找到能夠處理的view,則返回自身。

 - (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event;
 //該方法的處理過程:
 //首先調用當前視圖的pointInside:withEvent:方法判斷觸摸點是否在當前視圖內;
 //YES在,則遍歷當前視圖的所有子視圖(subviews),調用子視圖的hitTest:withEvent:;
 // NO不在,當前視圖的hitTest:withEvent:返回nil
 //若第一次有子視圖的hitTest:withEvent:方法返回非空對象,則當前視圖的hitTest:withEvent:方法就返回此對象,處理結束
 //若所有子視圖的hitTest:withEvent:方法都返回nil,則當前視圖的hitTest:withEvent:方法返回當前視圖自身(self)

//判斷觸摸點是否在當前視圖內,可以用來實現擴大View的相應區域
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;

1.事件的產生
發生觸摸事件后,系統會將該事件加入到一個由UIApplication管理的事件隊列中為什么是隊列而不是棧?因為隊列的特定是先進先出,先產生的事件先處理才符合常理,所以把事件添加到隊列。
UIApplication會從事件隊列中取出最前面的事件,并將事件分發下去以便處理,通常,先發送事件給應用程序的主窗口(keyWindow)。
主窗口會在視圖層次結構中找到一個最合適的視圖來處理觸摸事件,這也是整個事件處理過程的第一步。
找到合適的視圖控件后,就會調用視圖控件的touches方法來作具體的事件處理。
2.事件的傳遞
觸摸事件的傳遞是從父控件傳遞到子控件
也就是UIApplication->window->尋找處理事件最合適的view

4、NSThread、NSOperation、GCD

什么是進程
a、是指在系統中正在運行的一個應用程序;
b、每個進程之間是獨立的,每個進程運行在其專用且受保護的內存空間;
什么是線程
a、一個進程想要執行任務,必須得有線程(每個進程至少要有一條線程);
b、線程是進程的基本執行單元,一個進程(程序)的所有任務都在線程中執行;

5、MVC、MVVM等 View層架構模式

6、NSUserDefault、Plist、NSCode、Sqlite、CoreData、File

plist文件(屬性列表)

preference(偏好設置)

NSKeyedArchiver(歸檔)

SQLite 3

CoreData (icloud 無主鍵)

7、delegate、Notification、block

block本質是一個數據類型,多用于參數傳遞,代替代理方法, (有多個參數需要傳遞或者多個代理方法需要實現還是推薦使用代理方法),少用于當做返回值傳遞. block是一個OC對象,它的功能是保存代碼片段,預先準備好代碼,并在需要的時候執行.

8、內存管理、內存優化、內存泄漏

自動釋放池@autoreleasepool

自動釋放池底層怎么實現

自動釋放池以棧的形式實現:當你創建一個新的自動釋放池時,它將被添加到棧頂。當一個對象收到發送autorelease消息時,它被添加到當前線程的處于棧頂的自動釋放池中,當自動釋放池被回收時,它們從棧中被刪除,并且會給池子里面所有的對象都會做一次release操作.

OC對象的生命周期取決于引用計數,我們有兩種方式可以釋放對象:一種是直接調用release釋放;另一種是調用autorelease將對象加入自動釋放池中。自動釋放池用于存放那些需要在稍后某個時刻釋放的對象。

我們的Mac以及iOS系統會自動創建一些線程,例如主線程和GCD中的線程,都默認擁有自動釋放池。每次執行 “事件循環”(event loop)時,就會將其清空,這一點非常重要,請務必牢記!

9、堆和棧

棧,是由系統編譯器自動管理,不需要程序員手動管理,存放方法(函數)的參數值,局部變量的值等,棧是向低地址擴展的數據結構,是一塊連續的內存區域
堆,釋放工作由程序員手動管理,不及時回收容易產生內存泄露,堆是向高地址擴展的數據結構,是不連續的內存區域。這是由于系統是用鏈表來存儲的空閑內存地址的,自然是不連續的,而鏈表的遍歷方向是由低地址向高地址。堆的大小受限于計算機系統中有效的虛擬內存。由此可見,堆獲得的空間比較靈活,也比較大。

棧區存放局部變量,先進后出,當程序執行出了作用于的范圍,棧區局部變量就會被銷毀,所以我們也不需要管理棧區的內存。
1.在iOS中,堆區的內存是所有應用程序共享的

2.堆區內存分配是由系統來負責的

3.系統通過鏈表來維護所有已經分配過的內存空間

4.系統只是記錄分配了多少字節給應用程序,但是并不管理具體分配給的對象類型

5.變量使用結束后,需要釋放內存。在OC中當retainCount == 0時,就說明沒有任何變量使用該空間,那么系統就會直接回收

6.如果我們使用某一個變量之后,不釋放內存,那么該內存就會被永遠占用,造成內存泄漏

7.當對象已經釋放,但是程序中的變量仍然指向該內存地址,這個時候,如果向該對象發送消息,就會出現經典的野指針錯誤

10、const、static、extern

11、readwrite ,readonly strong,weak,retain,assign,copy , nonatomic , natomic

readwrite : 是可讀可寫屬性,需要生成setter 和 getter 方法;
readonly: 是可讀屬性,只生成getter方法,不生成setter方法,不希望屬性再類外改變;
strong:
weak:
retain: 表示持有特性,setter方法將傳入的參數保留,再賦值,傳入參數引用計數retaincount + 1;
assign: 是賦值特性,setter方法將傳入的參數賦值給實體變量,僅設置變量時,assign用于簡單數據類型 如 NSInterger ,double ,float ,bool
copy: 表示賦值特性,setter方式將傳入的對象復制一份,需完全復制一份新的變量時:
noatomic: 非原子性操作,決定編譯器生成的setter和getter 方法是否是原子性的操作;
atomic: 表示多線程安全

12、documents,tmp,app,Library

14、category、extension(類擴展)

類別:Category 是表示一個指向分類的結構體的指針。
1.分類是用于給原有類添加方法的,因為分類的結構體指針中,沒有屬性列表,只有方法列表。所以< 原則上講它只能添加方法, 不能添加屬性(成員變量),實際上可以通過其它方式添加屬性> ;
2.分類中的可以寫@property, 但不會生成setter/getter方法, 也不會生成實現以及私有的成員變量(編譯時會報警告);
3.可以在分類中訪問原有類中.h中的屬性;
4.如果分類中有和原有類同名的方法, 會優先調用分類中的方法, 就是說會忽略原有類的方法。所以同名方法調用的優先級為 分類 > 本類 > 父類。因此在開發中盡量不要覆蓋原有類;
5.如果多個分類中都有和原有類中同名的方法, 那么調用該方法的時候執行誰由編譯器決定;編譯器會執行最后一個參與編譯的分類中的方法。


擴展:

  1. 能為某個類添加成員變量,屬性,方法;
  2. 一般的類擴展寫到.m文件中;
  3. 一般的私有屬性寫到類擴展中

區別:

①類別中原則上只能增加方法(能添加屬性的的原因只是通過runtime解決無setter/getter的問題而已);
②類擴展不僅可以增加方法,還可以增加實例變量(或者屬性),只是該實例變量默認是@private類型的(
用范圍只能在自身類,而不是子類或其他地方);
③類擴展中聲明的方法沒被實現,編譯器會報警,但是類別中的方法沒被實現編譯器是不會有任何警告的。這是因為類擴展是在編譯階段被添加到類中,而類別是在運行時添加到類中。
④類擴展不能像類別那樣擁有獨立的實現部分(@implementation部分),也就是說,類擴展所聲明的方法必須依托對應類的實現部分來實現。
⑤定義在 .m 文件中的類擴展方法為私有的,定義在 .h 文件(頭文件)中的類擴展方法為公有的。類擴展是在 .m 文件中聲明私有方法的非常好的方式。

15、KVO、KVC

KVC的本質就是 (鍵值編碼)

定義: 在對象創建完成之后,動態(牽扯到運行時)的給對象的屬性賦值
KVO 的本質就是(鍵值監聽)

定義::Key-Value Observing,它提供一種機制,當指定的對象的屬性被修改后,則對象就會接受到通知。

KVO是基于KVC實現的,只有我們調用KVC去訪問key值的時候KVO才會起作用。

KVO只用來監聽屬性值的變化,這個發送監聽的操作是系統控制的,我們控制不了,我們只能控制監聽操作
通知需要一個發送notification的對象,一般是notificationCenter,來通知觀察者。KVO是直接通知到觀察對象,并且邏輯非常清晰,實現步驟簡單。
通知需要一個發送notification的對象,一般是notificationCenter,來通知觀察者。KVO是直接通知到觀察對象,并且邏輯非常清晰,實現步驟簡單。

16、runtime

17、runloop

指導文章:http://www.swiftyper.com/2017/01/04/runloop-learning-note/

RunLoop 是一種事件驅動(Event Driven)模型,
但是一個 iOS 應用一旦啟動起來后就會一直處于等待用戶事件(類似點擊或者觸摸事件)的狀態,除非用戶手動關閉它,
當我們使用 Xcode 創建一個新的 iOS 應用時,它會自動幫我們生成 main 方法(這個方法在 main.m 文件中),而在 main 方法里面會調用 UIApplicationMain 方法。UIApplicationMain 會將 AppDelegate 設置為應用程序的代碼,同時會為主線程創建一個 RunLoop 并啟動,因此任何一個 iOS 應用一旦啟動了,就至少存在一個 RunLoop,并且這個 RunLoop 是屬于主線程的。之所以說屬于主線程,是因為 RunLoop 與線程的關系是一一對應的。

其實事件驅動模型的本質就是一個死循環,然后在循環中不斷等待消息的到來,然后對其進行處理,
RunLoop 實際上就是一個對象,它為我們提供了一個進入事件循環的入口函數,線程執行這個函數后就會處于消息循環中,直到循環結束(比如接收到退出消息)。

在 iOS 中提供了兩個 RunLoop 對象:NSRunLoop 與 CFRunLoopRef。

其中,NSRunLoop 是基于 CFRunLoopRef 的簡單封裝。NSRunLoop 的 API 是非線程安全的,而 CFRunLoopRef 的 API 是線程安全的。更重要的一點是 CFRunLoopRef 的代碼是開源的。

特點:1、使程序一直運行接收用戶輸入
2、決定程序何時處理哪些Event
3、調用解耦
4、節省cpu

NSDefaulRunLoopMode (默認狀態,空閑狀態)
NSTrackingRunLoopMode (滑動scrollView)
NSRunLoopCommonMode (上方兩著都可執行)
列子: 當列表滑動的時候,NSTime 不會動。
解答: 因NSTime處于DefaulRunLoopMode,當滑動工程被切換到了TrackingRunLoopMode去關注滑動事件了,所以我們要將time設置為NSRunLoopCommonMode 

一個TableView延時加載圖片的新思路
在cell里面把設置圖片在 NSDefaulRunLoopMode中做,其滑動過程就不會設置圖片,

18、View層架構、網絡層架構、持久層架構、組件化架構、動態部署方案

19、UITableView的優化

20、二叉樹、時間復雜度

21、TCP,UDP,HTTP

TCP也就是傳輸控制協議。它是一種面向連接的、可靠的、基于字節流的[傳輸層]通信協議。主要解決數據如何在網絡中如何傳輸的,是一種長連接。建立一個TCP連接需要有三次握手,而終止一個TCP連接需要有4次握手,這是由TCP的半關閉(half-close)造成的。TCP包頭的最小長度為20字節。大小不受限制,是可靠協議,安全送達

UDP也就是用戶數據報協議。它與TCP相對應,是一種面向無連接的、不可靠的數據報傳輸協議,即不與對方建立連接,就直接就把數據包發送過去,因此缺乏可靠性。由于缺乏可靠性,UDP應用一般必須允許一定量的丟包、出錯和復制。大小限制在64k之內無需連接,所以不可靠協議,但速度快

HTTP也就是超文本傳輸協議。HTTP是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束后,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

TCP與UDP的區別

(1)TCP是需要連接的傳輸協議(長連接),UDP是不需要連接的傳輸協議;
(2)TCP對系統資源要求較多,UDP要求較少;
(3)TCP的程序結構較復雜,UDP程序結構較簡單;
(4)TCP是流模式,UDP是數據報模式 ;
(5)TCP保證數據正確性,UDP可能丟包,TCP保證數據順序,UDP不保證。

第三方庫實現原理解析:

SDWebImage 如何為 UIImageView 添加圖片(面試回答)

SDWebImage 中為 UIView 提供了一個分類叫做 WebCache, 這個分類中有一個最常用的接口, sd_setImageWithURL:placeholderImage:, 這個分類同時提供了很多類似的方法, 這些方法最終會調用一個同時具有 option progressBlock completionBlock 的方法, 而在這個類最終被調用的方法首先會檢查是否傳入了 placeholderImage 以及對應的參數, 并設置 placeholderImage.

然后會獲取 SDWebImageManager 中的單例調用一個 downloadImageWithURL:... 的方法來獲取圖片, 而這個 manager 獲取圖片的過程有大體上分為兩部分, 它首先會在 SDWebImageCache 中尋找圖片是否有對應的緩存, 它會以 url 作為數據的索引先在內存中尋找是否有對應的緩存, 如果緩存未命中就會在磁盤中利用 MD5 處理過的 key 來繼續查詢對應的數據, 如果找到了, 就會把磁盤中的緩存備份到內存中.

然而, 假設我們在內存和磁盤緩存中都沒有命中, 那么 manager 就會調用它持有的一個 SDWebImageDownloader 對象的方法 downloadImageWithURL:... 來下載圖片, 這個方法會在執行的過程中調用另一個方法 addProgressCallback:andCompletedBlock:forURL:createCallback: 來存儲下載過程中和下載完成的回調, 當回調塊是第一次添加的時候, 方法會實例化一個 NSMutableURLRequest 和 SDWebImageDownloaderOperation, 并將后者加入 downloader 持有的下載隊列開始圖片的異步下載.

而在圖片下載完成之后, 就會在主線程設置 image 屬性, 完成整個圖像的異步下載和配置.

總結SDWebImage 的圖片加載過程其實很符合我們的直覺:
查看緩存
緩存命中
返回圖片
更新 UIImageView
緩存未命中
異步下載圖片
加入緩存
更新 UIImageView

UITableView重用cell

UITableViewCell的復用機制是,在tableview中存在一個復用池.這個復用池是一個隊列或一個鏈表.然后通過dequeueReusableCellWithIdentifier:獲取一個cell,如果當前cell不存在,即新建一個cell,并將當前cell添加進復用池中.如果當前的cell數量已經到過tableview所能容納的個數,則會在滾動到下一個cell時,自動取出之前的cell并設置內容.

排序算法

冒泡排序

NSMutableArray *arr_M = [NSMutableArray arrayWithObjects:@1,@4,@2,@3,@5,nil];
    //遍歷`數組的個數`次
    /*
     i = 0 的時候,j的相鄰兩個位置都要比較排一下位置:
         j = 0 的時候:arr_M = 41235
         j = 1 的時候:arr_M = 42135
         j = 2 的時候:arr_M = 42315
         j = 3 的時候:arr_M = 42351
     i = 1;
      ……  ……
     */
    for (int i = 0; i < arr_M.count; ++i) {

        //遍歷數組的每一個`索引`(不包括最后一個,因為比較的是j+1)
        for (int j = 0; j < arr_M.count-1; ++j) {
            //根據索引的`相鄰兩位`進行`比較`
            if (arr_M[j] < arr_M[j+1]) {
                [arr_M exchangeObjectAtIndex:j withObjectAtIndex:j+1];
            }
        }
    }
    NSLog(@"最終結果:%@",arr_M);

選擇排序

NSMutableArray *arr_M = [NSMutableArray arrayWithObjects:@1,@4,@2,@3,@5,nil];

    for (int i=0; i<arr_M.count; i++) {

        for (int j=i+1; j<arr_M.count; j++) {

            if (arr_M[i]<arr_M[j]) {

                [arr_M exchangeObjectAtIndex:i withObjectAtIndex:j];

            }

        }
    }
    NSLog(@"%@",arr_M);

copy與mutableCopy 深復制和淺復制

copy 拷貝的對象為不可修改的,而mutableCopy拷貝的對象為可改變的對象,即使被復制的對象本身為不可改變的,調用mutableCopy方法復制出來的副本也是可修改的,當程序調用對象的copy方法來復制自身時,底層需要調用copyWithZone:方法來完成實際的復制工作,copy返回實際上就是copyWithZone:方法的返回值;mutableCopy與mutableCopyWithZone:方法也是同樣的道理。

淺復制和深復制:顧名思義,淺復制,并不拷貝對象本身,僅僅是拷貝指向對象的指針;深復制是直接拷貝整個對象內容到另一塊內存中。再簡單些說:淺復制就是指針拷貝;深復制就是內容拷貝。

AsyncSocket

考慮到數據量比較大的問題,所以數據大的時候我會使用分包和組包的功能去實現。TCP/IP在傳輸數據的時候,一般不會大于1500字節,所以我每512字節分了

一個包。然后當一次性數據包接收太多的時候,就出現了粘包的問題。因為我在數據傳輸的時候使用的是json,每一個分包都是由{}括起來的,所以我就想著在包頭上加上一段基本不會重復

的分割字符串,然后服務器接收到分包的時候每次都根據這個字符串分割一下,第一次分割的時候第一行絕對是空字符串 例如:@Hinagiku{“Name”=“桂雛菊”}, 我分割出來結果是:

“”,“桂雛菊”,所以說第一行我就可以直接跳過,每次取分包的時候從第二行開始取。然后后臺根據包的ID號,序號進行組包。如果當前分包在5分鐘內沒有接收完畢,就代表當前分包接收失敗

了,要求客戶端或服務器重新發送。粘包問題解決完畢之后,我開始實現心跳包功能,當時想的是,每隔1分鐘發一次心跳包,服務器放一個線程。每隔幾秒鐘判斷一次,當前的所有TCP連接的
最后一次訪問時間是多少號,如果超過了這個時間則斷開當前連接

tag參數是為了在回調方法中匹配發起調用的方法的,不會加在傳輸數據中。
需注意的一點是:發送時的tag和接收時的tag是無關的。
以read為例分析:

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

推薦閱讀更多精彩內容

  • 從三月份找實習到現在,面了一些公司,掛了不少,但最終還是拿到小米、百度、阿里、京東、新浪、CVTE、樂視家的研發崗...
    時芥藍閱讀 42,328評論 11 349
  • *面試心聲:其實這些題本人都沒怎么背,但是在上海 兩周半 面了大約10家 收到差不多3個offer,總結起來就是把...
    Dove_iOS閱讀 27,197評論 30 471
  • iOS面試小貼士 ———————————————回答好下面的足夠了------------------------...
    不言不愛閱讀 1,998評論 0 7
  • 史上最全的iOS面試題及答案 iOS面試小貼士———————————————回答好下面的足夠了----------...
    Style_偉閱讀 2,372評論 0 35
  • “我要吃這個,還有這個…”望著手里堆成山的食盤,陳翕回頭沖著秦灼于眨了個眼,發出了“求救”信號。像高中與世隔絕的小...
    Ooooyho閱讀 199評論 0 0