面試總結(jié)1
我是從來都不做面試總結(jié)的人梦抢，希望能就這些問題和大叫交流下～
這次面試問的都是和簡歷相關(guān)的知識般贼，還有就是其他的一些，在此做下記錄。
題目一：在你們項目中哼蛆，弱網(wǎng)環(huán)境下的網(wǎng)絡(luò)如何適配蕊梧，緩存策略是什么？
緩存策略
其實在我的項目中腮介，因為數(shù)據(jù)需求量比較小肥矢，我們在全局界面使用了一個名為UserInfo的一張表來存儲當(dāng)前App需要使用的模版數(shù)據(jù)，這個工作在每次登陸的時候會更新叠洗，每次在從后臺切入前臺的時候也會校驗芥喇，在必要的網(wǎng)絡(luò)請求中也會帶上一個Version的東西進(jìn)行校驗塔橡。
也就是說我會在我的用戶登陸的時候我就拿到接近15個左右的模版數(shù)據(jù)嗤练，我的界面邏輯（因為用戶不同把兔，界面是不同的）幾乎全部包含在內(nèi)。設(shè)計的字段包含有:見注1
這樣做本質(zhì)上是一個優(yōu)化策略名挥，而不是用來應(yīng)對弱網(wǎng)環(huán)境疟羹。其實這個答案已經(jīng)很接近緩存策略的正確答案了，我們拆分出來看禀倔，這個本質(zhì)上包含了3個東西:
- 本地數(shù)據(jù)緩存映射表以及過期時間（客戶端寫死）
- 本地要緩存的數(shù)據(jù)及Version
- 服務(wù)器數(shù)據(jù)
借鑒我之前看過的一篇文章榄融，主要內(nèi)容我在這里做下搬運： - 使用ETag來代替Version，一般使用Hash算法來生成救湖，這種方式是模仿Git對文件的緩存機(jī)制愧杯。
- 新增If_none_match字段，和ErrorCode=304字段來判斷數(shù)據(jù)是否與服務(wù)端一致鞋既。
- 新增響應(yīng)頭CC(Cache-Contorl), 來控制具體的緩存機(jī)制
| CC中的響應(yīng)頭 | 響應(yīng)頭描述 |
|---|---|
| max_age | 最大過期時間 |
| pubilc/private | 是否允許中間服務(wù)器（例如:CDN）來保存緩存信息 |
| no_cache | 客戶端使用緩存數(shù)據(jù)的時候必須與服務(wù)器進(jìn)行確認(rèn)后才可以使用 |
| no_store | 客戶端必須從服務(wù)器獲取新的數(shù)據(jù) |
使用了這種方式力九，就可以不用每次發(fā)版都更新客戶端的緩存策略了，只需要在客戶端維護(hù)一個緩存映射表邑闺，將緩存數(shù)據(jù)和映射數(shù)據(jù)當(dāng)作字段傳入跌前，做網(wǎng)絡(luò)請求的時候讀取就好了～
提高數(shù)據(jù)傳輸速度
之前我哥們給我講，弱網(wǎng)優(yōu)化上可以使用UDP協(xié)議+減少握手次數(shù)陡舅，從而減小時間上的開銷抵乓，回去翻了下書，UDP雖然比TCP速度更加快速靶衍，但是總體省略掉的是數(shù)據(jù)正確性和數(shù)據(jù)順序灾炭，UDP比TCP省略的是TCP中各種校驗位，而我們所說弱網(wǎng)不單單是網(wǎng)絡(luò)速度慢颅眶，而是網(wǎng)絡(luò)不穩(wěn)定蜈出，導(dǎo)致丟包率\時延比較大，相比于使用UDP協(xié)議我更傾向于使用更加安全的TCP協(xié)議帚呼。
UDP應(yīng)用場景： 1.面向數(shù)據(jù)報方式 2.網(wǎng)絡(luò)數(shù)據(jù)大多為短消息 3.擁有大量Client 4.對數(shù)據(jù)安全性無特殊要求5.網(wǎng)絡(luò)負(fù)擔(dān)非常重掏缎，但對響應(yīng)速度要求高
解釋
也就是本地維護(hù)一個映射文件，當(dāng)然這個文件要滿足以下幾個條件：
文件要從服務(wù)器上分發(fā)煤杀。
這個配置表要在本地可配置眷蜈。
要有默認(rèn)的配置，一般是全網(wǎng)都可以訪問的服務(wù)器沈自。
減少時延酌儒，和丟包
DNS
- 多服務(wù)器篩選：在啟動App之后，啟一個后臺進(jìn)程枯途，來掃描你們公司所有服務(wù)器域名的鏈接速度忌怎，和丟包率，優(yōu)先選擇服務(wù)器酪夷。在本地端口做適配榴啸。
- IP：使用IP地址而不是使用域名，（其實客戶端本身就存在DNS_cache機(jī)制晚岭，也有自己的過期策略鸥印，iOS端一般是24h/飛行模式/開關(guān)機(jī)/重置網(wǎng)絡(luò)），在做多服務(wù)器篩選表的時候我們可以順帶把這部分的東西一起做出來坦报。
界面和服務(wù)端
監(jiān)控優(yōu)化
- Web頁：在開發(fā)者模式下找到加載/運行緩慢的點库说，然后優(yōu)化。
- Image：使用緩存片择，并根據(jù)網(wǎng)絡(luò)判定請求圖片大小潜的，在經(jīng)過源哥指點下，這里還可以使用Web格式的Image來對Image進(jìn)行壓縮字管，感謝
- Data： 緩存json啰挪，使用游標(biāo)來確定當(dāng)前緩存的畫像-數(shù)據(jù)時效性要求差。
- Text&Image: 優(yōu)先加載Text數(shù)據(jù)嘲叔，Image數(shù)據(jù)延后加載
- Servers：使用慢查詢監(jiān)控脐供，并建立索引表。
容忍度
- 提示框：不從0開始借跪，而是從50%開始政己。
- 顯示預(yù)計時間= 實際預(yù)計時間/2
預(yù)加載
在WebView中我們可以使用本地Html，css掏愁，js文件來預(yù)加載歇由。
本地User_App界面數(shù)據(jù)采用數(shù)據(jù)預(yù)加載的方式。
User_info數(shù)據(jù)采用在登陸時候預(yù)先加載的方法是來做果港。
補(bǔ)充
其實我還看到很多優(yōu)化的方式沦泌，歡迎評論補(bǔ)充
- 如使用base64預(yù)先壓縮數(shù)據(jù)（雖然壓縮比能達(dá)到34%，但是一般在大數(shù)據(jù)上才做壓縮辛掠，小數(shù)據(jù)）谢谦。
- 如使用XML可以變解析邊下載释牺。但是我覺得有些靠譜，有些因為過于消耗性能回挽，有些因為需要代碼的統(tǒng)一没咙，被我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萬條數(shù)據(jù)的通訊錄千劈，你是如何存儲和展示的祭刚！
其實對于10萬條以內(nèi)的數(shù)據(jù)我認(rèn)為都沒必要對原生做大的修改，然后面試官又說還要顯示圖片什么的墙牌。涡驮。What？喜滨？加圖片捉捅？加圖片干嘛？虽风。锯梁。算了..考慮到我還是個初學(xué)者..在這里老老實實分析需求就好了。焰情。陌凳。
首先先簡單分析問題！
- 數(shù)據(jù)可能是沒有上限的内舟。需要考慮超級少人使用合敦，和超級多人使用的不同需求
- 因為涉及到圖片，可能需要設(shè)計下載验游，緩存充岛，渲染等
- 因為數(shù)據(jù)量龐大，是否使用數(shù)據(jù)庫耕蝉，建立一個什么樣的表
- 因為表格本身就涉及動畫的崔梗，更涉及到圖片，可能還會有圖片渲染的一些問題等～
- 可能涉及到??垒在，就是快速比較～
進(jìn)一步細(xì)化問題
- 圖片
下載到哪里蒜魄？Cache，F(xiàn)ileSystem
預(yù)處理场躯？時機(jī)
預(yù)處理的圖片是否緩存谈为。 - 動畫
使用什么方式加載Image：
（1）CGContextWithoutAlpha,
（2）CGContextWithAlpha,
（3）ImageIO,
（4）UIGraphic
是否在滑動時候阻斷動畫/使用更低質(zhì)量的圖？
是否在渲染的時候使用動畫踢关？ - 存儲
存儲方式SQL伞鲫？UserDefault？FailSystem签舞？
都存儲什么秕脓？UserInfo柒瓣？UserPhoto？ - 緩存
在加載/移出圖片的時候是否使用緩存吠架？ - 界面差異化
是否對500人以上的大客戶使用其他的界面代替掉當(dāng)前的界面芙贫？
是否對500人以上的大客戶使用不同的解決方案/遷移方案？
是否對500人以上的大客戶使用數(shù)據(jù)備份方案诵肛？容錯方案 - 查找
查找方式屹培？（1）SQL（2）內(nèi)存
逐一解答上面的問題
圖片
- 下載到哪里默穴？Cache怔檩，F(xiàn)ileSystem
首先在這里可以考慮使用FileSystem而不是Cache，因為這里的數(shù)據(jù)要保證用戶數(shù)據(jù)安全蓄诽，而不是使用一次就扔掉薛训，應(yīng)該對數(shù)據(jù)在下載的時候進(jìn)行保存，并留有副本～ - 預(yù)處理仑氛？時機(jī)乙埃、做什么
（1）在數(shù)據(jù)下載之后直接進(jìn)行預(yù)處理。
（2）對圖片進(jìn)行格式調(diào)整锯岖、去除透明通道介袜、圓角調(diào)整，分辨率調(diào)整出吹，小圖單獨存儲 - 預(yù)處理的圖片是否緩存遇伞。
只分文件夾存儲，不緩存捶牢。
動畫
- 使用什么方式加載Image：
（1）CGContextWithoutAlpha,
（2）CGContextWithAlpha,
（3）ImageIO,
（4）UIGraphic
SDWebImage使用的CGContextWithoutAlpha鸠珠，和CGContextWithAlpha，這兩種加載方式在在性能上由于UIGraphic秋麸，在單線程中ImageIO（370）卻優(yōu)于CGContextWithAlpha（550）渐排，可見蘋果在ImageIO上確實是下了大功夫的，但在多線程中CGContextWithAlpha（420）表現(xiàn)優(yōu)于ImageIO（730）灸蟆，由此可見在使用ImageIO可以能發(fā)揮更高的性能驯耻。（而且使用單線程就好了～）
- 是否在滑動時候阻斷動畫/使用更低質(zhì)量的圖？
在快速滑動的時候我建議是停止Image的繪制的炒考，在ScrollView的回調(diào)方法中可以做到
在慢速滑動的時候還是使用更加低質(zhì)量的圖片會讓幀數(shù)有更好的表現(xiàn)吓歇。 - 是否在渲染的時候使用動畫？
建議使用延遲加載的額方式票腰，而不是當(dāng)時加載～這個主要看需求～
存儲
存儲方式SQL城看？UserDefault？FailSystem杏慰？
照顧到可能需要查找测柠，應(yīng)該使用SQL炼鞠，SQL在iOS上支持的還是很好的。如果使用SQL就逃脫不了表的使用轰胁，這里要著重說一下谒主，面試官問我是否每一個索引都要建一張表？（索引為a的表赃阀、b的表……）Why?完全不理解為什么這么做..理由呢霎肯？速度快么？維護(hù)簡單榛斯？代碼簡潔观游？凸顯自己設(shè)計牛逼？感覺并不會啊..考慮到我還是個初學(xué)者這里需要大神指點驮俗！
都存儲什么懂缕？UserInfo？UserPhoto王凑？
是的都需要而且是分別存儲～
緩存
在加載/移出圖片的時候是否使用緩存搪柑？
不使用緩存～
界面差異化
- 是否對500人以上的大客戶使用其他的界面代替掉當(dāng)前的界面？
界面差異化其實是可以考慮的索烹，因為在小規(guī)模數(shù)據(jù)上工碾，Photo在查找人員上會很方便，但是在200人以上的時候就會大大不便了百姓，應(yīng)該更注重搜索和索引～這才是對用戶更大的幫助 - 是否對500人以上的大客戶使用不同的解決方案/遷移方案渊额？
可以考慮使用不同的解決方案，數(shù)據(jù)遷移方案應(yīng)該是統(tǒng)一的～ - 是否對500人以上的大客戶使用數(shù)據(jù)備份方案瓣戚？容錯方案
應(yīng)該強(qiáng)制讓500人以上用戶打開通訊錄備份功能端圈，導(dǎo)出功能應(yīng)該提供導(dǎo)出到通訊錄，但是不應(yīng)該提供其他的導(dǎo)出功能子库，畢竟考慮到用戶的隱私問題舱权，我們應(yīng)該盡可能把數(shù)據(jù)留在安全的地方！
我建議把容錯改成容災(zāi)方案仑嗅，在服務(wù)器保存一張更復(fù)雜的表格來加密存儲用戶數(shù)據(jù)宴倍！使用hash算法來做數(shù)據(jù)進(jìn)行校驗位！當(dāng)然這些都是在服務(wù)器中的仓技！～
查找
查找方式鸵贬？（1）SQL（2）內(nèi)存
SQL速度更慢，但是計算性能消耗并不多～
內(nèi)存速度快脖捻，實現(xiàn)難度大阔逼，計算性能消耗大仁者見仁吧～請各位大神指正～
后記 安全性
在考慮到這里的時候我就在想，我們的數(shù)據(jù)安全性誰來保證地沮，我們存在iPhone上的數(shù)據(jù)如果是被越獄的手機(jī)嗜浮，那樣其他的流氓軟件不是可以很輕易的獲取我們聯(lián)系人數(shù)據(jù)了么羡亩，如果上面有身份證號碼，這簡直不敢想象危融。嚇得我都炸毛了～
考慮到我是一個新手畏铆，隨便使用一個我們公司的通用密鑰算出publicKey，采用非對稱算法加密吧～反正注意到的人又不多吉殃。辞居。
