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