MVVM模式特点：
MVVM设计模式进一步解耦了View和交互逻辑，所以在MVVM模式下，View对应的接口完全用工具实现，而ViewModel对应的逻辑可以直接将数据处理的结果与接口双向绑定，Model完全属于业务逻辑数据层面。
由于ViewModel和View的完全分离，MVVM模式下出现了很多新的工具unity ui逻辑分离，包括微软的WPF，Kanzi等都会支持MVVM。 因此，MVVM模型最大的优势在于，将应用层软件三层完全解耦，中间的工具化完全工具化、模块化。
如前所述，平台化存在三个痛点。 首先是上层如何兼容不同的工具游戏图片素材，比如Kanzi、Unity、QT。 二是下层如何兼容不同的Tier1和不同的Tier1平台。 三是中间如何适配不同的机型，用一套代码来支持不同的机型，不同的分辨率，不同的电子架构。
宜兴建筑的重点是首先进行分层。 分层后，三个相关层完全解耦，然后在每一层实现一些标准化的模块，如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实现的。 不同机型有差异，不同分辨率有差异，不同电子架构有差异。 艺兴将差异化的东西作为单独的插件加入，并作为动态库进行整合。 最后可以用cmke body编译，通过编译设置配置选项3D角色，实现根据不同的配置选项生成不同电子架构、不同型号、不同分辨率对应的可执行文件。 可执行文件将仅包含此车型、此分辨率、此电子架构及其源文件所需的最少代码。 这是目前艺兴在实践中找到的最佳方案。
宜星人机界面软件平台架构及工具链解决方案的顶层是工具，底层兼容不同的Tier1。 中间部分的属性数据与所有Tier1或所有底层数据无关。 它是标准化数据。 . 比如速度数据，速度可能来自底层的CAN信号，也可能来自FDBAS，它的数据结构不同，但是到了中间的业务逻辑层，会给速度数据一个标准化的数据格式，所以可以做到中间层的业务逻辑到整个应用层的交互逻辑是完全标准化的。 这样我在适配不同的Tier1或者切换Tier1的时候，只需要再换一次Adapter，然后把Tier1的数据格式转换成自己标准化的数据格式unity ui逻辑分离，添加模型的时候只需要使用动态A差异化模块以库的形式集成。
这样，一套代码就可以兼容不同的机型，不同的Tier1，而且因为UI层以下都是C++接口。 C++ 接口本身与上述工具是分开的。 在C++代码层，没有Kanzi API、QT API，所有工具的API都在上层，通过相应的适配器进行封装。 . 这样，在开发所有HMI时，业务逻辑和UE逻辑都是C++的，与使用的工具无关。 比如我现在用看子工具的时候，以后想换新工具的时候，除了这个工具界面里面做的静态界面需要用新工具重做之外，所有的底层代码都不需要被迁移。
这套方案可以实现车厂不受任何工具的束缚，可以根据自己的需求选择相应的工具。 这种迁移的成本非常低。
