目前情況：10屆某民辦大學本科生，實際接觸Android年限6年多了，工作年限五年半（注意，我說的是工作年限，不是工作經驗），今年1月份裸辭後歇了大半年，經常一週也收不到幾個offer，好不容易熬到HR面，也因為薪資要求過高被放棄了，最終拿到一個並不是特滿意的offer。

首先我想明確地說在目前的大環境下，移動網際網路確實已經屬於寒冬。尤其是Android/IOS開發，雖然說不上夕陽行業，但也離熱門IT職業差了十萬八千里。從之前大量小創公司因疫情原因倒閉破產，360、滴滴、攜程等大廠實施裁員的新聞其實也能略見一二了。至於那些還存活著的小公司，對於移動端開發人員的要求。。。好像跑題了~還是說求職面試吧。

網上Android崗位招聘的需求來看：

要求掌握系統架構及相關技術，熟悉高階UI、framework原始碼，精通外掛化、效能優化、Java開發經驗。。。
視訊面試給我的第一感覺就是題太難了，薪資低也就就算了，面試要求還賊高。

TCP與UDP的區別

• TCP面向連線的, 傳輸資料時，需先進行三次握手,建立連線，UDP是無連線的，傳送資料之前不需要建立連線
• TCP通過確認和重傳機制，提供可靠的服務。即通過TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達，而UDP不保證可靠傳輸,只是儘可能得交付
• TCP面向位元組流，即將資料看成一連串無結構的位元組流。UDP是面向報文的,UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時視訊會議等）
• 每一條TCP連線只能是點到點的;UDP支援一對一，一對多，多對一和多對多的互動通訊
• TCP的邏輯通訊通道是全雙工的可靠通道，UDP則是不可靠通道

TCP的三次握手和四次揮手

這個概念大家一定不陌生，我以前寫過一篇詳細關於TCP的三次握手和四次揮手的文章，可以參考，這裡就不贅述

TCP流量控制

很多人會將流量控制和擁塞控制搞混，所以單獨拎出來，考究細節

流量控制：如果傳送者傳送資料過快，接收者來不及接收，那麼就會有分組丟失。流量控制策略就是控制傳送者的傳送速度，使得接收者來得及接收,達到不丟失分組的目的。流量控制是構成TCP可靠性的一方面。

流量控制主要使用滑動視窗機制實現。下面以上圖講解滑動視窗(也叫接受視窗rwnd)的細節

主機A向主機B傳送資料，開始雙方確定的視窗值為400位元組,這兩個是前提條件。開始A傳送了200位元組，之後發生了分組丟失現象，B調整接受視窗大小為300位元組。之後A又連續傳送了300位元組。此時A已經不能傳送資料，需等待B的視窗訊號。之後B調整視窗為100位元組。接收到100位元組資料後，調整視窗值為0，表示暫時不想接受資料。總共B調整了三次視窗大小，進行了三次流量控制

假如，B向A傳送了零視窗的報文段後不久，B的接收快取又有了一些儲存空間。於是B向A傳送了rwind=400的報文段，然而這個報文段在傳送中丟失 了。A一直等待收到B傳送的非零視窗的通知，而B也一直等待A傳送的資料。這樣就死鎖了。為了解決這種死鎖狀態，TCP為每個連線設有一個持續計時器。只 要TCP連線的一方收到對方的零視窗通知，就啟動持續計時器，若持續計時器設定的時間到期，就傳送一個零視窗探測報文段（僅攜帶1位元組的資料），而對方就在確認這個探測報文段時給出了現在的視窗值。

TCP擁塞控制

擁塞控制，大家都能背出來，什麼慢開始、擁塞避免、快重傳、快恢復，大家都耳熟能詳，但是有些細節問題，可以大家沒有留意，比如快重傳階段後，為什麼不直接進入慢開始階段，而是進入擁塞避免階段？

擁塞的概念：在某段時間，對網路中的某一資源的需求超過了該資源所能提供的可用部分，網路的效能就要變化，這種情況叫擁塞。網路擁塞往往是由許多因素引起的，簡單的提高節點處理機的速度或者擴大結點快取的儲存空間並不能解決擁塞問題。擁塞問題的是指往往是整個系統的各個部分不匹配，只有各個部分平衡了，問題才會得到解決。

擁塞控制：防止過多的資料注入到網路，導致網路中的路由器或鏈路過載。

流量控制和擁塞控制的區別：可以看出流量控制是一個端到端的問題，而擁塞控制是一個全域性性問題，設計到所有的主機、所有的路由器。

慢開始：乘法增加

傳送方維持一個擁塞視窗cwnd，大小取決於網路的擁塞程度，動態地在變化。傳送視窗小於等於擁塞視窗，而傳送視窗一定不能超過接收視窗。傳送方控制擁塞視窗的原則是：只要網路沒有出現擁塞，擁塞視窗就增大一些，以便把更多的分組傳送出去。但是隻要網路出現擁塞，擁塞視窗就減小一些，以減少注入到網路的分組數。

開始時，如果傳送大量資料包，容易導致網路中路由器緩衝空間耗盡，從而發生擁塞。所以新建連線時，cwnd初始化為1個最大報文段(MSS)大小，每經過一個迭代，擁塞視窗就乘以2，所以也稱為乘法增加階段。擁塞視窗不可能一直增大，所以一般會設定一個慢開始門限ssthresh.

• 當cwnd<ssthresh時，使用慢開始演算法。
• 當cwnd>ssthresh時，改用擁塞避免演算法。

擁塞避免：加法增大

一旦達到慢開始的初始門限ssthresh,就進入了擁塞避免階段。每一個迭代，擁塞視窗加1，而不是加一倍

快重傳

快重傳演算法規定，傳送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設定的重傳計時器時間到期。快重傳策略是為了防止TCP連線因等待重傳計時器超時而空閒較長的時間。

快恢復

快重傳和快恢復是搭配使用的，快重傳完成後，立即執行快恢復演算法。將ssthresh門限設定為當前擁塞視窗的一半，之後將擁塞視窗設定為新的ssthresh門限(即減半), 進入擁塞避免階段。

這裡可能會有人有疑問，為什麼不直接進入慢開始階段，更徹底得避免擁塞。**主要的原因是考慮到如果網路出現擁塞得話，就不會收到多次重複確認，所以傳送方認為網路可能沒有出現擁塞，所以不執行慢開始演算法，而是將cwnd設定為新得ssthresh門限，執行擁塞避免演算法

尾聲

以薪資待遇為基礎，以發展為最終目標，要在高薪資的地方，謀求最好的發展！

下面是有幾位Android行業大佬對應上方技術點整理的一些進階資料。有Android架構視訊+BATJ面試專題PDF+核心筆記等資料。希望能夠幫助到大家提升技術。如果大家想要獲取的話，可以私信我【666】免費獲取哦