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