情形再現(xiàn)

下面是一張工程機械的品牌表

這個表的logo就是存儲的base64的圖片。

當(dāng)我們在對品牌列表進(jìn)行查詢的時候，因為logoBase這個字段存儲的base64格式的圖片，大小基本在5kb左右。當(dāng)我們一下子拉取1000條數(shù)據(jù)的時候，那么整個列表接口的數(shù)據(jù)量就在 5000kb的大小。這就會導(dǎo)致當(dāng)用戶需要選擇品牌的時候，這個接口的響應(yīng)速度需要4s，嚴(yán)重影響到了用戶的使用體驗。

問題分析

既然接口數(shù)據(jù)這么大，每次查詢數(shù)據(jù)庫都需要耗費時間。首先想到的就是把這些數(shù)據(jù)放置到redis緩存之中，這樣每次取緩存數(shù)據(jù)就不會這么慢了。但是，品牌列表是跟分類多對多的一種關(guān)系，存在篩選。緩存中沒法存儲這所有篩選情況的組合。

那么就只能在列表中剔除掉這個耗時的字段，然后從圖片接口中單獨取這張圖片的數(shù)據(jù)了。但是，這樣就導(dǎo)致了當(dāng)前端拿取到列表時候，需要重新循環(huán)從接口拉取圖片數(shù)據(jù)。1000條數(shù)據(jù)就會循環(huán)1000次去圖片接口中拉取數(shù)據(jù)。循環(huán)接口拿數(shù)據(jù),這是非常的耗費資源的一種情況。

于是，我想到的是，直接用接口給前端返回一個資源文件，前端可以把配置的url直接扔到圖片的src中，這就實現(xiàn)了圖片的預(yù)覽功能。

具體實現(xiàn)

• 品牌列表中，直接干掉logoBase字段。這樣接口速度就非?？炝?。
• 編寫圖片src的接口

默認(rèn)接口返回的 Content-Type為application/json; charset=utf-8，此時瀏覽器就會以json的方式解析返回的內(nèi)容。我們既然要返回png，那么Content-Type就要設(shè)置為image/png。

header('Content-type:image/png');

剩下的就是怎么將base64的內(nèi)容解析成png圖片的內(nèi)容了。

           $image = imagepng(imagecreatefromstring(base64_decode(explode(',',$ret)[1])));
            header('Content-type:image/png');
            echo $image;
            exit;

解析我們用到了php GD庫提供的一些方法。當(dāng)?shù)玫搅藞D片的str內(nèi)容時候，通過imagepng()方法將得到的內(nèi)容轉(zhuǎn)成二進(jìn)制進(jìn)行輸出。這樣就可以達(dá)到訪問一個 url返回一張可以預(yù)覽的圖片效果了。

不足之處歡迎提供寶貴意見。

到此這篇關(guān)于php數(shù)據(jù)庫中將base64圖片數(shù)據(jù)轉(zhuǎn)化可訪問src的方法詳解的文章就介紹到這了,更多相關(guān)php將base64圖片轉(zhuǎn)化src內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論