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