關鍵詞：網站、APP、資料互動、資源加載、流程分析
1、分析過程
1.1、分析次元
互動分析重點：資源分布、通路排程、重要接口、使用者資訊、品質上報。
問題處理流程：發現異常、問題複現、分段分界、問題定位、優化處理。
1.2、關鍵接口與資源加載方式分析方式
1.3、資源分布與使用者通路流向統計
目的：APP資源分布位置與使用者通路流量的方向
特征：DNS解析記錄中包含有cdn或明顯資源辨別（例如img、mp3等）的域名及其指向的内容源。
以“今日頭條APP”為例：
其中域名“*tt.bytecdn.cn”為“位元組跳動CDN”的域名，其中資源基本上為頁面圖檔圖示，其解析位址部分在四川移動，有部分解析到了重慶移動。
其中域名“.pstatp.com”與“ .swcdn-tos.pstatp.com”為今日頭條的資源下載下傳域名，其中大部分域名解析首位址歸屬為四川移動，有部分解析至其他省份。
DNS解析記錄：
統計域名歸屬：
1.4、重要接口與資料互動分析
目的：APP中主要的接口，即關鍵域名及其相關的URL構造規則。
特征：有明顯具有相關特征（例如資源資訊、使用者資訊等）傳回值，或資源加載相關資訊的請求。
重要接口類型分析：
（1）使用者登入接口：
使用者登入過程，包括請求發起、鑒權、基礎資訊加載等。由于網絡安全需要，通常為加密内容，甚至拒絕HTTPS代理方式登入。
（2）域名解析方式（DNS接口）：
一般APP的域名解析方式為标準DNS協定，大部分APP采用标準DNS協定與HttpDNS協定相結合的方式進行域名解析，其中HttpDNS的構成由廠商自行定義，格式各異。通常特征為其中包含域名與IP的映射關系。
（3）資源排程接口（或資源資訊接口）：
APP中資源清單及其中資源資訊或頁面所顯示的内容的資訊。其中包含使用者請求的加載方式和資料互動過程中的中間件資料層資訊。可通過該接口調取APP中對應的資源資訊（例如歌曲或視訊的清單）。
（4）資源加載接口：
資源加載請求的構造方式以及資源請求清單。通常包含資源 特征（例如img、mp4等），或URL域名部分包含IP位址。使用者對此類URL發起通路來下載下傳資源。
（5）使用者資訊與事件上報接口：
使用者資訊（賬号、手機号碼、IMEI号碼、IP位址等）與使用者請求的關聯方式，使用者通路、視訊播放、資源下載下傳等事件的資訊上報（一般在URL中包含有相關字段資訊或ID）。
1.4.1、APP使用者登入接口
使用者登入方式：通常APP将支援多種登入方式。
（1）賬号密碼登入
此為較正常的用戶端登入方式，采用此類登入方式的使用者整逐漸減少。使用者發起登入請求，調用相關頁面與鑒權接口，上傳相關資訊。此過程中密碼資訊需進行加密處理。
（2）短信驗證碼登入
此為目前比較常用的登入方式。使用者發起登入流程，上傳手機号碼驗證其準确性後，用戶端将調用短信驗證服務（包含自主驗證或采用三方服務方式），驗證成功則加載使用者資訊。
（3）三方賬号代登入
較為常見的代登入方式支援包括：微信、QQ、微網誌等賬号的代登入。
此類登入過程通常為由代登入服務提供方提供專有代登入API接口，APP通過申請獲得對應的APPID，當用戶端發起登入請求時，首先拉起本機上的相關應用（部分服務不需要再本機安裝對應APP，則無需此過程），擷取授權碼（code），用戶端将授權碼與本應用在服務提供方的注冊APPID發送至代登入認證服務端，然後通過多次的鑒權互動過程，獲得登入認證。
根據APP設定不同，登入成功後進行不同的設定，例如部分APP在鑒權成功後直接授權使用者通路，不在進行其他操作；部分APP則将代登入授權資訊與自有資料庫中使用者資訊綁定（若無賬号則強制使用者注冊），後切換為自有新增賬號進行應用操作。
1.4.2、APP資源資訊接口示例
以電商APP為例，在頁面所顯示的資訊加載過程中，服務端将通過Json等方式向用戶端傳送商品相關清單資訊，用戶端通過該清單中的商品基礎資訊在頁面顯示，當使用者需要進一步擷取相關資訊時，可通過該清單中的唯一辨別（例如商品ID），構造URL，通路詳細資訊。
以“蘇甯易購APP”為例：
1.4.3、APP資源加載接口示例
目的：資源加載或排程方式與接口（商品詳細資訊頁面加載）。
特征：包含有資源資訊、URL或資源URL的構造方式。例如構造URL所需的關鍵字段資訊等。根據APP實作的邏輯結構不同，資源資訊清單與資源加載排程接口可能我同一過程，也可能分為多個步驟。
（1）如示例：當使用者觸發資源請求時，以商品ID等資訊為參數，根據固有規則形成URL，用以加載相關資訊頁面。
（2）對于圖檔視訊等資源，根據APP的用途不同，加載方式存在較大差異，例如此示例中APP為電商類，其中視訊和圖檔皆為輔助内容顯示作用，其URL均根據以固定方式将URL寫在相關請求的傳回值中。
1.4.4、APP資源加載接口示例2
目的：資源加載或排程方式與接口（視訊或圖檔資訊加載）。
以電商類APP“蘇甯易購”為例：
通過商品資訊請求的傳回值中傳回的資訊指定URL。
加載獲得相關的圖檔或視訊資訊：
1.4.5、APP使用者資訊、品質資訊、事件上報接口示例
應用用戶端通常會通過某些特定接口對用戶端的品質資訊、使用者資訊、使用者操作事件等内容進行回傳，用以作為品質分析或使用者行為分析的依據。
示例：“QQ音樂APP”調用内置浏覽器的性能測試接口進行診斷測速：
其中上傳内容包括：使用者位置資訊、使用者IP位址、本地DNS節點IP、用戶端作業系統、網速等。
1.5、不同環境下的差異分析
2、案例
（1）目标：擷取咪咕閱讀APP資源清單與使用者請求排程過程（部分）
（2）問題解析：即需要分析使用者是通過什麼流程從打開APP一步一步到閱讀書籍内容。該過程中經過哪些步驟，這些步驟中涉及到哪些資料互動，其中可以為我所用的資訊有哪些（例如頁面構成，排程資訊（告訴用戶端下一步該怎麼做）、書籍清單（可以統計相關内容作為資源庫）、書籍請求連結（可以用來統計使用者行為或閱讀偏好））。
（3）通常APP資料互動過程：使用者從打開APP（過程略）→選擇進入資料分類頁面（該頁面資訊如何加載） →選擇一類圖書（使用者如何進入分類頁面） →選擇一本圖書（使用者如何進入該圖書的資訊詳情） →開始閱讀（使用者如何從資訊詳情跳轉進入資料内容）。
（4）互動分析：
清空手機緩存，打開頁面執行加載，抓取過程中的資料包。注意抓包範圍不宜過大（頁面加載之前開始，到加載完成停止），不宜太長，以免請求過多難以區分有用資訊。
根據碼流内容逐一尋找有用資訊，排除圖檔等請求（URL中帶有jpg等字樣的内容），注意jsp類檔案。打開相關包（Fllow HTTP Strem），檢視其中内容。（wireshark中藍紅色字型為請求、藍色字型為響應）。
根據資料互動過程層層向下，梳理資料互動流程，分析每步URL的構造方式和檔案位置。
1、書籍分類資訊。
2、該類型中書籍清單：該清單中至少應包含書籍名稱或ID等重要資訊。
3、資料詳情頁面：該頁面中包含有大量書籍相關屬性資訊。
一般此類按照類型層層向下鑽去的請求中，每一層級的連結通常是以其ID作為參數，根據固定的規則構造URL。
通常越接近底層的資訊清單中包含有越多的資訊。
一般資源加載過程為通過其ID來進行資源擷取。即資源擷取請求可能為固定格式的URL，以不同的資源ID作為參數。
資源中帶有的屬性或頁面的功能越多，頁面越複雜重要資訊越難以發現。需剔除其頁面樣式等無關内容的資訊。
（5）APP分析報告資源排程資訊：
3、備注
1、分析過程中，部分品質問題定界需關注底層通信協定，其他分析主要注意其資訊的互動過程。
2、由于各ICP的安全防護品質不一方法各異，需采用多種工具多種方式結合分析；有部分應用安全級别較高（例如騰訊旗下應用安全等級較高），采用公共的代理方式抓包工具可能無法解析。
3、根據實際需求，從不同的角度和思路分析解決問題。重點關注資源排程和使用者資訊與其行為的關聯。
4、不同類型APP由于其功能和邏輯結構不同，其資料互動方式存在差異；同類APP由于功能類似，可以互相印證參考。
5、由于HTTPS協定加密，部分内容無法解析，可通過網頁端的應用，利用同一應用中某些内容的共通性，用浏覽器内置調試工具對分析内容進行驗證。
6、本文所有案例均來自多年之前，現已無法用于實際分析。上述方案僅供技術交流，請勿随意嘗試解析他人網頁或APP。