打造跨平台UI，不要再犯这些方案架构错误啦-icspec

打造跨平台UI，不要再犯这些方案架构错误啦

来源:EET 发布时间:2018-09-13

分享至微信

随着当今的设备及其各自的用户接口(UI)变得更加先进，创建和产生这些UI也变得更具挑战性，特别是为现代复杂设备建置UI通常更烧脑。无论如何，当你想要为特定的自定义嵌入式设备制作UI时，它可能是一项完全不同的挑战性任务。

我们经常看到开发人员受限于各式各样的问题，跌入常见的错误陷阱。本文将深入探讨这些问题，并揭示开发人员在开发跨平台UI时最常犯的6个与应用和解决方案架构有关的错误。

错误#1：误解内存消耗和内存利用

当开发人员将影像加载图像内存时，需要考虑的一些事项包括：需要快取的项目、加载元素的顺序，以及如何建构整体用户体验(UX)。性能问题(通常发生在较小的设备中)区分为实际和感知性能，例如，对于花费大量时间(实际性能)的操作，开发人员可以在屏幕上弹出预载的影像，让用户认为事情发生得更快(感知性能)。然而，解决这些问题需要到位的技术能力和工具。

以嵌入式Linux堆栈为例。现成可用的底层操作系统(OS)可能得花超过10秒的时间启动，而其上的普通Qt大约需要1秒钟(图1)。考虑到在这两者之上的应用本身，总启动时间总计约15秒。透过适当的技巧、工具和优化，启动应该只需要1~2秒钟。

图1 启动序列的持续时间在未优化和优化的软件堆栈之间差异很大。

在优化时，开发人员必须减少性能迟滞，并了解真正的瓶颈和时间花费所在。这需要充份地理解内存的使用方式、顺序，以及如何优化并具备相应能力。如果方案需要花费大量启动时间，显示优化尚未到位，亦说明企业不重视绩效，但我猜最终会如愿以偿，因为客户毕竟花了钱，对吗？

错误#2：在部署到目标硬件之前于PC上进行开发

这是嵌入式开发最常见的原罪。设计师和工程团队光是在PC上就花费太长时间开发嵌入式方案，然后，他们在项目周期中又太晚部署到目标硬件上。由于目标硬件通常是新的，而且在项目的早期阶段团队也还用不到，因此该问题通常会进一步恶化。

在项目实施过程中，设计缺陷、性能瓶颈、错误或问题的发现时间越晚，其修复成本就越高。将PC与嵌入式设备进行比较发现，PC几乎可以不限量地「挥霍」资源、内存和功耗，以及其他基础要素。如果项目在PC上运作良好，可能无法实现添加提升性能的特性，这会导致重新进行架构设计和重新编写大量软件的主要问题。在PC桌面上完美运作的东西到了嵌入式设备上，并不一定就能正常运作或管理，忽略了这一点会影响产品上市时间、提高拥有成本，以及工程和维护成本。

那么有灵丹妙药吗？是的，从第一天开始就在目标设备上部署。投资在使这一切成为可能的工具，以确保整个团队(包括设计师)都可以存取目标硬件，如果没有可用的目标设备，请选择接近该设备的产品，并从第一天开始部署。当今，有很多的现成参考硬件选择，可让你足够接近目标设备，如果必须只在PC上进行开发，那就在PC上开发，但要做好重新编写和延迟的心理准备。

错误#3：将完全渲染的设计压缩到嵌入式设备中

为了在屏幕上显示酷炫的三维(3D)元素，需要来自设计师的3D设计。设计师经常会创造完全渲染的影像，相当于无数的多边形("嘿！它可是在设计师的PC上运作得很好呢！")。这必须要由开发人员试图将巨大的3D对象挤进小型设备中(图2)，它要不是使一切都变得非常缓慢，不然就是要求开发人员付出额外时间，或者两弊兼具。

图2 设计师提供完全渲染的影像，导致对于开发人员来说是过于复杂的元素。

此外，在2D UI上，开发人员和设计师有时会在UI上使用过于复杂的元素。挑战是如何优化不堪(down)、斑驳(shaving)和单调(slimming)的影像、元素和多边形以适应小屏幕，同时保持相同的用户体验。在此过程中，通常都以性能和/或上市时间为代价。

错误#4：使用一种编码语言，以一盖全

客户经常用HTML5、Javascript和/或QML编写过多的应用逻辑。上述都是声明性的脚本技术，它们将使用与原生(native)C++不同的CPU资源，这通常会导致性能和维护问题。

从一开始就设计软件架构十分重要。先放上UI层，然后加上C++和更低分层(二进制执行、原生二进制执行，在这些分层上可能使用的GPU和CPU功率)。在设计软件架构时，选择正确的组件非常重要。

性能良好的Qt应用有两个主要部份：应用逻辑和大量数据以C++编写；UI和使用者互动则使用更高级语言编写，如QML。

错误#5：将更新和安全性视为特性

假设你正在研发一项项目，而且完成了大约三分之二的工作量，然后，客户希望添加无线软件更新和安全特性，这要求是错误的。更新和安全性并不是特性，它们是设计思维模式(mindset)和整体软件架构的核心部份。

客户往往会将更新和安全性视为某段时间中已在其他特性实现的东西，但其实不然。开发人员必须提前计划和思考，有什么样的安全要求？软件的哪些部份需要定期更新？怎么实施这项方案？如何验证？它需要具有从第一天就开始的思维模式。例如，如果开发人员在对UI至关重要的韧体层上编写内容，则可能无法使用可用于更新应用层和UI的相同机制更新韧体。