2011-02-15 120 views
10

我已經通過this post(及其他),以及通過documentation關於Android的支持不同的屏幕分辨率,但我無法找到一個明確的答案,一個(簡單)的問題:安卓:繪製分辨率

在Android應用程序中使用「res/drawable」圖像可以嗎?

背景:在這個特定的應用程序中唯一需要的圖像是應用程序圖標本身和通知圖標,在任何佈局中都不會有任何圖像。
因此,根據我的理解,如果找不到「hdpi」 - ,「mdpi」 - 和「ldpi」 - 文件夾,Android將使用「res/drawable」作爲後備。
由於不同屏幕分辨率的唯一缺陷似乎是Android會根據特定分辨率縮放圖像,如果沒有找到特定分辨率的圖像,這隻會在UPScaling時出現問題,因爲圖像會變得模糊。但是如果我在「res/drawable」(而不是3個不同的)中提供所有「hdpi」-images,那麼如果尺寸太大,Android是不是隻會DOWNscale這些圖像?
如果這是真的,我可以通過三分之一的圖像節省一些APK空間。

後續問題:我讀到了API級別3,需要名爲「drawable-v3」的dir。這是真的還是「可繪製的」這個API級別的回退?

任何提示表示讚賞。

回答

7

在繪圖資源文件夾中的圖像被認爲是在MDPI分辨率,因此他們將得到放大/縮小如果你不提供其他人。

放大的圖像將是低分辨率,看起來模糊。按比例縮小的圖像會丟失像素,並且看起來很光滑。

因此,您的應用程序只能使用一組默認圖像「工作」,但在許多設備上看起來會很糟糕。我強烈建議您創建不同大小的圖像,因此在所有設備上看起來都很棒 - 這有點無聊,但不難做到。

在我們擁有xhdpi設備之前不久,所以當你在它的時候,你可能也想創建它們。

我假設你讀過this

2

不是一個完整的答案,但:高度縮小的圖像通常看起來和放大圖像一樣差(但採用不同的方式),因爲圖形庫幾乎完全使用插值方法進行調整大小,而插值方法受限於在嚴重信息丟失之前它們可以縮小圖像的程度(對於線性方法約爲50%,對於雙三次方法約爲25%)。這就是爲什麼大多數平臺已經發展出可以讓您嵌入最適合每種屏幕尺寸的圖像的慣例(如hdpi,mdpi等)。

+0

這隻會影響應用程序圖標本身,其中hdpi 72x72和ldpi是36x36,當縮小時不應該這麼差,對吧? – Select0r 2011-02-15 22:13:37

+0

不,它可能看起來很糟糕。應該使用Photoshop等複雜的圖形引擎來縮小尺寸 - 他們的算法會比編程環境的圖形引擎(它針對性能而不是最終結果質量進行了優化)產生更好的結果 – MusiGenesis 2011-02-15 22:27:45

+0

我有我的所有圖像n三種尺寸,用一個圖形程序完成,我只是渴望在最終的APK大小中安全的這幾個kB :) – Select0r 2011-02-15 22:31:41

0

RES /可繪是回退

的告誡是縮放不僅降低了圖像,但需要的處理時間太。

我還沒有讀API級別3文檔但是,遺憾的1/2答案

2

我用繪製/所有的時間,然後我去百思買和所有的本地無線商店和測試的小/大/巨(平板電腦)設備我的應用程序和他們看起來很好。

2

除非您有理由針對pre-Donut設備(現在只有4%的設備符合http://developer.android.com/resources/dashboard/platform-versions.html),否則您應該將您的位圖放入其中一個-Xdpi目錄中。由於兼容性的原因,通用的「drawable」目錄是「drawable-mdpi」的同義詞,但是現代編寫良好的應用程序應該將其drawable放入與其設計密度相匹配的目錄中。

-2

對於什麼是值得我發現Android的圖像處理是乏味和不可靠的。爲不同屏幕包含不同大小圖像的概念將導致大型應用程序文件與圖像臃腫。已經有不符合標準分辨率範圍的屏幕。我發現最好不要讓android處理縮放,它會爲您定位的最小屏幕創建一個基本圖像,然後將其縮放,從而在大屏幕上顯示普通圖像。即使您專門爲大屏幕製作圖像,也會發生這種情況。 我的解決方案似乎適用於從2「三星手機到索尼平板電腦的所有內容,都是以高分辨率創建圖像,並使用Bitmap.createScaledBitmap()來獲得所需的尺寸。 Android和有很多東西需要學習