7.1.1eb頁麵–首元素渲染&頁麵加載完成
0）該項檢測說明：與actiity數據采集方式相同，eb頁麵都是借助app中的ebvieactivity來oadur，因此此處不論什麼業務，activity響應時延都是ebvieactivity的響應時延，基本相同。因此eb頁麵更關注的是首元素渲染何時可以讓用戶知道頁麵開始加載了。但eb頁麵的加載深受網絡質量的影響，因此這裡區分ifi和移動網絡。
1）ifi下，首元素渲染(展示到界麵上)2s，全頁麵數據加載完成3s。
2）移動網絡下最差2g），首元素渲染3s，全頁麵數據加載完成10s。
特殊說明：目前android手q，eb頁麵的加載都是在eb進程中，因此首次訪問涉及起進程耗時最後一次統計接近1s），因此1）2）的數據會有超標，需要在評估時適當放寬標準。
7.1.2eb頁麵使用離線緩存
0）該項檢測說明：當業務一次訪問需要加載的靜態資源jscss圖片）200k以上，且靜態資源不經常改變，就可以考慮使用離線包當然也可以考慮其他緩存實現方式，比如瀏覽器緩存）
7.1.3eb頁麵–按需加載
0）該項檢測目的：避免無端流量浪費，列表加載時默認加載一屏1015條數據），在首屏渲染完成後，滑動頁麵觸發第二屏加載。
1）檢測手段：fidder抓包查看首屏數據請求返回時的實際數據條數，分頁控製在合理的間隔內。注意：某個需求開發為了用戶體驗速度，層提出過偽加載一次性返回多頁數據，但前端隻展示一頁，下拉時展示第二頁），這點不行。
7.1.4eb頁麵–避免302請求
0）該項檢測目的：302臨時跳轉請求，原則上沒有必要，應儘量避免，因為一次跳轉肯定會浪費eb加載時間，但某些特殊原因有必須存在時，合流規範要求一次業務訪問302跳轉要2個
1）檢測手段：fidder抓包查看業務訪問所有請求的http返回狀態碼
7.1.5eb頁麵–避免404請求
0）該項檢測目的：沒有理由，任何情況都不允許404
1）檢測手段：fidder抓包查看業務訪問所有請求的http返回狀態碼
7.1.6eb頁麵–靜態文件(jscss)請求不能帶okie
0）該項檢測目的：無端流量耗費、也不安全
1）fidder熱點抓包分析請求頭，jscss靜態文件請求頭不能帶okie(如有特殊情況，請開發說明理由)
7.1.7eb頁麵(jscss)代碼必須壓縮
0）該項檢測說明：資源文件儘量壓縮減少流量消耗，空格注釋除了方便閱讀沒有任何作用，js混淆變量名替換）在壓縮js的同時也增強了分析難度。因此(jscss)代碼必須壓縮去除了空格注釋，js文件變量名變成ab等代替
1）fidder熱點抓包分析or資源文件直接pc訪問下載，檢查文件內容。
7.1.8eb頁麵http請求需經過gzip壓縮
0）該項檢測說明：http請求壓縮可進一步節省流量。
備注：但如離線包特彆注意對gzip壓縮的支持，出過不支持gzip導致壓縮包不可用的bug。
1）fidder熱點抓包分析，檢查ate
7.1.9eb頁麵–單張圖片60k
0）該項檢測說明：移動終端60k的圖片目前的分辨率下就已經很清晰了，沒必要浪費流量，除非滿足某些人高清查看需求時，也要先用縮略圖，按需主動觸發加載大圖
1）fidder熱點抓包分析
7.1.10eb頁麵圖片大小和尺寸檢查
所有的圖片尺寸都控製在以下範圍，720x1280(60k以內)、640x1136(50k以內)、480x800(40k以內)、190x284(15k以內)、152x182(10k以內)
7.1.11eb頁麵橫豎屏切換不會重新拉取數據
0）該項檢測說明：未做特殊處理時，橫豎屏切換導致的界麵重繪會重新網絡拉取eb數據，浪費流量。
1）使用ats性能監測工具，監控指定apk進程，程序穩定後，切換手機橫豎屏，觀察ats是否抓到流量新增