我們服務端rpc框架採用restful，其底層是curl實現的。curl採用http協議的，另外我們服務端的技術棧是php。我們都知道http協議相比較tcp而言，不僅多了http的報頭，php本身效能也是大問題。在不做大重構的情況下，怎麼做最小的修改，完成最大的效能提高。還是很有挑戰性的。
針對首屏介面，我們針對其完成了兩次效能優化。
將本來屬於乙個介面的內容，單獨在兩個請求中返回。第一屏api返回關鍵的資料，減少使用者初次進入的等待時間。第二屏，返回剩餘的大部分資料。具體api返回內容的劃分，是依賴客戶端渲染順序的。也沒絕對標準。但我們的原則是，第一屏api力所能及返回最少的資料，避免使用者等待。剩餘的留給第二屏的api去完成。分屏載入的難點有以下幾個。
確定好資料載入順序，最基礎的資料肯定是需要最先返回的，另外也要客戶端的同學配合
首屏內容是和使用者的懷孕狀態緊密聯絡在一起的，使用者切換寶寶(懷孕中切換到寶寶已出生，寶寶a切換到寶寶b)時，api的重新整理頻率怎麼控制。最後為了可操作性，採用了比較粗暴的做法，每次切換均會請求兩次介面。
完成分屏載入以後，使用者進入首頁的等待時間，已經由1-2s減為1s左右。不必像以前客戶端拿到全部內容後，才去渲染介面。現在只需要拿到第一屏的介面，即可完成介面的渲染工作。
分屏後第一屏介面耗時
分屏後第二屏介面耗時
通過在alpha壞境和beta壞境部署xhprof效能分析工具。我們可以看到實際的api在函式級別的效能損耗。這裡不詳述該工具的部署方式和使用方法。在xhprof的幫助下，我們得到了以下幾個結論。
rpc採用的是http協議，單純的rpc呼叫便接近10ms的耗時。首屏rpc呼叫次數接近30次。
每個rpc服務層內部，通過函式呼叫即可，也採用rpc的方式。
熱點資料直接查庫，快取利用率低下
資料表索引亂用，存在慢查詢。
結合上面幾點，在實際操作過程中，由簡到難，逐步完成。第一能減少rpc，便減少rpc請求。邏輯層資料由以前的多次獲取改為一次獲取。其次，服務層內部，不垮服務層不走rpc，直接以函式呼叫的方式請求。第三，熱點不變動的資料，直接在邏輯層快取，拿到後丟給api返回。第四，追蹤mysql慢查詢，優化查詢sql。完成後，實際效能如下
第二次優化第一屏介面耗時
第二次優化第二屏介面耗時
首屏優化策略
效能優化是程式開發中乙個永恆的話題，在當前全民 的大環境下，低端機型 弱網環境 頻寬限制依然占有市場很大的份額，前端頁面的快速呈現，不僅影響使用者的使用體驗，對使用者的閱讀深度 停留時長等都有比較深遠的影響。而在前端渲染優化中最重要的乙個是首屏渲染優化。把內容最快的呈現給使用者，提供及時的可互動方式...
關於首屏效能優化的總結 原創
這兩天一直在看首屏優化的文章，所以將其總結歸納一下，方便以後使用。相對於移動端的首屏優化，pc在有些方面要苛刻得多，主要是因為pc端有太多的東西想要讓使用者看到，這就 難免pc端的頁面大而 重 與我們現在 富客戶端 的概念想相呼應。本文目錄 以800x600畫素尺寸為標準，當瀏覽器載入頁面後看到第一...
關於首屏效能優化的總結 原創
這兩天一直在看首屏優化的文章，所以將其總結歸納一下，方便以後使用。相對於移動端的首屏優化，pc在有些方面要苛刻得多，主要是因為pc端有太多的東西想要讓使用者看到，這就 難免pc端的頁面大而 重 與我們現在 富客戶端 的概念想相呼應。本文目錄 以800x600畫素尺寸為標準，當瀏覽器載入頁面後看到第一...