簡單逆向天貓的思考

    多Tab應用App使用中，第一個實質頁面的呈現速度和操做體驗，極大影響了用戶使用慾望和總體評價。對於電商App而言，首頁更直接關聯商品推介和訂單轉化。全部頁面中，首頁使用頻率最高，停留時間最長，極致優化良好佈局App首頁是收益極高的任務。
    筆者從UI和代碼等多切點分析天貓iPhone App首頁，在必定程度內復現編碼邏輯 。使用了網絡抓包、沙盒目錄分析、reveal 視圖層次、dump類頭文件、IDA內存尋址、LLDB越獄聯調等方式，將得到信息簡單篩選梳理，但願能對應用開發的童鞋有稍許幫助或者參考意義。

1、架構級服務支持
    1.圖片緩存，全權託管SDWebImageCache。SDWebImageCache在體驗和性能上都有很好的優化，並獲得長期開源維護。
    2.HotFix，使用了服務器下發JSPatch文件的方式，但不依賴JSPatch三方庫。JSPatch大約1600行OC和90行JS代碼，提供了核心功能。
    3.Hybrid，預加載H5全站至沙盒，從而能快速從Native切換至WebApp，在重大活動時能夠實時監控和維護界面而不至Crash。
    4.營銷支持，每一個頂級Native View所在VC，均在屏幕外實例化WVWebView(計劃替換UCWebView中)，以執行相似紅包雨等營銷活動。
    5.數據本地持久化，切合Cache、Perference、Library、tmp、Document各沙盒目錄特性。

2、數據源策略對用戶體驗的影響
    先以這樣一個前提條件爲基礎：首頁的佈局變更須要通過市場調研，給出充足理由；不然在很長一段時間內，首頁的佈局都是輕微或者基本不變化的。
     從這個前提出發，天錨首頁採用了這樣的策略：1.用戶新安裝App時有預置數據；2.優先本地數據實例化UI組件和初步繪製；3.服務器數據到達後從新繪製；4.完成一次服務器請求，變更的佈局文件被持久化，以供下次打開時用最新佈局；5.因爲新佈局可能在灰度測試中，新佈局不必定存放至持久化存儲位置(NCPersitentxxx)，但會存到至另一處(Preference)並優先使用。
    
    首頁的繪製下降對服務器數據返回的必然依賴，是目前大部分流行App的數據繪製選擇。有這樣幾個好處：1.增長信息推介機會。用戶在斷網狀況下也能瀏覽主頁，至少能瀏覽商品目錄樹，若有圖片緩存可獲更多信息； 2.優化界面呈現速度。等待網絡過程當中，能夠完成全部對象的實例化與繪製(天貓首頁並無重用此時實例化的對象或繪製，在網絡數據返回後，將重複一遍實例化和繪製過程。但各實例有canReuse屬性以支持重用)；3.提升用戶體驗。不須要在首頁彈出交互打斷的AlertController，實際上大部分App斷網時不會在首頁彈出Alert或只有空白頁。

    根據這些狀況主要測試幾個場景：1. 新安裝，斷網運行 ;  2.非新安裝，斷網運行，未清理Cache；3.非新安裝，斷網運行，已清理Cache；  4. 斷網運行，其它頁面網絡恢復，切回首頁；5.正常運行。
    場景一、3，天貓爲空目錄，但能看目錄樹；2有圖片和目錄；1爲持久化佈局，2和3多是新佈局，也多是持久化佈局；4圖片自動加載，佈局需手動刷新。

3、用ScrollView來實現一個lazilyScrollView的必要
    大部分APP的首頁爲了簡便起見，使用了tableView+collectionView的主要佈局，然而這都是很重的控件，尤爲是collectionView。若是從這個考慮，減小視層圖級出發，實現一個lazilyScrollView是有必要的，也是天貓首頁的選擇。
    
    而如何實現，使得更tableView同樣有新入屏重用，出屏釋放，須要設計和考慮的東西仍是不少的。而lazilyScrollView正是天貓首頁UI實現的精髓所在。
    但願能在近期內忠實的復現，然而不少屬性的用途，衆多方法的調用順序，仍是須要猜想和彙編驗證的，加油！