面試總結1
我是從來都不做面試總結的人，希望能就這些問題和大叫交流下～
這次面試問的都是和簡歷相關的知識，還有就是其他的一些，在此做下記錄。
題目一：在你們項目中，弱網環境下的網絡如何適配，緩存策略是什么？
緩存策略
其實在我的項目中，因為數據需求量比較小，我們在全局界面使用了一個名為UserInfo的一張表來存儲當前App需要使用的模版數據，這個工作在每次登陸的時候會更新，每次在從后臺切入前臺的時候也會校驗，在必要的網絡請求中也會帶上一個Version的東西進行校驗。
也就是說我會在我的用戶登陸的時候我就拿到接近15個左右的模版數據，我的界面邏輯（因為用戶不同，界面是不同的）幾乎全部包含在內。設計的字段包含有:見注1
這樣做本質上是一個優化策略，而不是用來應對弱網環境。其實這個答案已經很接近緩存策略的正確答案了，我們拆分出來看，這個本質上包含了3個東西:
- 本地數據緩存映射表以及過期時間（客戶端寫死）
- 本地要緩存的數據及Version
- 服務器數據
借鑒我之前看過的一篇文章，主要內容我在這里做下搬運： - 使用ETag來代替Version，一般使用Hash算法來生成，這種方式是模仿Git對文件的緩存機制。
- 新增If_none_match字段，和ErrorCode=304字段來判斷數據是否與服務端一致。
- 新增響應頭CC(Cache-Contorl), 來控制具體的緩存機制
| CC中的響應頭 | 響應頭描述 |
|---|---|
| max_age | 最大過期時間 |
| pubilc/private | 是否允許中間服務器（例如:CDN）來保存緩存信息 |
| no_cache | 客戶端使用緩存數據的時候必須與服務器進行確認后才可以使用 |
| no_store | 客戶端必須從服務器獲取新的數據 |
使用了這種方式，就可以不用每次發版都更新客戶端的緩存策略了，只需要在客戶端維護一個緩存映射表，將緩存數據和映射數據當作字段傳入，做網絡請求的時候讀取就好了～
提高數據傳輸速度
之前我哥們給我講，弱網優化上可以使用UDP協議+減少握手次數，從而減小時間上的開銷，回去翻了下書，UDP雖然比TCP速度更加快速，但是總體省略掉的是數據正確性和數據順序，UDP比TCP省略的是TCP中各種校驗位，而我們所說弱網不單單是網絡速度慢，而是網絡不穩定，導致丟包率\時延比較大，相比于使用UDP協議我更傾向于使用更加安全的TCP協議。
UDP應用場景： 1.面向數據報方式 2.網絡數據大多為短消息 3.擁有大量Client 4.對數據安全性無特殊要求5.網絡負擔非常重，但對響應速度要求高
解釋
也就是本地維護一個映射文件，當然這個文件要滿足以下幾個條件：
文件要從服務器上分發。
這個配置表要在本地可配置。
要有默認的配置，一般是全網都可以訪問的服務器。
減少時延，和丟包
DNS
- 多服務器篩選：在啟動App之后，啟一個后臺進程，來掃描你們公司所有服務器域名的鏈接速度，和丟包率，優先選擇服務器。在本地端口做適配。
- IP：使用IP地址而不是使用域名，（其實客戶端本身就存在DNS_cache機制，也有自己的過期策略，iOS端一般是24h/飛行模式/開關機/重置網絡），在做多服務器篩選表的時候我們可以順帶把這部分的東西一起做出來。
界面和服務端
監控優化
- Web頁：在開發者模式下找到加載/運行緩慢的點，然后優化。
- Image：使用緩存，并根據網絡判定請求圖片大小，在經過源哥指點下，這里還可以使用Web格式的Image來對Image進行壓縮，感謝
- Data： 緩存json，使用游標來確定當前緩存的畫像-數據時效性要求差。
- Text&Image: 優先加載Text數據，Image數據延后加載
- Servers：使用慢查詢監控，并建立索引表。
容忍度
- 提示框：不從0開始，而是從50%開始。
- 顯示預計時間= 實際預計時間/2
預加載
在WebView中我們可以使用本地Html，css，js文件來預加載。
本地User_App界面數據采用數據預加載的方式。
User_info數據采用在登陸時候預先加載的方法是來做。
補充
其實我還看到很多優化的方式，歡迎評論補充
- 如使用base64預先壓縮數據（雖然壓縮比能達到34%，但是一般在大數據上才做壓縮，小數據）。
- 如使用XML可以變解析邊下載。但是我覺得有些靠譜，有些因為過于消耗性能，有些因為需要代碼的統一，被我pass。
附錄
注1
[user:（id, name, token, version, sig, update, next_update）] SQL如下
[viewData:(hash_token, view_id, view_data, version)]
create table
if not exists User (
id int primary key AUTO_INCREMENT,
name varchar(16)
token int,
version int,
sig int,
update int,
next_update int
);
注2:
題目二： 2萬條數據的通訊錄，你是如何存儲和展示的！
其實對于10萬條以內的數據我認為都沒必要對原生做大的修改，然后面試官又說還要顯示圖片什么的。。What？？加圖片？加圖片干嘛？。。算了..考慮到我還是個初學者..在這里老老實實分析需求就好了。。。
首先先簡單分析問題！
- 數據可能是沒有上限的。需要考慮超級少人使用，和超級多人使用的不同需求
- 因為涉及到圖片，可能需要設計下載，緩存，渲染等
- 因為數據量龐大，是否使用數據庫，建立一個什么樣的表
- 因為表格本身就涉及動畫的，更涉及到圖片，可能還會有圖片渲染的一些問題等～
- 可能涉及到??，就是快速比較～
進一步細化問題
- 圖片
下載到哪里？Cache，FileSystem
預處理？時機
預處理的圖片是否緩存。 - 動畫
使用什么方式加載Image：
（1）CGContextWithoutAlpha,
（2）CGContextWithAlpha,
（3）ImageIO,
（4）UIGraphic
是否在滑動時候阻斷動畫/使用更低質量的圖？
是否在渲染的時候使用動畫？ - 存儲
存儲方式SQL？UserDefault？FailSystem？
都存儲什么？UserInfo？UserPhoto？ - 緩存
在加載/移出圖片的時候是否使用緩存？ - 界面差異化
是否對500人以上的大客戶使用其他的界面代替掉當前的界面？
是否對500人以上的大客戶使用不同的解決方案/遷移方案？
是否對500人以上的大客戶使用數據備份方案？容錯方案 - 查找
查找方式？（1）SQL（2）內存
逐一解答上面的問題
圖片
- 下載到哪里？Cache，FileSystem
首先在這里可以考慮使用FileSystem而不是Cache，因為這里的數據要保證用戶數據安全，而不是使用一次就扔掉，應該對數據在下載的時候進行保存，并留有副本～ - 預處理？時機、做什么
（1）在數據下載之后直接進行預處理。
（2）對圖片進行格式調整、去除透明通道、圓角調整，分辨率調整，小圖單獨存儲 - 預處理的圖片是否緩存。
只分文件夾存儲，不緩存。
動畫
- 使用什么方式加載Image：
（1）CGContextWithoutAlpha,
（2）CGContextWithAlpha,
（3）ImageIO,
（4）UIGraphic
SDWebImage使用的CGContextWithoutAlpha，和CGContextWithAlpha，這兩種加載方式在在性能上由于UIGraphic，在單線程中ImageIO（370）卻優于CGContextWithAlpha（550），可見蘋果在ImageIO上確實是下了大功夫的，但在多線程中CGContextWithAlpha（420）表現優于ImageIO（730），由此可見在使用ImageIO可以能發揮更高的性能。（而且使用單線程就好了～）
- 是否在滑動時候阻斷動畫/使用更低質量的圖？
在快速滑動的時候我建議是停止Image的繪制的，在ScrollView的回調方法中可以做到
在慢速滑動的時候還是使用更加低質量的圖片會讓幀數有更好的表現。 - 是否在渲染的時候使用動畫？
建議使用延遲加載的額方式，而不是當時加載～這個主要看需求～
存儲
存儲方式SQL？UserDefault？FailSystem？
照顧到可能需要查找，應該使用SQL，SQL在iOS上支持的還是很好的。如果使用SQL就逃脫不了表的使用，這里要著重說一下，面試官問我是否每一個索引都要建一張表？（索引為a的表、b的表……）Why?完全不理解為什么這么做..理由呢？速度快么？維護簡單？代碼簡潔？凸顯自己設計牛逼？感覺并不會啊..考慮到我還是個初學者這里需要大神指點！
都存儲什么？UserInfo？UserPhoto？
是的都需要而且是分別存儲～
緩存
在加載/移出圖片的時候是否使用緩存？
不使用緩存～
界面差異化
- 是否對500人以上的大客戶使用其他的界面代替掉當前的界面？
界面差異化其實是可以考慮的，因為在小規模數據上，Photo在查找人員上會很方便，但是在200人以上的時候就會大大不便了，應該更注重搜索和索引～這才是對用戶更大的幫助 - 是否對500人以上的大客戶使用不同的解決方案/遷移方案？
可以考慮使用不同的解決方案，數據遷移方案應該是統一的～ - 是否對500人以上的大客戶使用數據備份方案？容錯方案
應該強制讓500人以上用戶打開通訊錄備份功能，導出功能應該提供導出到通訊錄，但是不應該提供其他的導出功能，畢竟考慮到用戶的隱私問題，我們應該盡可能把數據留在安全的地方！
我建議把容錯改成容災方案，在服務器保存一張更復雜的表格來加密存儲用戶數據！使用hash算法來做數據進行校驗位！當然這些都是在服務器中的！～
查找
查找方式？（1）SQL（2）內存
SQL速度更慢，但是計算性能消耗并不多～
內存速度快，實現難度大，計算性能消耗大仁者見仁吧～請各位大神指正～
后記 安全性
在考慮到這里的時候我就在想，我們的數據安全性誰來保證，我們存在iPhone上的數據如果是被越獄的手機，那樣其他的流氓軟件不是可以很輕易的獲取我們聯系人數據了么，如果上面有身份證號碼，這簡直不敢想象。嚇得我都炸毛了～
考慮到我是一個新手，隨便使用一個我們公司的通用密鑰算出publicKey，采用非對稱算法加密吧～反正注意到的人又不多。。
