目前我所在的团队正在研究面向营销域的中后台前端解决方案。通常来说，中后台解决方案的核心目标是提效，提效包括两个方面，一方面是对研发人员的提效，另一方面是对用户的提效，提效的核心抓手在于生产关系的变更，由前端开发向后端，视觉，产品各方面参与发展，从而降低前端研发的门槛，提高生产效率。提效解决的不是20%的个性化增量需求，而是解决让“非前端”参与进来，解决80%的通用需求。中后台的提效路径大部分走的都是ProCode->LowCode->NoCode方式。

表面上看，从ProCode->LowCode->NoCode看起来好像只有很小的差别，好像只有代码量多少的问题，但整个过程已经从量变发生了质变。ProCode和LowCode主要面向的还是一些需要有前端编程能力的人，而NoCode则代表“非前端”也能够参与的前端的页面搭建中来，这里面不是说完全不需要代码，因为今天哪些算“代码”其实比较难界定，比如用户编写一个配置文件，这个文件是json格式的，那到底能不能算“代码”？所以，NoCode的意思不是说没有代码，而是说在于用户学习门槛和学习成本的降低，普通用户不需要经过艰难的学习就可以做到以前程序要编码才能实现的事情。

iceluna低代码平台的痛点问题

iceluna作为集团内优秀的低代码搭建平台，主要解决中后台页面快速搭建的场景，经过几年的探索，基本能够实现页面UI的可视化搭建，但是针对业务逻辑还是需要手动编码来实现。这对非前端开发人员的上手门槛还是比较高的。下面这张图是最近针对iceluna的用户（前端，后端和测试）做的一个调研分析，可以看到逻辑代码和数据绑定的学习成本也是用户在问卷中提的最多的。

因此在这个财年，我们尝试去用可视化逻辑编排的方式解决逻辑相关的问题，解决低代码中最后一点需要编码的部分，实现无代码化的研发模式，从而进一步降低用户的学习和使用门槛。

可视化逻辑编排

=======

首先我们来通过一个逻辑编排的示例来看一下如果一段代码通过编排的方式呈现出来之后会带来怎么样的体感：

如上图所示，原本晦涩难懂的代码逻辑通过流程图的形式表达出来以后，产品的逻辑变得非常直观。可读性和可维护性也变得非常高。再也不用担心在接手其他人的项目时，注释不规范，文档不全的问题，逻辑编排生成的逻辑图谱就是天然的产品文档。

逻辑节点抽象

---

可以看出，要形成这样的逻辑图谱，本质上就是需要对不同逻辑节点进行组合和串联，真正的逻辑由封装在节点中的函数完成。那么这里就产生了两个问题，首先是如何抽象逻辑节点，抽象出的逻辑节点能不能被复用直接决定了用户编排的成本，如果需要不断的定制个性化逻辑节点可能就失去了编排的意义；其次是逻辑节点的的颗粒度大小也非常关键，如果封装的逻辑颗粒度太大，大到一个功能服务，那么可能就变成了业务流程编排；如果颗粒度太小，小到一个表达式级别，那么对于有编程基础的同学来说，可能直接写代码效率反而更高。

通过对中后台营销域的部分业务代码进行梳理，发现中后台的页面大都是以表单、列表，详情为主，而其中90%的业务逻辑基本上都围绕在表单(校验，取值，赋值，提交)，对话框（显隐、提示），发送请求，消息提示，数据处理，路由跳转，条件判断等，相对比较收敛。同时iceluna作为集团内优秀的低代码搭建平台，在上层封装了很多非常好用的api，屏蔽了大部分前端语法层面的差异，比如状态赋值，页面刷新，接口调用，一些常用的工具函数（时间处理）等，为逻辑节点的抽象提供了极大的便利性。

通过分析归类，最后沉淀了10个左右的逻辑节点，如下图所示，同时每一个逻辑节点最终本质上都是对应一段执行函数，并接收一个参数作为入参，返回一个参数作为出参。

编排协议

---

由于是可视化编排，自然也避免不了编排的协议，为了避免重复建设最大程度的复用集团内已有的编排方案，最终计划采用LF通用可视化逻辑编排的协议来实现iceluna中的逻辑编排。

技术架构图

技术难点

---

自动化布局

从一开始调研我们就发现大部分的编排产品，都是让用户自己进行拖拽，连线等操作去完成，但是通过前面对逻辑代码的分析，如果我们将异步回调操作使用async/await的方式转换成同步的写法，那么逻辑代码大部分都可以看作是一种串行式的执行过程，偶尔叠加一些if/else的分支判断，这样也非常符合人们常用的思维模式，理解起来非常直观。所以从编排的角度说，就是将不同的逻辑节点和分支判断节点串联起来，布局上不需要太多的灵活性，同时连线操作也显得比较多余，因此我们将拖拽连线全部改成添加节点的方式，然后自动连线即可。

采用这种自动布局的方式会大大简化用户的操作，用户只需关注核心的业务逻辑流程，按顺序添加节点即可，但同时也带来一个问题，由于分支类型的节点会产生两个分支流，如果遇到嵌套分支的情况下，需要自动将上层分支的横坐标的位置统一向右偏移一个单位，否则处在上下层不同分支上的节点位置可能会产生重叠。为此，我设计了一自动布局算法，最终实现的效果图如下：

算法过程比较简单，采用的是DFS深度优先遍历算法，详细过程这里就不再赘述。

代码与schema互转

逻辑图编排完成之后，紧接着面临的问题是如何保证编排后的逻辑正确的运行，产生和源码一样的效果。一开始讨论的有两种方案，第一种方案把整个逻辑看成一个事件流，按照前面设计的逻辑编排schema，通过事件注册监听的方式完成逻辑节点的上下游串联，最后设计一套事件执行器，依次触发事件即可。这种方式实现起来比较简单，但是对原有开发流程的侵入性比较强。因为原有保存事件函数的地方都要被替换成逻辑schema，同时负责code review的前端同学看到的不再是代码diff，而是schema的diff，这无疑会大大增加了CR的风险。因此经过一番讨论之后，我们决定采用第二种方案，将逻辑编排后的schema自动转成代码，同时生成后的代码也要能够自动转回schema。

基于schema转成代码是比较容易的，因为每个逻辑节点本身就映射了一段函数片段，而将代码转回schema则稍微有些复杂。这里主要利用了Babel先对代码进行解析，得到抽象语法树AST，然后遍历AST中类型为statement的节点，最后通过正则匹配找到对应的逻辑节点，并串联好连线即可。下图就是生成好的一份代码示例：

可以看出，通过schema生成后的代码与源码编写还是有一点区别，带有一些逻辑编排的特征，但是可读性更强，从代码基本也能直观的反推出逻辑流程图，反而从一定程度上降低了code review的成本。整个AST解析的过程如下：

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！