怎樣設(shè)計一個圖片緩存框架(基本框架)
- Manager
- 內(nèi)存緩存
- 磁盤緩存
- 網(wǎng)絡(luò)下載
- CodeManager
- 圖片解碼
- 圖片壓縮/解壓縮
圖片通過什么方式進(jìn)行讀寫，過程是怎么樣額？
- 以圖片URL的單向Hash值作為key 來存儲到存儲框架中
-
為什么要使用內(nèi)存為了提高系統(tǒng)的查找效率所以才要設(shè)置多級緩存，節(jié)省流量
圖片緩存的過程.png
-
內(nèi)存的設(shè)計上需要考慮哪些問題
- 存儲size
- 隊列方式存儲圖片，先進(jìn)先出
-
根據(jù)使用情況存儲10kb以下的 50個，100kb以下的20個，100kb以上的10個
根據(jù)使用情況來設(shè)置size的大小.png
- 淘汰策略
- 先進(jìn)先出的淘汰策略
- LRU 最近最久未使用算法， 如果30分鐘是否使用過
- 定時檢查，優(yōu)化：每次進(jìn)行讀寫的時，前后臺切換也可以去檢查
- 通過緩存大小清除
磁盤設(shè)計
- 存儲方式的選擇
- 大小限制(如100MB)
- 淘汰策略（距今超過7天）
網(wǎng)絡(luò)設(shè)計
- 圖片請求最大并發(fā)量
- 請求超時策略
- 重試機(jī)制
- 請求優(yōu)先級
圖片解碼
不同格式的圖片，解碼采用什么方式來做？
應(yīng)用策略模式對不同圖片格式進(jìn)行解碼
在哪個階段做圖片解碼處理？
磁盤讀取之后網(wǎng)絡(luò)請求后進(jìn)行圖片解碼。
圖片緩存過程？
怎么設(shè)計一個時長統(tǒng)計框架？
- 記錄管理者
- 記錄緩存模塊
- 內(nèi)存緩存在程序崩潰的時候懟是怎么辦，
- 磁盤來處理異常場景
- 上傳器 本地時長數(shù)據(jù)上傳給server
- 流式
- 記錄緩存模塊
- 記錄器 (記錄的數(shù)據(jù)交給記錄管理者進(jìn)行管理)
- 頁面式記錄器 用戶訪問一個頁面的時長
- 流式記錄器 訪問新聞閱讀時長記錄
- 自定義記錄器 橫條新聞播放有業(yè)務(wù)方控制
為何要有不同類型的記錄器，你的考慮是什么？
- 基于不同分類場景提供的關(guān)于記錄的封裝、適配
記錄的緩存*存儲
記錄的數(shù)據(jù)由于某些原因丟失，你怎么處理？
- 定時寫磁盤，每次滿足多少條就存儲磁盤
關(guān)于延時上傳的具體場景有哪些？
- 每滿多少條上傳
- 前后臺切換
- 無網(wǎng)到有網(wǎng)的變化
上傳時機(jī)是怎么樣把控的？
- 立即上傳
- 延遲上傳
- 定時上傳
復(fù)雜頁面架構(gòu)總結(jié)
MVVM框架思想
- View對MVVM有一個強引用，ViewModel作為view的成員變量，ViewModel可以通過block形式把輸出結(jié)果回傳給使用方，或者是RAC響應(yīng)式編程方來把對應(yīng)的輸出回傳給這個視圖
- View包含ViewController
- ViewModel對model有一個強引用，或者是成員變量，model可以用block或者代理會傳給Viewmodel
ReactNative的數(shù)據(jù)流思想
首先會反向回到根節(jié)點，通過自頂向下遍歷查找對應(yīng)打了臟標(biāo)記的節(jié)點，然后去更新對應(yīng)的視圖
任何一個子孫節(jié)點是沒法做自己的變化更新的。他必須把這個變化消息傳遞給根節(jié)點， 根節(jié)點自頂向下的順序去遍歷子孫節(jié)點，
從主動行為編程被動行為。
系統(tǒng)UIView更新機(jī)制的思想
微博正文頁，反向更新機(jī)制，實際上就是模擬了系統(tǒng)的UIView更新機(jī)制的思想，
UIView更新機(jī)制，就是UIView的繪制流程，調(diào)用UIView的setneedsplay只是給對應(yīng)視圖打了一個臟標(biāo)記，而它真正繪制的時候是在RunLoop將要結(jié)束時才進(jìn)行的實際繪制。view通過反向查找到對應(yīng)的ViewModel然后變更對應(yīng)的業(yè)務(wù)數(shù)據(jù)，打臟標(biāo)記，然后在下次reload之前去反向更新從新走一遍RN的數(shù)據(jù)流來驅(qū)動UI的變化，借鑒了系統(tǒng)UIView更新機(jī)制的思想
或者是借鑒了AsyncDisplayKit的預(yù)排版思想
FaceBook的開源框架AsyncDisplayKit關(guān)于預(yù)排版的設(shè)計思想
預(yù)排版，也是解決了性能方面的問題，也是性能優(yōu)化的一種
客戶端整體架構(gòu)面試問題
如何自己設(shè)計客戶端的整體架構(gòu)
- 獨立于App的通用層
- 時長統(tǒng)計、崩潰統(tǒng)計、網(wǎng)絡(luò)的第三方庫
- 通用的業(yè)務(wù)層
- 自定義的當(dāng)下公司業(yè)務(wù)相關(guān)的控件
- 中間層 協(xié)調(diào)解耦
- 業(yè)務(wù)A、業(yè)務(wù)B、業(yè)務(wù)C、業(yè)務(wù)D 中間層就是為了解耦這些業(yè)務(wù)
完全單獨拿出來一個業(yè)務(wù)A就能直接運用
業(yè)務(wù)之間的解耦通信方式
- OpenURL
- 依賴注入方式
依賴注入
業(yè)務(wù)A需要使用業(yè)務(wù)C的一些某些模塊，業(yè)務(wù)C、業(yè)務(wù)A不產(chǎn)生依賴就可以解耦，那么可以使用中間層，業(yè)務(wù)A通過中間層獲取業(yè)務(wù)C的方法和成員變量
iOS使用的時候， 讓某一個業(yè)務(wù)方注冊一個protocol，注冊到中間層當(dāng)中，同時實現(xiàn)中間層的代理方法，來返回給中間層具體的一個實例對象
然后業(yè)務(wù)A在使用的時候，通過跟其他業(yè)務(wù)開發(fā)人員商量好的協(xié)議，再從中間層中通過某一個方法
獲取遵從某個協(xié)議的實例然后在業(yè)務(wù)A當(dāng)中，把這個實例當(dāng)作完全遵從這個協(xié)議的透明對象來使用，這樣就接觸了業(yè)務(wù)A和業(yè)務(wù)C的耦合稱之為依賴注入
總結(jié)
圖片緩存設(shè)計
閱讀時長統(tǒng)計
時長統(tǒng)計數(shù)據(jù)丟失率
復(fù)雜頁面架構(gòu)
客戶端整體架構(gòu)
上層可以依賴下層 下層不能依賴上層
業(yè)務(wù)解耦
OpenUrl
依賴注入
