应用骨架支持多屏 [英] Application Skeleton to support multiple screens
问题描述
众所周知,Android 带有各种不同的设备功能、分辨率和屏幕尺寸,以便在开发支持多个(小和大)屏幕存在大小和布局的障碍.
这会导致屏幕尺寸、分辨率和 DPI 的不同组合,并在为 Android 设备设计和开发时带来相当大的挑战.虽然其他一些制造商(非 Android)具有不同的分辨率和 DPI,但它们共享相同的屏幕尺寸并且分辨率遵循相同的纵横比.因此,可以创建适合非 Android 设备的图像.
我的问题是是否有一个合适的流程或架构可以满足要求?
请记住,我们确实有不同尺寸和分辨率的平板电脑.
我知道 或BetterNinePatch
现在只需根据 Android 的标准重命名您的图像并使用 hdpi
完成您的应用程序,然后只需获取 drawable-hdpi
文件夹并打开 Adode Photoshop(推荐)创建多个尺寸的Action(只需根据百分比)一旦为所有尺寸创建操作,然后只需执行批量自动化 并给出源(drawable-hdpi)和目标(drawable-ldpi、drawable-mdpi、drawable-xdpi).
我坚持您使用 Photoshop 的原因是它会使用 Actions 自动调整您的图像大小,另外一个优点是您无需重命名文件(它会分配与原始文件相同的名称).
完成所有图像的创建后,刷新项目并进行测试.
有时支持屏幕(xhdpi,hdpi,mdpi)的布局可能会在小屏幕(ldpi)中被剪切,因此为了处理这个问题,只需为它创建单独的布局文件夹(layout-small)并添加<代码>滚动视图代码>(大部分).就是这样.
平板电脑平板电脑分为两种尺寸.
- 7"(1024X(600-48(navigation bar))) = 1024X552 (drawable-large)
- 10"(1280X(800-48(导航栏))) = 1280X752 (drawable-xlarge)
在这里我们需要为两个屏幕创建图像并相应地放置它们
总而言之,我们将在我们的应用程序中使用这个文件夹来支持多屏幕.
drawabledrawable-ldpidrawable-mdpidrawable-hdpidrawable-xhdpi可绘制大drawable-xlarge
与屏幕尺寸和屏幕密度
drawable-large-ldpidrawable-大-mdpidrawable-大-hdpidrawable-大-xhdpi
更多限定符,屏幕密度和版本
drawable-ldpi-v11drawable-mdpi-v11drawable-hdpi-v11drawable-xhdpi-v11
和更多带有屏幕尺寸和版本
drawable-large-v11drawable-xlarge-v11
和更多带有最小宽度概念(SW)
drawable-sw???dp
进一步在 Android V3.0 Honeycomb 中,他们引入了 SW(smallest width)
的新概念,其中设备按屏幕宽度分类,因此如果我们创建一个名为 drawable 的文件夹-sw360dp
那么720dp(宽度或高度)的设备将使用此文件夹中的资源.
例如找到Samsung Galaxy S3
dp 后缀为drawable-sw?dp
参考 DP 计算,如果您想要支持你的布局或可绘制到 S3 然后计算说
px= 设备的宽度 = 720
dpi= 设备的密度 = 320
给定的公式
px = dp * (dpi/160)
交换公式,因为我们有 px 的值
dp = px/(dpi/160)
现在投入价值,
dp= 720/(320/160);dp=360.
所以 drawable-sw360dp
将完成这项工作
从 GsmArena 获取设备配置同样,您还可以根据设备的 Android API 版本创建文件夹,即 drawable-hdpi-v11`,因此具有 API11 且为 Hdpi 的设备将使用此资源.
其他提示:
使用相对布局,dp、sp 和 mm
dp 单位 - 在 160 ppi 屏幕(即中等密度)上标准化为 1 个物理像素的设备独立像素.在运行时缩放.用于屏幕元素尺寸
sp 单位 - 缩放像素,指定为浮点值,基于 dp 单位,但根据用户的字体大小首选项设置进行了额外缩放.在运行时缩放.用于字体大小
你应该总是使用RelativeLayout进行布局;AbsoluteLayout 已弃用,不应使用.
使用适当的图像格式 - PNG 与 JPEG
对于位图图像文件,Android更喜欢"PNG,接受"JPEG,不鼓励"GIF.
然而,PNG 和 JPEG 不是等价的.它们有不同的质量权衡,PNG 并不总是最好的:
JPEG 与 PNG 相比,文件大小最多可减少 50%,这对于图像密集型应用来说意义重大
对于相同的文件大小,更高质量的有损"JPEG 可能比高度压缩的无损"PNG 看起来更好
为图像和图形添加标签以进行调试
使用支持屏幕元素
使用真实设备值配置您的模拟器
传统上,桌面系统以 72ppi (Mac) 或 96ppi(Windows、Linux)显示.与移动设备相比,桌面显示器始终是低密度的.
始终将您的 Android 模拟器配置为模拟真实设备值,并始终将它们设置为缩放以模拟设备密度.
在 Eclipse 中,很容易创建多个模拟器(从 Eclipse 菜单栏,选择窗口 > AVD 管理器 > 新建),配置为真实设备的值:
为其模拟的真实设备命名模拟器指定分辨率,不要使用内置通用尺寸设置设备密度以匹配真实设备(在硬件窗格中将抽象 LCD 属性设置为真实密度,始终为整数值)
当您启动设备时,始终选择将显示缩放到实际大小,并以英寸为单位输入实际屏幕尺寸.
如果不设置设备密度,模拟器默认为低密度,并且总是加载ldpi特定的资源.分辨率(像素尺寸)将是正确的,但与密度相关的图像资源不会按预期显示.
当然,您所做的任何事情都不会在较低密度的桌面显示器上再现较高密度的图像质量.
以下是截至 2012 年 10 月 1 日的 7 天期间收集的数据.要查看有关 Android 平台版本的最新统计数据,转到这里
基于屏幕尺寸
基于屏幕密度
As we know Android coming with various device which having different Features, Resolution, and Screen-size so while developing an Application which support multiple (small and big) screen there is an obstacle of size and layout.
This leads to different combinations of screen sizes, resolutions, and DPIs and creates quite a challenge when designing and developing for Android devices. While some other Manufacturer (non Android) have different resolutions and DPI, they share the same screen size and the resolutions follow the same aspect ratio. Therefore, an image can be created to fit the non Android devices.
My question is that is there a proper flow or architecture that one should follow to meet the requirement?
Remember we do have Tablets of different Size and Resolution.
I'm aware that Android Developer contains this information but my view is from implementation.
From my knowledge what I understood is that for designing Android graphics even Programmer must know the designing concept.
Finally created a structure which handle layouts and icon for multiple screen.
Android generalises device displays into categories based on two parameters:
- Screen size, the physical size of the display (measured diagonally)
- Screen density, the physical pixel density of the display (in pixels-per-inch, or ppi)`
To determine screen size & density quickly, please install "What's my Size" app for Android.
Screen size
Android defines four generalised screen sizes:
Qualifier Size
small ~3 inches (approx)
normal ~4 inches (approx)
large Exceeds 4 inches
xlarge Exceeds 7 inches
- Most phones are classified as small or normal (roughly 3 to 4 inches diagonally). But now, there are many phones with large screen such as Galaxy S4, HTC One, Xperia Z
- A small tablet like the Samsung Galaxy Tab is classified as large (larger than 4 inches)
- Extra-large applies to large devices, for example large tablets
Android defines four generalised screen densities:
Qualifier Description Nominal value
ldpi low density 120 ppi
mdpi medium density 160 ppi
hdpi high density 240 ppi
xhdpi extra high density 320 ppi
Typically:
- screen size has most impact on your app layouts
- screen density has most impact on your image and graphic resources
It is listed here the percentage difference of device screen
- Ldpi- 75%
- Mdpi- 100% (base according to Android developer site)
- Hdpi- 150%
- XHdpi- 200%
But as we know now most of device coming with 480X800 so I'm consider this as based device, so our new calculation will like this
- Ldpi- 50%
- Mdpi- 66.67%
- Hdpi- 100%
- XHdpi- 133.33%
which means that first icon and design will be created for 480X800 only and then for rest ones(i.e. Ldpi, Mdpi, Xhdpi).
There are images which are common for all layout and must uniform in color and shape(no complex shape, no curve) so for this kind of image we are creating 9patch
which to be put in "drawable(no-suffix)" folder. To create 9Patch image you can either use DrawNinePatch or BetterNinePatch
Now just rename your images based on Android's standards and complete your application with hdpi
and then just take drawable-hdpi
folder and Open Adode Photoshop(recommended)
create Action of multiple size(just change the size according to percentage ratio) once Action created for all size then just do Batch Automate and give source(drawable-hdpi) and destination(drawable-ldpi, drawable-mdpi, drawable-xdpi).
The reason I insist you to use Photoshop because it will resize automatically your image with Actions and one more plus point is that you need not to rename the file(it will assign same name as original one).
once you completed with creation of all images, refresh your project and test it.
Sometimes there may be possibility that the layout which support screen(xhdpi, hdpi, mdpi) may be get cut in small screen(ldpi) so for handling this just create separate Layout folder(layout-small) for it and add ScrollView
(mostly). Thats it.
Tablet Tablets are categorized into two size.
- 7"(1024X(600-48(navigation bar))) = 1024X552 (drawable-large)
- 10"(1280X(800-48(navigation bar))) = 1280X752 (drawable-xlarge)
In this we need to create image for both the screen and just put them accordingly
So all in all we will have this folder in our application to support multiple screen.
drawable
drawable-ldpi
drawable-mdpi
drawable-hdpi
drawable-xhdpi
drawable-large
drawable-xlarge
will be more qualifier combination with Screen size and Screen density
drawable-large-ldpi
drawable-large-mdpi
drawable-large-hdpi
drawable-large-xhdpi
more qualifier with Screen density and Version
drawable-ldpi-v11
drawable-mdpi-v11
drawable-hdpi-v11
drawable-xhdpi-v11
and more qualifier with Screen size and Version
drawable-large-v11
drawable-xlarge-v11
and more qualifier with Smallest width concept(SW)
drawable-sw???dp
Further more in Android V3.0 Honeycomb they introduced new concept of SW(smallest width)
in which device are categorized into screen width, so if we are creating a folder named drawable-sw360dp
then the device with 720dp(either width or height) will use resource from the this folder.
for example to find the Samsung Galaxy S3
dp to suffix to drawable-sw?dp
With reference of DP Calculation, If you want to support your layout or drawable to S3 then the calculation says
px= Device's width = 720
dpi= Device's density= 320
formula given
px = dp * (dpi / 160)
interchanging formula because we have px's value
dp = px / (dpi / 160)
now putting value,
dp= 720 / (320/160);
dp=360.
so drawable-sw360dp
will do the job
Get you Device configuaration from GsmArena Sameway you can also create folder according to Device's Android API version i.e. drawable-hdpi-v11` so the device which is having API11 and it is Hdpi then it will use this resources.
Additional Tips:
Use relative layouts, dp, sp, and mm
dp units - device independent pixels normalised to 1 physical pixel on a 160 ppi screen i.e. medium density. Scaled at runtime. Use for screen element dimensions
sp units - scaled pixels, specified as floating point values, based on dp units but additionally scaled for the user's font-size preference setting. Scaled at runtime. Use for font sizes
you should always use RelativeLayout for layouts; AbsoluteLayout is deprecated and should not be used.
Use appropriate image formats - PNG versus JPEG
Android "prefers" PNG for bitmap image files, "accepts" JPEG, and "discourages" GIF.
However, PNG and JPEG are not equivalents. They have different quality trade offs, and PNG is not always best:
JPEG can offer up to 50% file-size reductions over PNG, which is significant if your app is image-intensive
A higher quality "lossy" JPEG may look better than a highly compressed "lossless" PNG, for the same file size
Add labels to your images and graphics for debugging
Use the supports-screens element
Configure your emulators with real device values
Conventionally, desktop systems display at 72ppi (Mac), or 96ppi (Windows, Linux). Compared with mobile, desktop displays are always low density.
Always configure your Android emulators to mimic real device values, and always set them to scale to emulate device density.
In Eclipse, it's easy to create multiple emulators (from the Eclipse menu bar, select Window > AVD Manager > New) configured with values for real devices:
Name the emulator for the real device it's emulating Specify Resolution, don't use Built-in generic sizes Set the device density to match the real device (in the Hardware pane set Abstracted LCD Property to the real density, always an integer value)
When you launch the device, always select Scale display to real size, and type in the real screen dimension in inches.
If you don't set the device density, the emulator defaults to low density, and always loads ldpi-specific resources. Resolution (pixel dimensions) will be correct, but your density-dependent image resources will not display as intended.
Of course, nothing you do will reproduce higher density image quality on a lower density desktop display.
Here is the Data collected during a 7-day period ending on October 1, 2012. To see the latest statistic about Android platform version, go to here
Based on Screen Size
Based on Screen Density
这篇关于应用骨架支持多屏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!