一年撸完百万行代码，企业微信的全新鸿蒙NEXT客户端架构演进之路原创

一年撸完百万行代码，企业微信的全新鸿蒙next客户端架构演进之路一、引言本文将要分享的是企业微信的鸿蒙next客户端架构的演进过程，面对代码移植和API不稳定的挑战，提出了data list框架解决方案。通过结构化、动态和认知三重商检机制，将业务逻辑与UI解耦，实现数据驱动开发。采用MDM分层架构，业务实体层、逻辑层、UI数据层、表示层，屏蔽系统差异，确保业务代码稳定。Data list是一套基于数据驱动的分层隔离框架，整体架构图如上图所示。从数据流向的角度，Data list框架可以简单分为data list两部分。MBDM环形分层设计data list通过将业务数据到UI数据的转换逻辑独立出来，系统形成了清晰的边界层次，箭头代表依赖指向。

Cell data内不含任何业务代码，所以不受限于业务，天然可以复用。下图是组件复用统计，现有58个组件，数千次复用。比如我们开发一个极简版本的人员列表，算上注释，总计39行，一个极简版联系人列表就开发完成了。如果是一个本地静态页面，可以去掉网络请求部分，直接堆砌通用组件cell data即可。完整代码只要40行技术方案，在现有API的基础上，我们只能实现如上这个方案。直接把所有属性列出来，全部调一遍，如果data里对应属性没有赋值，就相当于用null调用了一次。实践问题这个方案有很多问题，我们迫切需要一个能动态设置属性的方案，因此我向华为官方提出了需求，如上图，向华为提需求。第二版动态属性下的数据绑定，这是官网的介绍。上图Modfire能力介绍第二版更新原理大致如上图，实践问题一，代码膨胀在实际应用这些W系列封装组件的场景可以看到，编译后的代码膨胀的非常明显，两行编译后变成了20行。

上图EES源码TS产物上图编译后体积变化从4K变成了75K。问题二，性能消耗上图节点增多，适宜节点从2个变成了5个，而鸿蒙的渲染性能优化就是要求节点越少越好。第三版基于自定义状态管理的性能优化针对这些问题分析的思路如下，控件包装的两个问题都可以用attribute update r来解决，它是attribute model air的子类。上图Attribute updatear说明杠化重点。

升级为UPDATE2之后，如果对应的data仍然是状态变量，那么我们去的时候消耗依旧。这里先解试一下为什么我们的data要加A特observer注解。第三版的改动总结如上。分两种情况讨论一下，1、修改data内部的值，这两种写法都是通过attribute updater内部的attribute对象进行更新，都是改那个更新哪个没毛病。2、增删改data对象本身。升级效果，以phototexcel为例，升级之后，代码编译后的体积明显降低了，仅为升级前的9.3%。升级前后帧率对比。简单总结一下，E第一版妥协版基于API便利属性实现基础数据绑定，虽快速启动业务开发，但存在冗于调用与性能隐患。2、第二版适配版引入attribute mod I动态属性机制，可进行属性的动态更新，却因状态管理机制本身的性能消耗和控件包装导致代码膨胀与性能劣化。3、D3板优化板创新采用自定义状态管理，剥璃包装层，直接操作原生控件，结合attribute update r实现静态代理与精准属性更新，使通用组件编译体机缩减至9.3%，复用耗时降低79%，帧率从32帧跃升至118帧。三次架构升级始终贯彻MBM分层理念，通过UI数据层的隔离，实现业务逻辑零修改，适配UI层聚变。这些最终让企业微信鸿蒙团队于2024年底完成了企业微信鸿蒙。

成next第一版100万行600加页面的开发并成功发布。