大型项目自动化发布平台前端系统实现与优化
随着移动平台的兴起，传统的前后端耦合的开发模式不再合适，后端改为专门负责提供数据接口，以应对多平台开发的需求。
故而前后端开始独立，web应用开始了工程化的改造。在前端工程化的改造中，开发人员除了要探求适合前端开发的工程化实践范式，还需要应对实践过程中出现的性能问题，及时予以解决。
在项目工程化实践过程中，结合框架原理以及新兴的技术，对开发过程中遇到的诸多性能问题，分别给出了解决方案，并予以实施。
针对采用单页应用的开发范式导致的页面最早可交互时间延后的问题，分别对文件的拉取流程和解析渲染流程做出了优化。
运用基于CacheAPI的预加载技术减少了拉取流程的时延，使用渐进式渲染的方式，对页面进行有梯度的渲染，提升了页面的整体渲染速度。
对于大型表格的渲染更新慢，操作效率低下的问题，在vnode渲染（render）阶段，检查vnode的状态是否发生了改变，在未发生改变的情况下，复用缓存的vnode，避免了大量高开销的vnode新建操作。
在更新提交（commit）阶段，框架需要使用Diff算法对比新旧vnode的差异，以确定需要执行的DOM操作，项目内使用LIS算法优化了框架原有的Diff算法，减少了不必要的DOM操作，避免了大型表格的更新造成的卡顿。
用户生成的发布任务，需要经过审批人的审批，才能被用户操作。审批人在任务生成后，会在企业微信中收到通知，审批人通过点击链接进入任务审批页面。
无论任务包含多少子任务，都会在此页面展示出来。为了方便用户检视，通过折叠面板分别展示了发布任务的基本信息与计划的具体批次安排。
如果出现发布申请中包含多个发布任务的情况，系统将设置Set类型的对象viewedTabs，用于记录用户已经访问过的发布任务，当用户访问过一个发布任务后，会将该发布任务的id存入viewedTabs中。
Set类型的对象储存的内容是总是唯一的，对象内不会出现重复的值。因此只有当viewedTabs的长度等于关联发布的任务的数量时，操作按钮才可以被使用。
这样就保证了审批人检查到所有的发布任务。
审批人最终可以对发布申请执行通过或驳回的操作。当选择驳回时，审批人可以向申请人反馈不给予通过的具体原因，方便申请人优化方案。
任务列表页面展示了用户生成的所有发布任务，每一列都展示了一个任务的相关信息，比较重要的就是任务发布进度和操作按钮。
对于未进行审批的任务，用户可以在这里主动触发提醒，提醒审批人完成工作。如果已经被审批通过，用户就可以执行任务的开始，结束，终止等操作。
为了保证任务进度的同步显示，应用会通过setInterval方法在后台发起轮询操作，不断更新页面。
任务监控页面展示单个任务发布的详细情况，展示发布过程中每一个批次的发布进度，同样通过轮询确保用户获取信息的实时性。
用户可以对正在发布或未发布的批次进行调控，包括编辑批次发布安排，提前发布某个批次等操作。
确保发布的顺利进行。发布中的任务可以暂停，终止或者回滚。
用户正在使用的身份会通过localStorage存储在本地，用户打开应用时，读取本地存储的身份，确保用户身份的一致性。
应用会通过getAllTanants方法对用户所拥有的身份进行拉取，通过下拉选择框的形式进行展示，并提供切换身份的功能。
当用户切换身份时，会对localStorage进行更新，并使用router.go（0）方法实现页面的原地刷新，拉取更新后的身份对应的内容。
应用在运行过程中，如果没有在本地读取到用户的身份信息，说明用户是新用户，会自动跳转至身份管理页面，指引用户选择身份或创建新身份。
原有的持续发布平台，随着上线后用户逐渐增多，为了应对不同用户繁多的需求，平台的功能持续不断的优化新增，随之而来的就是代码库变得越来越庞大。
这种庞大不仅体现在开发过程中需要更细心的维护、组织代码，也体现页面加载性能越来越差上。
因为本平台采用单页面网络应用的开发范式，在未经过优化的情况下，用户请求的页面不会携带任何信息，浏览器需要拉取页面中引用的JavaScript脚本，接着执行脚本生成可以交互的页面。
代码库越庞大，浏览器自然就要花更多的时间执行，页面的最早可交互时间越来越难以控制在可以接受的范围内。
通过详尽的测试，验证了持续发布平台的功能实现的完善性以及稳定性。通过对比实验的方式，证明项目在最早可交互时间，大型表单性能优化等方面的实践的有效性。
