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