• 背景

自己開(kāi)發(fā)的微信小程序，因?yàn)榭紤]到流量不大的緣故，一直使用的單服務(wù)器的架構(gòu)，這樣做的好處是能將運(yùn)維成本維持在一個(gè)很低的價(jià)格。但是隨著業(yè)務(wù)迭代以及用戶數(shù)量的積累，慢慢開(kāi)始出現(xiàn)性能不足的情況。

• 問(wèn)題

小程序首次熱啟動(dòng)的情況下，頁(yè)面加載緩慢，拿活動(dòng)頁(yè)舉例從點(diǎn)擊跳轉(zhuǎn)開(kāi)始到渲染完成耗時(shí)在5秒以上，這導(dǎo)致用戶在使用的時(shí)候體驗(yàn)極差，有時(shí)會(huì)主動(dòng)要求轉(zhuǎn)為線下支付，所以在這種場(chǎng)景下，一個(gè)優(yōu)化方案應(yīng)運(yùn)而生。

• 分析

首先在使用cos之前也試過(guò)其他方案：

1. 微信小程序 image 元素自帶的 lazy-load 功能，但是效果并不明顯，因?yàn)閼屑虞d是對(duì)當(dāng)前頁(yè)面3~4屏外的內(nèi)容施行懶加載的策略，而實(shí)際的場(chǎng)景連當(dāng)前這一屏的內(nèi)容渲染都很吃力。

2. 縮小圖片分辨率，這個(gè)方式確實(shí)是有效果的，但是優(yōu)化限度非常有限，因?yàn)榻档头直媛实那疤岜仨毐ＷC圖片的可讀性，當(dāng)大圖出現(xiàn)小字的時(shí)候優(yōu)化限度基本為0。

連續(xù)試了兩個(gè)方法效果都不理想，只能重新想辦法了，前面說(shuō)了這個(gè)項(xiàng)目是單服務(wù)器的架構(gòu)，所有的靜態(tài)資源也都保存在服務(wù)器上，需要時(shí)直接訪問(wèn)地址即可。但是當(dāng)我們點(diǎn)開(kāi)首頁(yè)的時(shí)候需要同時(shí)加載十幾張圖片，其中不乏1~2m的圖片，以服務(wù)器4m的帶寬來(lái)說(shuō)壓力太大，所以考慮將本地的靜態(tài)資源存儲(chǔ)到云，以此減輕服務(wù)器壓力，從而達(dá)到提升性能的目的。

綜上所述，能不花錢的方案基本都試了一下，效果不盡如人意，所以最后還是決定將本地存儲(chǔ)的靜態(tài)資源(圖片為主)遷移到cos上去。

• 計(jì)劃

1. 安裝cos的sdk

本地開(kāi)發(fā)的話composer直接引入依賴即可，需要注意的是正式環(huán)境部署的時(shí)候如果你vendor包內(nèi)的東西一起上傳了，需要執(zhí)行一下

否則composer無(wú)法檢測(cè)到新裝的依賴。如果沒(méi)有上傳vendor的就進(jìn)終端直接require一下就好了。

另外cos官方文檔還提供另外兩種安裝方式：https://cloud.tencent.com/document/product/436/12266

2.根據(jù)sdk開(kāi)發(fā)

目前來(lái)看沒(méi)有碰到什么坑，可能是業(yè)務(wù)邏輯比較窄的關(guān)系，sdk這塊只用一個(gè)upload的功能，只是說(shuō)cos這邊上傳對(duì)象的時(shí)候僅支持本地文件上傳，所以后端服務(wù)器這邊要將上傳的圖片先保存在本地，確認(rèn)上傳cos成功后，將本地的資源刪除，這里可能需要一個(gè)重試機(jī)制，后面考慮加下吧

• 效果

可以說(shuō)提升明顯吧，目前只是將各頁(yè)面的大圖上傳到了cos，整體的渲染時(shí)間縮短到了1~2秒，可以說(shuō)提升很大了，后面看具體的使用情況如果還是嫌慢的話，考慮用下cdn吧