MVVM设计模式进一步解耦了View和交互逻辑，因此在MVVM模式下，View对应的界面完全用工具实现，而ViewModel对应的逻辑可以直接将数据处理结果双向绑定到界面。 ，Model完全属于业务逻辑数据层面。
由于ViewModel和View的完全分离，MVVM模型中出现了很多新的工具，包括微软的WPF、Kanzi等，它们都支持MVVM。 因此，MVVM模型最大的优点就是将应用层软件三层完全解耦，中间完全工具化、模块化。
前面提到，平台化存在三个痛点。 首先是上层如何兼容不同的工具，比如Kanzi、Unity、QT。 第二个是下层如何兼容不同的Tier1、不同的Tier1平台。 第三个是如何适配不同的车型，用一套代码来支持不同的车型、不同的分辨率、不同的电子架构。
YiXing的架构重点是先分层，然后将相关的三个层完全解耦，然后在每一层实现一些标准化的模块，比如UI模块、UE交互模块、业务逻辑模块、DataParser模块。 根据多年为主机厂提供HMI软件的经验，易星将整个应用层分为五层左右。 顶层的UI完全是用工具做的，一次一个模块； 第二层是UE交互逻辑，第三层是业务逻辑像素游戏素材，第四层Parser是数据分析层，第五层是Adapter。 Adapter是专门用来适配平台的。 不同的平台使用不同的接口。 例如，有的平台使用PPS通信，有的平台使用FDBAS通信等ODI通信。 不同的通信使用不同的Adapter来适应不同的Tier1平台。 数据通过Adapter的Parser层进行解析。 解析之后，数据变得标准化。 数据。
因此，从上面的Parser层开始，所有数据和所有Tier1平台都是解耦的。 Adapter主要用于与Tier1平台的数据结构和解析进行关联。 这一层就可以实现了。 下层可以兼容不同的Tier1。 上层可以适配不同的工具，还有中间的业务逻辑层和交互逻辑层。 ，Parser层整体接口完全采用C++，并且已经标准化、模块化。
宜兴有一个基地项目。 这个Base Project可以理解为对同一个汽车厂家不同车型共享的模块进行标准化开发，所以共享的模块都是使用Base来实现的。 不同型号不同unity ui逻辑分离，不同分辨率不同，不同电子架构不同。 易星将差异化的东西添加为单独的插件，并将其集成为动态库。 最后可以提供Cmke本体编译，通过编译设置配置选项，从而根据不同的配置选项生成对应不同电子架构、不同型号、不同分辨率的可执行文件。 可执行文件将仅包含该模型、该分辨率、该电子架构及其源文件所需的最少代码。 这是目前易星在实践中找到的最佳解决方案。
亿星HMI软件平台架构和工具链解决方案顶层使用工具unity ui逻辑分离，底层兼容不同的Tier1。 中间的属性数据与所有Tier1或所有底层数据无关。 它是标准化数据。 。 例如，速度数据可能来自底层CAN信号，也可能来自FDBAS，其数据结构不同。 但当到达中间业务逻辑层时，速度数据会被赋予标准化的数据格式，使其能够到达中间层。 整个应用层从业务逻辑到交互逻辑完全标准化。 这样，当我适配不同的Tier1或者切换Tier1时，我只需要改变Adapter，然后将Tier1的数据格式转换成我自己的标准化数据格式即可。 添加模型时，我只需要动态地以库的形式集成一个差异化的模块。
这样才能真正做到一套代码兼容不同车型、不同Tier1。 同时，UI层以下的所有层都是C++接口。 这个C++接口本身与上述工具是分开的。 您在 C++ 代码层中看不到任何 Kanzi API 或 QT API。 所有工具的API都在上层，通过相应的适配器进行封装。 。 从此以后，开发所有HMI时，业务逻辑和UE逻辑都是C++，和使用的工具无关。 举个例子，如果我现在用的是Kanzi工具，以后想切换到新工具的时候游戏运营，除了这个工具界面里做的静态接口，需要用新工具重做之外，所有的底层代码不需要任何迁移。
这套解决方案可以实现汽车制造商不会被任何一种工具所束缚，后续可以根据自己的需求选择相应的工具。 这种迁移的成本非常低。
