場景題/智力題
來自網路上到處收集
文章目錄
在弱網環境下，如何確保一個請求傳送成功/如何提高http連線成功率？
弱網環境會存在的問題：
丟包、錯包、亂包。
高延遲：響應資料回來時間長，甚至大於客戶端等待時間
頻寬小：每次通訊的內容少，資料包越大受影響越大
網路斷續：網路經常斷開又連線，類似於經常出入電梯
弱網下優化處理：
參考：弱網環境下的網路效能調優 - 紅嘴鯉魚 - 部落格園
1、採用TCP協議、實現長連線
2、採用長連線池，節省握手時間
3、採用ProtocolBuffer，減少冗餘資料（相比xml）
4、棄用DNS，直接使用IP，減少了請求DNS服務查詢IP的時間，避免被DNS劫持
5、加入重試機制，提供成功率
6、使用Http 2.0，壓縮頭部、長連線更加徹底、支援推送、支援（Multiplexing：支援一個TCP連線上同時實現多個請求和響應。）
7、超時時間設定可以適當延長（限制放寬一點）
參考：在弱網環境下HTTPS比起HTTP來是否會讓移動應用的體驗顯著變差？ - 知乎
可以將https切換為http:
參考：弱網環境下如何優化網路請求_free_android的部落格-CSDN部落格
1、 前後端採用gzip方式請求和響應
前端在請求header新增：“content-encoding” 為 “gzip”
後端也要開啟gzip，才能生效
相比不採用gzip的請求方式，能節省流量，可以快速響應
android：OKHttp請求框架預設支援gzip，不需要額外配置。
參考：弱網搭建及模擬工具，弱網或無網狀態下 App的優化，弱網優化，網路優化(DNS/HttpDNS)_ShareUs的專欄-CSDN部落格
1、斷線重連。這可能是最重的一個特性，因為在無線網路中有太多的原因導致資料連線中斷了。這裡可以使用CDN。(CDN 是構建在資料網路上的一種分散式的內容分發網。 CDN 的作用是採用流媒體伺服器叢集技術，克服單機系統輸出頻寬及併發能力不足的缺點，可極大提升系統支援的併發流數目，減少或避免單點失效帶來的不良影響。)
3、優化DNS查詢。應儘量減少DNS查詢、避免域名劫持、DNS汙染，同時把使用者排程到“最優接入點”。
4、減小資料包大小和優化包量。通過壓縮、精簡包頭、訊息合併等方式，來減小資料包大小和包量。
5、控制資料包大小不超過1500，避免分片。包括邏輯鏈路控制(Logic Link Control)分片、GGSN分片，以及IP分片。其中，當資料包大小超出GGSN所允許的最大大小時，GGSN的處理方式有以下三種：分片、丟棄和拒絕。
6、優化TCP socket引數，包括：是否關閉快速回收、初始RTO、初始擁塞視窗、socket快取大小、Delay-ACK、Selective-ACK、TCP_CORK、擁塞演算法(westwood/TLP/cubic)等。做這件事情的意義在於：由於2G/3G/4G/WIFI/公司內網等接入網路的QoS差異很大，所以不同網路下為了取得較好的服務質量，上述引數的取值差異可能會很大。
7、優化ACK包。在弱網路的情況下，TCP協議中的ACK包是非常昂貴的，延時甚至能夠達到秒級別，而TCP協議的擁塞控制、快速重傳、快速恢復等特性都非常依賴接收端反饋的ACK包。可想而知，如果傳送端接收到的ACK包延時太長，會嚴重影響TCP協議的效率。但是如果傳送ACK太多又會佔用寶貴過多的無線資源。在行動網路下通訊，“在可靠的連線上，如何在減少ACK包的情況下，降低資料包的延時”是研究的熱點。基本的思想：平衡冗餘包和ACK包個數，達到降低延時，提高吞吐量的目的。
app如何精準校時(客戶端的時間如何與服務端的時間進行較準?)
客戶端與伺服器端時間校準_Jason Wang-CSDN部落格
1、伺服器端永遠使用UTC時間，包括引數和返回值，不要使用Date格式，而是使用UTC時間1970年1月1日的差值，即long型別的長整數。
2、APP端將伺服器返回的long型時間轉換為GMT8時區的時間，額外加上8小時，這樣就保證了無論使用者在哪個時區，他們看到的時間都是同一個時間，也就是GMT8的時間。
3、APP本地時間會不準，少則差幾分鐘，多則十幾分鍾，要解決這個問題，我們可以使用HTTP Response頭的Date屬性，每次呼叫伺服器介面時就取出HTTP Response頭的Date值，轉換為GMT時間，再減去本地取出的時間，得到一個差值d，我們將這個差值d儲存下來。每次獲取本地時間的時候，額外加上這個差值d,就得到了伺服器的GMT8時間，就保證了任何人看見的時間都是一樣的。
或者：如何計算遊戲客戶端與伺服器之間的時間延遲？_huangquanxi的專欄-CSDN部落格：
計算客戶端與伺服器之間的時間延遲：
1）客戶端A先記錄自己的本地時間TA1，然後給伺服器發B傳送一個報文。
2）伺服器B收到報文之後，記錄自己的本地時間TB，然後把TB放入報文裡傳送給客戶端A。
3）客戶端A收到資訊之後，記錄下收到報文的時間TA2.
由於報文往返的時間是相等的，所以客戶端傳送給伺服器的時間延遲P = （TA2 - TA1）/ 2。一般，P只計算一次是不夠精確的。我們可以讓客戶端A定時的給伺服器B傳送測量資訊，然後計算P的平均值。
如果我們想要知道客戶端和伺服器的本地時間差，可以怎麼獲取呢？
也是可以通過公式計算出來的
我們可以先假設A和B的本地時鐘是一樣的（當然這個假設明顯不成立），那麼
TB = TA1 + P ，把上面的P套入公式，整理後可以得TB = (TA1 + TB2) / 2
可是實際上A和B之間是有時間差X的，於是 TB + X = （TA1 + TB2）/ 2
整理後可得X = （TA1 + TB2）/ 2 - TB
一個app在啟動的時候有很多模組要載入，一個模型就要使用一個執行緒，怎樣限制執行緒的最大使用數量？
設定一個訊號量作為最大執行緒併發數，通過PV操作來同步和限制每個時刻的執行緒併發數。
兩根不均勻的香，1小時燒完，怎麼得到15分鐘
1、同時點上其中一根香的兩頭，另一根只點一頭；
2、當點兩頭那根香燃完時，時間過去半小時，另一根香剩下的可以燃半小時，再點上它的另一頭（開始計時）；
3、當這根香燃完時,時間為15分鐘。
門外3個開關，門內三盞燈，門外看不到門內的狀況，只能進去一次，怎麼確定所以開關對應哪個燈？
假如有K1、K2、K3三個開關，先開啟K1、K2等一段時間後， 關掉K2。
然後進門，這時有一個亮著的燈就是K1控制，再有手去摸下不亮的兩個燈，有發熱的就是K2控制，不熱的就是K3控制。