blocks|key|1640943|text|我倾向于使用仅在从移动设备访问应用程序时才包含的移动样式表。此样式表通常应用最小宽度(取决于用户和设备需求)，并将内容填充到屏幕宽度的100%25。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1640944|其他建议：|1640945|移动专用登陆页，完全由菜单和搜索框占据。|unordered-list-item|1640946|评估哪些内容对移动用户来说真正重要，并将重点放在这一点上。|1640947|没有死胡同--即使搜索结果为零，也很容易继续(新搜索，页面建议)|1640948|地理定位(如适用的话)
谷歌地图显示商店位置
附近)|1640949|如果可能的话，可以在多种设备上进行测试(即黑莓的原生浏览器倾向于
对jquery有困难)|1640950|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|T|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|U|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|V|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|W|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|P|$]]

<p>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.</p>

<p>Other suggestions:</p>

<ul>
<li>mobile-specific landing page, taken
up entirely by a menu and a search
box</li>
<li>evaluate what content is actually important to a mobile user and focus on that</li>
<li>No dead ends - even if a search returns zero results, make it easy to continue on (new search, page suggestions)</li>
<li>geolocation if applicable (ie a<br>
google map showing store locations<br>
nearby)</li>
<li>test on a variety of devices if possible (ie
blackberry's native browser tends<br>
to have difficulty with jquery)</li>
</ul>


blocks|key|443487|text|我同意约翰尼的观点，使用移动样式表。例如：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|443488|<link+rel="stylesheet"+href="screen.css"+media="screen"/>
<link+rel="stylesheet"+href="handheld.css"+media="handheld"/>|code-block|syntax|javascript|443489|但是，无论您在页面底部做什么，都允许用户在两者之间进行交换。例如，许多“移动”站点在底部都有一个链接来查看“完整”站点。这样，用户就可以对设备的功能做出明智的决定。|443490|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

<p>I agree with Johnny, use a mobile stylesheet.  For example:</p>

<pre><code>&lt;link rel="stylesheet" href="screen.css" media="screen"/&gt;
&lt;link rel="stylesheet" href="handheld.css" media="handheld"/&gt;
</code></pre>

<p>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.</p>


blocks|key|1996140|text|到目前为止我发现的唯一一件事是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1996141|开发到最低的SDK版本，您可以。我的目标是2.2，但只使用了1.6版的API，而且到目前为止(触摸木头)效果很好。你仍然可以支持的事情，如备份和移动应用到SD卡，感谢这些是由报表驱动。|ordered-list-item|1996142|对于非常小的屏幕，您可能需要一个单独的布局。使用仿真器，我发现，仅仅缩小图形的大小并不能使布局可用--您需要重新排列和删除一些元素。|1996143|有时，你需要一个单独的布局的肖像与景观模式-但通常肖像工作良好的景观。|1996144|这将是有趣的，看看其他人有什么要说-特别是围绕着提供多个可提取的资源，为不同的密度。我一直无法分离为什么有时需要使用-hdpi，有时不能在hdpi屏幕上获得好的结果。|1996145|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|O|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|P|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|L|$]]

<p>The only things I've found so far:</p>

<ol>
<li>Develop to the lowest SDK version you can.  I target 2.2, but only use APIs from 1.6 and so far (touch wood) that's worked out well.  You can still support things like backup and move app to SD card thanks to these being driven by the Manifest.</li>
<li>For really small screens you will probably need a separate layout.  Using the emulator I've found that just reducing the size of the graphics doesn't make the layout usable - you need to re-arrange and strip out some elements.</li>
<li>Sometimes you need a separate layout for portrait versus landscape mode - but often the portrait works fine in landscape.</li>
</ol>

<p>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.</p>


blocks|key|443568|text|用于布局|type|unstyled|depth|inlineStyleRanges|entityRanges|data|443569|首先，您应该从阅读正式的支持多屏幕最佳实践开始。有很多好的提示，以及一个关于你需要寻找的兼容性的总体想法。|offset|length|443570|我发现一件非常有用的事情，这似乎很明显，就是在各种大小的模拟器中测试您的布局。当扩展到1024x768+(即使没有设备会有这样的res)时，您的布局看起来如何？当它是非常小和方形的时候怎么样？查看您的布局扩展/契约将帮助您调整它，以更好地适应所有屏幕。|443571|layout_weight|style|CODE|443572|在布局方面，android:layout_weight是一个功能强大但文档不足的属性。使用它，您可以创建布局，其中组件之间的百分比大小。|443573|例如：|443574|<LinearLayout+android:orientation="horizontal"
++++android:layout_width="fill_parent"
++++android:layout_height="fill_parent">

++++<EditText+android:layout_weight="80"+
++++++++android:layout_width="wrap_content"
++++++++android:layout_height="wrap_content"+/>
++++<Button+android:layout_weight="20"
++++++++android:text="Button"
++++++++android:layout_width="wrap_content"
++++++++android:layout_height="wrap_content+/>
</LinearLayout>|code-block|syntax|javascript|443575|在此布局中，<EditText/>将占用可用宽度的80%25，而<Button/>将占用可用宽度的20%25。显然，这应该谨慎使用，以便所有的项目仍然可以使用，即使它们是小的。|443576|<include+/>|443577|另一个有用的布局实践是将布局的公共部分打包到单独的文件中，并使用<include+layout="@layout/smaller_section"+/>将它们包括在内。这样，您就可以在布局的其他部分(例如，对于景观)进行洗牌，而不必保留布局的整个并行版本。|443578|entityMap|0|LINK|mutability|MUTABLE|url|http://developer.android.com/intl/de/guide/practices/screens_support.html#screen-independence^0|0|C|9|0|0|0|0|D|0|6|L|0|0|0|6|B|U|9|0|0|B|0|W|18|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@$D|1A|E|1B|1|1C]]|A|$]]|$1|F|3|G|5|6|7|1D|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1E|8|@$D|1F|E|1G|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1H|8|@$D|1I|E|1J|J|K]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1K|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1L|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|1M|8|@$D|1N|E|1O|J|K]|$D|1P|E|1Q|J|K]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1R|8|@$D|1S|E|1T|J|K]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1U|8|@$D|1V|E|1W|J|K]]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|11|$12|$5|13|14|15|A|$16|17]]]]

<h1>For Layouts</h1>

<p>First, you should start off by reading the official <a href="http://developer.android.com/intl/de/guide/practices/screens_support.html#screen-independence" rel="nofollow noreferrer">Supporting Multiple Screens Best Practices</a>. 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.</p>

<p>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.</p>

<h2><code>layout_weight</code></h2>

<p>In layouts, <code>android:layout_weight</code> is a powerful, but under-documented attribute. Using it, you can create layouts where components are sized in percentages to each other. </p>

<p>For example:</p>

<pre><code>&lt;LinearLayout android:orientation="horizontal"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"&gt;

    &lt;EditText android:layout_weight="80" 
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" /&gt;
    &lt;Button android:layout_weight="20"
        android:text="Button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content /&gt;
&lt;/LinearLayout&gt;
</code></pre>

<p>In this layout, the <code>&lt;EditText/&gt;</code> will take up 80% of the available width, while the <code>&lt;Button/&gt;</code> 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. </p>

<h2><code>&lt;include /&gt;</code></h2>

<p>Another helpful layout practice is to bundle up common bits of your layout into separate files and include them using <code>&lt;include layout="@layout/smaller_section" /&gt;</code>. That way, you can shuffle around other parts of the layout (say, for landscape), without having to keep entire parallel versions of the layout.</p>


<p>As you know android today is many versions many  constructors, many screen sizes,...</p>

<p>it's quite difficult for developers today to write programs that targets a big part of devices.</p>

<p>What would be THE developer must-know practices for this ?</p>

<ul>
<li>tips for fluid layouts.</li>
<li>"standards" for developing on any android version.</li>
<li>...</li>
</ul>

<p>Any other ideas ?</p>


Best practices for targetting a wide range of devices and screen sizes

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

正如你所知道的，android现在有很多版本--许多构造函数，许多屏幕大小，.对于今天的开发人员来说，编写针对大部分设备的程序是相当困难的。开发人员必须知道的方法是什么？流体布局提示。任何android版本开发的“标准”。..。还有其他想法吗？

问获取多种设备和屏幕大小的最佳实践
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问获取多种设备和屏幕大小的最佳实践EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问获取多种设备和屏幕大小的最佳实践
EN