現(xiàn)階段所屬團隊開發(fā)設計的是一款母嬰用品，集*工具和小區(qū)特性。截至文中公布，申請注冊用戶貼近7000萬，首屏接口日瀏覽量過上百萬。在首屏中，會給用戶呈現(xiàn)不一樣的數(shù)據信息，例如每日每日任務，寶寶（寶寶）每日簡述，胎教音樂，運動視頻，帖子等控制模塊。
首屏接口性能的優(yōu)劣，將同時危害到app的應用感受。大家服務器端RPC架構選用RESTful，其較底層是curl完成的。curl選用http協(xié)議的，此外大家服務器端的技術棧是PHP。眾所周知http協(xié)議相較為TCP來講，不但多了http的報頭，PHP自身性能也是問題。在沒有做大重新構建的情形下，如何做較少的改動，進行較好的性能提升。或是很有創(chuàng)造性的。對于首屏接口，大家對于其完成了2次性能提升。
分屏載入
將原本歸屬于一個接口的內容，獨立在2個要求中返回。*屏API返回重要的數(shù)據信息，降低用戶**進到的等待的時間。*二屏，返回剩下的絕大多數(shù)數(shù)據信息。實際API返回內容的區(qū)劃，是依靠手機客戶端3D渲染次序的。也沒肯定規(guī)范。但人們的基本原則是，*屏API有意義的事返回至少的數(shù)據信息，防止用戶等候。剩下的交給*二屏的API去進行。分屏載入的難題有下面好多個。
1. 明確好數(shù)據加載次序，較根本的數(shù)據信息肯定是必須較開始返回的，此外也需要手機客戶端的同學們相互配合
2. 首屏內容是和用戶的孕期情況密切聯(lián)系在一起的，用戶轉換寶寶(孕期中轉換到寶寶已出世，寶寶A轉換到寶寶B)時，API的刷新頻率如何操縱。較終為了*好地可執(zhí)行性，選用了較為暴力的作法，每一次轉換均會要求2次接口。
進行分屏載入之后，用戶進入首頁的等待的時間，早已由1-2S減至1S上下。無須像之前手機客戶端**所有內容后，才去3D渲染頁面。如今只必須***屏的接口，就可以進行頁面的3D渲染工作中。
xhprof性能剖析
根據在alpha環(huán)境和beta壞境布署Xhprof性能分析工具。我們可以見到具體的API在函數(shù)公式等級的性能耗損。這兒不詳細描述該*工具的布署方法和操作方法。
在Xhprof的幫助下，大家**了下列好多個結果。
1. RPC選用的是HTTP協(xié)義，單純性的RPC讀取便貼近10MS的用時。首屏RPC讀取頻次貼近30次。
2. 每一個RPC服務項目層內部，根據函數(shù)調用就可以，也選用RPC的方法。
3. 網絡熱點數(shù)據信息立即查庫，緩存文件使用率不高
4. 數(shù)據分析表數(shù)據庫索引濫用，存有慢查詢。融合上邊幾個方面，在操作環(huán)節(jié)中，由簡到難，逐漸進行。*能降低RPC，便減少RPC要求。邏輯性層數(shù)據信息由之前的多次獲得改成一次獲得。次之，服務項目層內部，不垮服務項目層不動RPC，立即以函數(shù)調用的方法要求。*三，網絡熱點不變化的數(shù)據信息，立即在邏輯性層緩存文件，**后丟給API返回。*四，跟蹤MYSQL慢查詢，提升查看SQL。
*二次提升*屏接口用時
*二次提升*二屏接口用時
