针对各种设备和屏幕尺寸的最佳实践
如您所知,今天的 Android 有很多版本、很多构造函数、很多屏幕尺寸……
对于今天的开发人员来说,编写针对大部分设备的程序非常困难。
开发人员必须了解的做法是什么?
- 流畅布局的技巧。
- 在任何 Android 版本上进行开发的“标准”。
- ...
还有其他想法吗?
As you know android today is many versions many constructors, many screen sizes,...
it's quite difficult for developers today to write programs that targets a big part of devices.
What would be THE developer must-know practices for this ?
- tips for fluid layouts.
- "standards" for developing on any android version.
- ...
Any other ideas ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
对于布局
首先,您应该首先阅读官方 支持多屏幕最佳实践。那里有很多很好的提示,以及关于您需要在兼容性方面寻找什么的一般想法。
我发现一件事非常有帮助,这似乎很明显,那就是在各种大小的模拟器中实际测试您的布局。当扩展到 1024x768 时,您的布局看起来如何(即使没有设备具有这样的分辨率)?如果它超级小而且是方形的呢?查看布局如何拉伸/收缩将帮助您调整它以更好地适应所有屏幕。
layout_weight
在布局中,
android:layout_weight
是一个功能强大但记录不足的属性。使用它,您可以创建布局,其中组件的大小按彼此的百分比进行调整。例如:
在此布局中,
将占用可用宽度的 80%,而另一个有用的布局实践是将布局的常见部分捆绑到单独的文件中,并使用
包含它们
。这样,您就可以在布局的其他部分(例如,横向)进行洗牌,而不必保留布局的整个并行版本。For Layouts
First, you should start off by reading the official Supporting Multiple Screens Best Practices. There are a lot of good tips there, as well as a general idea on what you need to be looking for in terms of compatibility.
One thing I've found to be very helpful, which seems quite obvious, is to actually test your layout in various sized emulators. How does your layout look when expanded to 1024x768 (even though no device will have such a res)? How about when it's super tiny and square? Seeing how your layout stretches/contracts will help you tweak it to better fit all screens.
layout_weight
In layouts,
android:layout_weight
is a powerful, but under-documented attribute. Using it, you can create layouts where components are sized in percentages to each other.For example:
In this layout, the
<EditText/>
will take up 80% of the available width, while the<Button/>
will take up 20% of the available width. Obviously, this should be used carefully so that all items can still be usable even if they are small.<include />
Another helpful layout practice is to bundle up common bits of your layout into separate files and include them using
<include layout="@layout/smaller_section" />
. That way, you can shuffle around other parts of the layout (say, for landscape), without having to keep entire parallel versions of the layout.到目前为止我唯一发现的是:
看看其他人怎么说会很有趣 - 特别是在为不同密度提供多个可绘制资源方面。我无法找出为什么有时需要使用 -hdpi 而有时却不能在 hdpi 屏幕上获得良好的结果。
The only things I've found so far:
It'll be interesting to see what other have to say - particularly around providing multiple drawable resources for different densities. I've not been able to isolate why it's sometimes required to use -hdpi and sometimes not to get good results on a hdpi screen.
我倾向于使用仅在从移动设备访问应用程序时才包含的移动样式表。此样式表通常应用最小宽度(取决于用户和设备要求),并将内容填充到屏幕宽度的 100%。
其他建议:
完全通过菜单和搜索完成
框
谷歌地图显示商店位置
附近)
黑莓原生浏览器趋于
jquery 有困难)
I tend to use a mobile stylesheet that is only included when the app is accessed from a mobile device. This stylesheet generally applies a min-width (depending on user and device requirements), and fills the content up to 100% of the screen width.
Other suggestions:
up entirely by a menu and a search
box
google map showing store locations
nearby)
blackberry's native browser tends
to have difficulty with jquery)
我同意约翰尼的观点,使用移动样式表。例如:
但是,无论您在页面底部做什么,都允许用户在两者之间进行交换。例如,许多“移动”网站在底部包含一个用于查看“完整”网站的链接。通过这种方式,用户可以对其设备的功能做出有意识的决定。
I agree with Johnny, use a mobile stylesheet. For example:
However whatever you do at the bottom of the page allow the user to interchange between the two. For example many 'mobile' sites include a link at the bottom to view the 'full' site. This way the user makes the concious decision over the capabilities of their device.