这里是我的看法,与Igor的回答有些重叠:
原生控件外观 - UI控件今天具有相当复杂的外观。我们从中直觉地得出许多视觉线索,即使它只是一个带有一些框架的白色矩形,在错误的阴影下看起来很奇怪。上下文菜单通常不仅仅是打开,而是从某个方向滑入或淡入。
原生控件行为 - 比UI更复杂,行为细节很多:根据单击位置不同的上下文菜单,选择或拖动项目时不同的“热区”,键盘快捷键等等。
注重细节 - 在任何平台上都有很多一致的UI行为可以发现。例如,箭头键在树形控件中的工作方式与选择、打开和关闭节点有关。
只需看看Windows:大多数非本机工具包都会在基本键盘导航上出错-箭头键,Home,End,PgUp和PgDown,使用Ctrl修改行为,使用Shift扩展选择可提供32种行为。复制和粘贴传统上是使用Ctrl + C / Ctrl + X / Ctrl + V和Shift + INS,Shift + DEL,缺少一些功能。鼠标双击通常选择一个单词,鼠标三击有时选择一个句子、行或段落。
响应时间和肌肉记忆 - 基本上有两种UI操作模式:
“行动-外观循环”,在这种模式下,您需要等待响应才能决定下一步操作,
“从肌肉记忆中播放”,这种模式速度更快,需要的精神处理资源更少。但是,这需要满足两个要求:响应必须是统一的和“即时的”,下一个操作必须立即正确地注册(至少在10毫秒内)。
然而,对于非本机工具包来说,这通常变得困难,因为响应滞后于一两个操作之后(思维锁定在差异上),并且工具包需要50毫秒或更长时间才能显示菜单,在此期间,单击不会按预期注册。
打磨UI需要很长时间 - 一个好的控件库可以解决大部分控件问题,但还有一些最后的10%需要90%的时间,并且您需要控制交互。您必须尝试不同的方法,您必须期望具有FPS训练过的反应,您必须尝试各种工作流程。
跨平台工具包无法完美地做到这一点 - 它们陷入了进退两难的境地:它们可以选择独立于平台的内部一致性,或者与当前运行的平台保持一致。要做到正确,后者通常需要在调用代码中使用特定于平台的代码,这正是您要避免的实际事情。