场景：您需要在不同的屏幕上展示相同的应用程序 - 假设标准 15''-17'' 便携式 10'' 和移动 4''，可能在不同的分辨率下工作。
问题：您是否尝试采用根据可用空间重新排列的流动布局，或者您是否滚动 N（每个范围一个）单独的 UI 层，针对每个特定支持的分辨率/屏幕尺寸进行优化。
这类问题的行业标准是什么？
提出非常巧妙的布局是否有意义，将屏幕划分为优先区域，当屏幕以一种或另一种方式调整大小时会消失/返回？
我们都知道 iPhone 应用程序（或任何其他掌上设备）不可能与桌面版本完全不同，所以我假设在这种情况下（4 英寸或更少）你被迫滚动不同的 UI，但是否有中间地面（假设在 13'' - 7'' 屏幕之间，后者需要手指作为主要输入）在哪里进行液体布局有意义？
您似乎已经决定移动设备需要单独的 UI，我支持这一点。用户与这些设备交互的方式如此不同，以至于您需要以特定的方式来考虑它们。
对于其他屏幕尺寸，我认为需要从用户的角度来处理它们。如果用户以不同的方式与屏幕交互，那么您需要单独的界面。然而，根据我的经验，用户倾向于将大约 10 英寸以上的屏幕视为同一事物的更大或更小的版本，因此您应该以相同的方式对待您的 UI。不要为较小的屏幕大幅更改它。相反，您需要找到一种方法来扩大或缩小它，使用户觉得他们有更多的工作空间。使用相同的旧 UI。
文本编辑器就是一个很好的例子。文档窗口变大了，有更多的空间来编辑文档，但实际界面保持不变。
移动应用程序（用于手机和其他便携式设备）通常会获得手卷移动 UI。
您所说的 10" - 13" 机箱更多地属于上网本范围。在这种情况下，设备 UI 与（在大多数情况下）常规桌面 UI 相似，因此我将采用流动布局并使用相同的 UI。
编辑
有关要求的说明，请参阅评论...
但是考虑到较小的界面将成为触摸界面，而较大的界面不会……我建议为每个界面滚动不同的 UI。如果对基于触摸的问题进行特殊考虑，触摸版本的用户体验会好得多。
我们刚刚开始一个项目，我们遇到了一个非常相似的问题。
在我们的例子中，应用程序在不同屏幕上的工作方式会略有不同，例如，在较小的屏幕上会有更多的阶段和更少的选项。
我们打算做的是使用 ASP.Net MVC 框架，为每个屏幕分辨率/子应用实现一个视图。我们将尽量保持应用程序的其余部分对所有屏幕分辨率通用。
在 Web 应用程序的上下文中，Jakob Nielsen 建议（基于他对最近可用性测试的评估，阅读链接文章了解详细信息）为移动设备设计专用 UI。我认为即使您的应用程序不是基于 Web 的，他的一些指导原则还是有用的。
他也有桌面分辨率的指导方针。