最具挑战的项目
虽然这些年做过很多很多项目，有公司的也有自己做的一些小项目。但让我印象最深的，也是让我快速成长的一个项目就是一个青少年近视防控的一个项目。
行业：这个项目是属于眼科医疗行业，人工智能、物联网、大数据方向，涵盖B端和C端的一个项目。
简介：利用物联网、人脸识别与云技术实现的集智能体检、眼健康教育、监测预警、综合干预、跟踪管理于一体的长效近视防控平台，专为“儿童青少年视力监测计划”而生。医院-学校-家长-政府一体化，打通多种眼科医疗设备，服务于多家眼科医院，最终实现体检-数据分析-智能诊断-政府报告等核心功能。刚开始只是垂直于眼科，后期改版为了智能体检方向。
产品端：整个产品线包括了PC端、微信小程序端、移动PAD端、桌面应用端。其中PC端又包含了不同的用户角色，有面向医院、面向政府疾控中心（大数据报告）、面向学校（体检报告）等。微信小程序端是面向学生和家长使用的，PAD和桌面端是面向体检工作人员使用的。PAD和桌面端又通过物联网技术与设备（如验光仪、生物测量设备、眼底相机、扫码枪、串口服务器）进行通信。
架构：系统架构的话，后端采用JAVA微服务架构，前端PC采用Vue+elementUi配合webpack工程化开发，微信小程序使用原生开发。PAD端使用的也是Vue+elementUi刚开始是直接用浏览器，后期使用的Uniapp重构。桌面端采用了Electron打包开发。
前端框架刚开始是准备使用angular的。但当时Vue很火，很多公司都在用，就选了Vue。我也是在18年下半年的时候接触的Vue，也算是直接就能上手。
整个产品从立项，到调研，去眼科医院以及参与学校的体检进行需求考察与评审，再到最终开发、调试、现场实测、再到迭代、UI设计优化都有全程参与。大概参与时间一年多，到离开的时候，第一版已经卖给了山西的爱尔眼科医院整个山西十几家医院吧，还有临汾的眼科医院。在谈的也有几家医院，包括外省的医院。当然后期还有一些功能和需求没有实现，需要慢慢完善和迭代，但是核心功能已经完成。后期又添加了很多新的体检科目，不仅是眼科。
整个小组除了技术经理是前端出身之外，前端刚开始就我一个人，因为刚开始做这个项目的时候没想到后面有那么多需求。做到后面又加了2个。后端有3个人。
个人职责：
所有的前端架构搭建，满足多端需求。像PC端面向不同的用户角色，使用的一套项目架构，因为UI风格是一致的，功能点有重合有不重合的，还有一些个别的定制服务（比如某个医院想添加付费的验光配镜服务，但另一家不需要）。所以我们最后给不同用户角色用的不是一个系统，他们互相没有关系，但一些数据是共享的。比如给某个医院我们打包成一套系统，给另一个医院又是另一套。给疾控中心的又是另一套。他们各自购置各自的服务器。学校和医院是在一个系统的。只是不同的用户角色。医院也可以开启权限，将数据共享给政府，这是后端做的事了。
我参与开发的功能，基本上都有参与，列举几个：
- 小程序端的家长登陆，信息录入，人脸识别登陆。体检报告生成，每次体检的数据对比可视化。家长提醒服务，发送公众号消息提醒家长孩子眼睛问题，什么时候该体检了。还有配镜的推荐。核心功能是体检报告。针对不同的数据给出合理建议。
- PC端：面向学校的班级人员信息录入。包括单个录入和批量excel导入和导出。学生个人报告和班级报告生成。体检结果给出建议。
- PC端：面向医院，有不同学校的数据检索功能、数据手动录入、数据可视化、班级整体体检报告生成。
- Pad端：标准对数视力表视力录入（工作人员），验光仪物联网自动录入，姓名、手机、身份证检索；数据实时更新（web-soket）。连接扫码枪和验光仪。
优化、性能
优化方面，就是一些Vue相关的优化。主要是首屏白屏和加载慢的问题。
用户体验
这个在实测中发现问题不断优化。当时做过的优化有很多，比如：
- 在体检时候，左右眼视力最初是做的下拉选项，后面操作时候，效率跟不上，经过商议改为了直接将所有的视力数字从3.几到5.几一次性用按钮方式排列，直接点击就能录入。
- 在操作时为提高效率，将按钮放到最适合的位置。
个人成长
- 首先是技术方面的经验得到了提高。比如前端架构、Vue框架，比如物联网的经验、串口服务器与设备接入。
- 提高了发现问题和解决问题的能力。有实测，有调研，有使用反馈。解决问题有独立思考、有团队协作、有会议探讨。
- 拓展了项目及产品研发的整体的把控能力。比如如何将调研转变为需求，如何将需求落地，不同的需求要用什么功能实现，由于成本和效率问题，有没有必要满足这个需求或者哪些需求是重要的，优先级最高的。
项目中的难点及解决方式
1、为什么要用条形码
因为在体检过程中，学生开始体检时需要在系统中检索到他，然后录入后数据才能与之关联。功能和现在的核酸检测差不多。
刚开始用的是直接输入模糊搜索，可以输入姓名、或者身份证、手机号，但是有很多问题，比如重名，手机号重复或者没有，而身份证又太长，总之就是搜索还需要打字，而且模糊查询查出来的有多个人，需要2次操作，效率太低。所以当时考虑使用条形码或者二维码。（现在核酸检测用的身份证扫描，但是学生年纪小没有身份证，也记不住号码），最后选择条形码搭配扫码枪进行检索。还有个问题就是，条形码必须打印出来放到学生手中，因为如果是扫描手机上的条形码的话，学生又不让带手机。
所以最终的解决方案就是使用学生ID生成条形码，将其批量打印出来，下发给对应的学生。
2、多页面条形码打印问题
首先，学校的班级很多，学生很多，所以需要打印的条形码很多，刚开始是后台生成条形码图片，然后返回前台，然后前台通过排版为HTML，再打印，后台生成很慢，返回前台再打印效率很低。而且需要等待所有条形码图片都加载完成才能通过window.print()去打印。而且小的图片效果不好，容易失真不清晰。大的图片生成又慢。
后来了解到前台也有条形码生成工具JsBarcode，可以生成svg格式的图片，矢量图比较清晰，但在使用后发现，条形码生成效率虽然提高了，但是由于是打印的A4纸，排版后的页面太多，有一百多页，导致window.print()执行后会特别卡，需要很久才能显示预览的界面。而且打印出来底部的条形码和名字有的被一分为二到第二页上面了，而且打印的每页右侧空白过大，条形码也变形了。
为解决变形和空白的问题，多次查阅才发现是页面宽高产生的问题，用的是A4纸，所以经过不断调试宽高，让每个条形码和名字以合适的宽高均匀排版到打印的纸上，一行排几个，一列几个。
另外为解决页数过多的卡顿问题，可以将条形码尺寸改的小一点，让一页尽可能多的排列，让页数变少，但是这样的话页数还是很多，而且条形码的尺寸小不方便扫描。
经过思考，想的办法是，能不能把数据分成多份去打印，但当时用的是window.open()的方法打开新的空白页，但不论是使用window.open()还是模拟a标签点击事件打开多个新标签都会被浏览器拦截。多次尝试下，最终解决办法是：在一个标签解决多次打印问题，将数据分为多份，将第一份数据排版之后，赋值给body进行打印，监听打印事件onafterprint，等到一份打印完成，再次将页面body赋值为新的数据，再次执行window.print()（这里需要设一个setTimeout延迟，否则无法弹出打印预览窗口）进行打印。
3、某生物测量仪器的数据实时上传问题
在处理物联网问题时，遇到最大的问题就是不同品牌的设备数据导出的方式不同，而且数据传输的协议也不同。比如有些是通过蓝牙实时传输，有些可以通过wifi实时传输，大部分是有一个RS232串口的串口。通过串口连接到串口服务器，在将数据实时传输到服务器接口。然后根据不同牌子厂家提供的数据协议、密码等进行解码。这其中遇到几个很难解码的数据格式，甚至于乱码根本解不了。
最后通过长期与厂家和经销商技术员沟通，才知道他的数据连接线需要定制，而他没有提供配套的连接线。最后联系做数据线的供应商才解决这个问题。
这其中有一台设备，没有数据线导出口，他的数据是在电脑软件上实时生成一个xml文件到硬盘中。这就需要写一个脚本，监控文件变动，实时解析xml文件然后将数据传回后台。
最初公司后端他们用java写的脚本，但是编译后软件比较大。当初我正好是在研究Go语言，因为Go语言编译打包后的可执行包很小，所以我直接用Go写了一个脚本。当时也算是小小练手，但最终测试没问题后，被领导采纳了。
4、PAD端uniapp打包
刚开始时候，在PAD端直接使用浏览器，但浏览器还需要输入域名，且需要手动去全屏界面，且无法与安卓的蓝牙进行交互，监控不到蓝牙设备。后来选型使用uniapp，因为uniapp也是用的Vue。但是当初在使用uniapp的时候，还不成熟，遇到过很多问题，文档写的也不太好，有很多问题。所以解决这些问题也用了不少时间。
5、可视化报告快速生成平台
当初公司在做供应链运营的项目，有很多的功能点需要数据可视化分析报告。而且这些报告需要不同的模板，有的需要实时数据，且需要导出PDF、以及线上页面。而且在未来公司开发相关系统也会有这样的需求。为了节省时间，提高开发效率，我向领导提出开发一个数据可视化页面快速开发平台。通过组件拖拽及简单配置，配合导入的数据或接口可快速生成可视化报表页面，可进行导出 PDF、Word 及 Html，也可生成链接嵌入到其他系统，提高公司业务的可视化报表快速开发效率。这里用到的技术是Vue+echarts。
前期的组件封装和模块开发问题不是很大，难点就是公共组件很多，需要封装很多，比如配置项，不同的图表有很多重复的配置项，所用的输入表单太多，如果一个图表就要写一堆表单，太费力。
所以解决方法是封装很多公共的组件，将输入框、下拉框、单选多选等进行二次封装。而界面上的图层也是不同的图表封装不同的组件，如果有相同的配置提取出来，给出默认值。然后在展示的时候使用动态组件形式。
另外拖拽功能、图层叠加、图层缩放、视图界面缩放也花费了不少时间。这里我全部都是用原生写的。使用了很多鼠标事件。也做了节流操作。
最终存到数据库的数据是一个大的json对象，其中包含了报表的信息和图层数据。
最大的问题就是，初期测试，图层过多的话，内存会吃不消。在配置和拖拽操作时会有一点轻微的卡顿。在不断的测试和与同时沟通过程中，发现内存占用过多的就是一些配置项数据等。因为之前是只要创建一个图层，图层相关的数据就一直在内存中，当时是考虑激活的时候配置栏能够响应快一些。
这块解决办法是全部能使用懒加载的操作就使用懒加载。在图层点击激活的时候再加载相关的数据和组件，如果加载较慢就添加loading。在切换图层之后，将不需要的数据进行及时销毁（只保留当前状态，其余如默认值、图层配置项全部置为null）（原先是切换图层之后，由于图层所在组件并没有销毁，所以组件内的数据包括静态的和响应式的全部都在）。
本文固定连接：https://code.zuifengyun.com/2021/02/2963.html，转载须征得作者授权。
