android中怎么優(yōu)雅的從網(wǎng)絡(luò)加載點九圖

這篇文章主要介紹了android中怎么優(yōu)雅的從網(wǎng)絡(luò)加載點九圖的相關(guān)知識，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇android中怎么優(yōu)雅的從網(wǎng)絡(luò)加載點九圖文章都會有所收獲，下面我們一起來看看吧。

1 背景

1.1 什么是點九圖

其實點九圖和我們用的其他格式的圖沒有什么大的不同，只不過是在圖片的四周各增加了1px的純黑（#FF000000）的線進(jìn)行標(biāo)記。例如：

1.2 Android是如何加載點九圖的

當(dāng)我們將點九圖放在res目錄下，Android不是直接去加載點九圖的，而是在編譯的時候?qū)⑵滢D(zhuǎn)換成另一種格式，這種格式是將其四周的黑色像素保存在Bitmap類中的mNinePatchChunk的byte[]數(shù)組中，并去掉四周一像素的寬度；在使用的時候，當(dāng)判斷mNinePatchChunk不為空且為9patchchunk，則將其構(gòu)造為NinePatchDrawable，否則構(gòu)造為BitmapDrawable，最終設(shè)置給view。所以，最后打包后的點九圖已經(jīng)不是原來帶黑線的點九圖了。

2 使用方案

2.1 遇到的坑

如果沒做任何處理，當(dāng)我們從服務(wù)端直接拉取點九的圖設(shè)置到我們的view上時，發(fā)現(xiàn)圖片并不會拉伸，并且圖片周圍的黑線也會顯示出來。從上1.2Android加載點九圖的原理可知，之所以出現(xiàn)這種問題，是因為我們少了編譯這一步，是直接拿原始的點九圖設(shè)置到view上的，所以才出現(xiàn)問題。 知道錯誤的原因后，我們可以做如下幾種方式處理：

• 讓產(chǎn)品或者設(shè)計師先進(jìn)行轉(zhuǎn)換后（轉(zhuǎn)換工具由開發(fā)提供）再上傳到服務(wù)器，這時客戶端再從服務(wù)端拉取到的就是編譯處理后的點九圖了

• 將原始點九圖上傳到一個轉(zhuǎn)換平臺，平臺進(jìn)行轉(zhuǎn)換后再上傳到服務(wù)器

• 另外一種是客戶端拿到原始的點九圖后自行處理，根據(jù)加載的原理自行構(gòu)造出NinePatchDrawable,這個過程放到客戶端渲染的時候顯然太耗時，不符合要求 我們以QQ的方案為例（第一種）來討論實現(xiàn)方案。

2.2 使用方案

先看下總的流程圖：

使用上述方案的注意事項：

• 步驟2畫黑線必須是純黑色像素，且圖片的四個角必須為透明像素點，否則Android無法識別，且在步驟3中將無法轉(zhuǎn)換

• 步驟3中，可以使用Android SDK自帶工具aapt進(jìn)行轉(zhuǎn)換：aapt c -v -S . -C .\output，其中.表示當(dāng)前目錄，.\output表示目標(biāo)目錄

• 步驟4中，上傳過程中不能對轉(zhuǎn)換后的圖進(jìn)行壓縮，因為轉(zhuǎn)換后的點九圖的黑線信息被保存到了png圖片的輔助數(shù)據(jù)快中，這部分?jǐn)?shù)據(jù)在壓縮的過程中會消失，導(dǎo)致最終客戶端拉取到的圖片不是點九圖

• 步驟4中，某些cdn因為省流量，或者其他原因，對圖片進(jìn)行壓縮或者轉(zhuǎn)碼為webp格式，這樣會導(dǎo)致最終拉取到的圖片不是點九圖。

• 步驟8中，需要通過Bitmap創(chuàng)建drawable,如果是使用res目錄下的，Android系統(tǒng)會自動完成，如果是獲取網(wǎng)絡(luò)圖片則需要自己手動創(chuàng)建，如下：

• 

• 步驟9中，一定要使用緩存，不然異步加載的過程中，在list中顯示會有問題，跳變很嚴(yán)重。

關(guān)于“android中怎么優(yōu)雅的從網(wǎng)絡(luò)加載點九圖”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“android中怎么優(yōu)雅的從網(wǎng)絡(luò)加載點九圖”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道。