combobox 怎么实现对listview的类别查询_我们该如何实现一个 Excel

在国内，大部分软件从业者都是在从事应用水平的工作。世界分工就是这样，中国大部分企业处于劳动制造业阶段。

就如现在的世界商业布局一样，英美日是核心技术研发梯队，台湾是管理梯队，而中印越南是制造梯队。中国大部分企业管理上不去，核心技术也拿不到手，只能处于低端产业链，也是无可奈何的现实。再加上国际形势恶化，连制造业也要守不住了。

很不乐观，我们逐渐坠入了恶性循环。就如政治经济学里所讲的，社会劳动时间是由社会平均劳动时间决定的，当头部企业在不断坠落的时候，整个社会也在不断恶化。

题外话

我们使用Excel，经常处理数据汇总、单元格行列合并、颜色标注、视图、图表、各种宏计算等等。不知道大家有没有好奇，这是如何实现的，前端如何渲染，后端如何存储，数据量大的情况下又是如何处理的呢。大概从数据存储、数据缓存、数据结构、渲染引擎、公式解析器等几个方面，粗略的分析下Excel的几个方面。 数据存储数据存储主要涉及哪些内容。比如单元格样式、单元格数值、单元格公式、单元格数据类型，以及这些信息如何与单元格进行关联。比如下图，数据【898602B4151730161879】为文本类型，样式为红色字体、黄色背景、粗体、下划线、斜体，对齐方式为垂直居中、水平左对齐，所在单元格为B8。这些信息如何存放。 存储方式，应该便于快速查询、更新、删除等操作。尤其是，面对数据量比较大的情况下，应该不会将数据一次性读取内存，就需要多次读取。如何设计存储格式，便于分步查询处理。我们专注的数据有坐标、数据，其他样式信息是辅助性信息，于是数据分成了三部分，依次为【坐标】、【数据】、【样式】。一般情况下，以单元格为索引，组织数据结构。这样，进行excel表格渲染时，同步填充单元格信息。反过来，通过数据查找坐标，也是一个需求点。数据如何存储呢？借助于数据库中间件，但是目前的WPS、office都是独立于中间件的，它就是一个文本文件。 数据缓存将硬盘里的内容，读取到缓存(内存)，转化为哪种数据结构进行缓存，对于渲染比较有利。要适合于UI渲染，数据快速定位、更新等操作。比如，我们可以用哈希存储，HashMap[B8]=xx。这样在进行表格行列渲染时，的确可以快速定位到当前单元格是否存在数据，并进行渲染。但是，再批量查询相邻区域的数据时，感觉还是有点不舒服。比如，计算公式 =SUM(E10:E19) ,如何定位到该区域内的数据集合，并实现累加操作。在这种情况下，如果可以把数据存放在List中，就可以直接定位到一批数据。但是第二种存储方式，貌似又有问题。进行渲染表格时，不能每次都遍历一遍List，这样性能很低的。如果将两者结合，是不是更好。那是不是还有其他的存储方式可以同时兼备两种方式呢！比如二维数组。 渲染引擎UI视图展示，可以有多种技术平台可供选择，比如winform、web、go、delphi等等。不管用那种技术平台，都需要有表格控件，支持以下技术特性。比如双击、单击、右键、滑动选择区域、动态行列合并、单元格编辑、行列插入、批量复制黏贴等等。渲染算法的优劣，影响了操作流畅性，要实现局部渲染，局部数据的更改。也就是平常所说的MVVM模式，数据模型与视图模型的转换。或者类似于Vue、React的渲染方式。 公式解析器单元格行列合并，也是单元格包含的样式之一。在表格渲染过程中，需要特殊处理。一般情况下，多个单元格合并，在视觉上应该表现为连接为一个大的单元格。只会保留第一个单元格的数据，样式会平铺到整个选择的单元格区域。还有其他区域计算操作，比如区域内的求和、求平均数、公式运算等等。比如 =SUM(E10:E19)，如何进行解析计算呢？首先，识别关键信息，比如 SUM、E10、E19。如何识别这些关键信息，需要精心设计。像SUM属于内部函数，E10、E19是坐标，+、-、*、/、%是运算符，也就是说需要定义一套内部规则，然后通过解析器来动态解析并执行。何为公式解析器，诸如游戏引擎，mvc模版解析器。excel 计算公式也需要一个计算引擎来理解它，这样才能计算出结果。这里面就涉及正则表达式了。其次，在获取到坐标后，如何检索数据呢？就是第3个问题中涉及的，如何设计缓存的数据结构。 性能问题 最后还有一个问题，对于几十万，上百万行的数据文件，如何处理呢？如果有一个几十万行的文件需要加载浏览，难道真的要创建几十万个行控件，来填充UI嘛？这样做会导致性能降低，大量占用电脑资源，明显不合适。比如Android的ListView，上下滑动后，脱离可视区域的Item控件会被重复利用，而不是一直创建控件。 最后Excel 实现是一个复杂的工程，实现很复杂，算法、数据结构、数据存储、解释执行都需要考虑到。以上几点，只是个人在实际工作中的实践与猜想。