Tango是一个用于快速构建低代码平台的低代码设计器框架，并以源代码为中心，执行和渲染前端视图，并为用户提供低代码可视化搭建能力，用户的搭建操作会转为对源代码的修改。借助于Tango构建的低代码工具或平台，可以实现源码进，源码出的效果，无缝与企业内部现有的研发体系进行集成。
目前Tango设计器引擎部分已经开源，正在积极推进中，可以通过如下的信息了解到我们的最新进展：
本文主要探讨基于Tango低代码在RN场景如何打造一套标准低码研发体系。
RN（ReactNative）是Facebook开发的一种基于React框架的移动应用开发框架。它可以用于同时开发iOS和Android平台的跨平台移动应用程序。
在npmtrends上可以看到，RN每周的下载次数，稳固上升，相比5年前，下载量已经翻了接近10倍之多，GithubStar数量也来到了110K之多，拥有非常庞大的社区生态。
在国内，无论大公司、小公司都钟情于应用的动态更新。因为动态更新能降低产品的试错成本。如果产品策略有调整，可以立马上线，线上有小问题也可以快速修复。但能够既满足动态更新，又能跨端，还能满足复杂业务需求的只有JavaScript语言。
2022年，对于ReactNative来说是一个大年，因为重构已久的ReactNative新架构已经确定会在今年正式推出，相对于老架构，新架构在最关键的性能问题上有了非常大的提升，这将会为ReactNative开启一个全新的阶段。
RN有着众多优势，云音乐也有相当多的RN需求，在需求不断地迭代，研发不断地投入过程中，还是暴露了一些问题。回顾一下C端场景的特点，往往是重视觉，重交互，我们来看一下目前介入一个RN需求开发并最终交付上线的核心过程：
如图所示，开发第一阶段，还原设计稿，这个过程其实可以追溯到需求评审阶段：设计稿的页面构成，哪些已有现成组件，哪些需要定制开发，样式部分的代码如何编写等。
不同场景的RN需求对应的实际业务开发有所不同，以下三种是最为常见的业务开发类型。
我们期望构建一套为低码为中心的在线研发体系，通过整套体系标准化来解决目前的问题，降低研发成本和门槛，提高效能。
RN迭代从需求到交付涉及到多个核心环节，以下是目前开发现状和低码研发体系的对比。
Tango将提供以源码为中心的RN在线搭建能力，支持RN应用快速交付，并提供标准化的线上研发流程
云音乐在移动端传统搭建上已经有了一些实践，但是在实际使用过程中遇到了一系列的问题。
DSL方案局限性
首先传统搭建平台大多基于DSL驱动，再交由DSL解析器进行渲染，映射到对应的组件。DSL本质上其实就是对代码的一种抽象，描述为一种Schema的形式进行可视化编排，最终还是要映射到真实的组件，组件消费DSL中携带的信息。
如果面向业务模式稳定的固化场景，进行深度垂直定制，在这个前提下一套DSL确实可以解决大部分场景，剩下的场景可以直接放弃(交由开发介入)。
但是移动端场景的特点就是灵活性高，而此类产品的特点往往面向运营等非开发角色进行无码搭建，快速交付。在实际使用过程中，会遇到DSL无法满足业务需求，需要开发介入定制DSL，升级组件的情况。
这个过程中其实带来了较大的成本:
基于AST驱动
Tango通过AST驱动，可视化的修改实际上就是对源码进行修改，对源码的直接修改其实就跳过了DSL映射到源码的过程，这样做的好处是，没有中间产物的形成，不需要额外的开发资源维护，也不会耦合至其他环境，可以跟现有的云音乐RN研发生态较好的融合。所以Tango主要面向研发同学，解决灵活场景下的RN开发，侧重对研发环节进行提效。在一些轻量场景，也可以作为NoCode平台，提供运营同学可视化搭建的能力。
从上图可以看出：无论DSL还是AST，最终都是映射到实际的组件，组件能力的强大与否会直接影响整个低码体系，以及需求交付的效率。组件，是非常重要的！
RN和Web应用在线开发最大的区别在于运行环境的不同，Web场景可以基于CodeSandbox实时预览，RN场景依赖App物理环境。
常见的RN应用调试环境:
目前云音乐RN研发主要使用模拟器+真机扫码两种形式进行开发，起步我们考虑了相对轻量的方案：RNForWeb进行初步搭建及预览，再结合真机扫码进行实际联调，这样做的好处是在设计器运行沙箱上可以复用现有CodeSandbox能力，不需要做定制，但该方案马上暴露了一系列问题：
综上，选用MacIOS模拟器作为真机运行环境，完美贴合本地开发体验。也带来了更大的挑战，我们需要模拟一套在线开发环境(远程本地开发):
下面我们来具体看一下如何解决这些问题。
首先我们来解决第一个问题，回顾一下本地开发过程：启动RN项目，通过模拟器或者真机App访问RNbundleUrl进行调试预览，本地启动的devserver其实就是打包服务(metrodevserver)，产物为:
xx://10.10.10.10:8081/index.ios.bundle那么远端构建其实就是将本地流程容器化：拉取项目代码，构建打包，输出产物。如图所示：
在低码平台初始化时将完整的代码推送至构建服务，构建服务分配一个实例进行上述构建过程，平台或者手机访问打包产物即可，代码变更时patch最新代码，触发HMR热更新即可。
Expo真机界面通过实时图传的方式进行返回(如下图所示)，我们也进行了类似方案的实践，实践结果是在20~30FPS帧率下实时截屏图传返回至Web再显示，Socket存在时序和堆积问题，造成画面时序不一致且闪烁严重。
其实还有一种方式可以获取到屏幕的实时画面，通过直播推流的形式，将物理屏幕进行捕获推流，网页拉流播放即可，也就是传统意义上的"直播"。
ffmpeg-fx11grab-video_size1280x720-i:0.0+100,200-falsa-idefault-c:vlibx264-presetultrafast-pix_fmtyuv420p-c:aaac-fflvrtmp://your-streaming-server-url/your-stream-key最终采用OBS进行窗口捕获及推流，OBS优势：自带窗口捕获，画布调整，完整的推流参数配置，以及内置WebSocket服务器可以进行直播控制。
常见的直播方案如下：
由于云手机交互时效性要求，需要一套低延迟直播方案，经过综合对比：
选用SRS流媒体服务器进行转码，使用OBSRTMP进行推流，Web使用WebRTC进行拉流得到云手机实时画面。
SRS是一个开源的（MIT协议）简单高效的实时视频服务器，支持RTMP、WebRTC、HLS、HTTP-FLV、SRT、MPEG-DASH和GB28181等协议。SRS媒体服务器和FFmpeg、OBS、VLC、WebRTC等客户端配合使用，提供流的接收和分发的能力，是一个典型的发布（推流）和订阅（播放）服务器模型。SRS支持互联网广泛应用的音视频协议转换，比如可以将RTMP或SRT，转成HLS或HTTP-FLV或WebRTC等协议。
CANDIDATE="192.168.1.10"dockerrun--rm-it-p1935:1935-p1985:1985-p8080:8080\--envCANDIDATE=$CANDIDATE-p8000:8000/udp\registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5./objs/srs-cconf/rtmp2rtc.confOBS推流与拉流接下来对OBS进行一定的配置，Mac设备优先选用H264硬件编码进行推流，码率和帧数控制在一定范围，推流地址设置为rtmp://{your_ip}/live/{your_livestream_key}即可。
网页端使用WebRTC播放器进行拉流，WebRTC（WebReal-TimeCommunications）是一项实时通讯技术，它允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。
至此，我们已经获取到实时画面，模拟器摇身一变成为云手机，接下来的核心问题：解决云手机的通信和交互，以及多台云手机如何调度分配的问题。
首先解决如何分配的问题，场景是：用户访问低码平台时，需要使用一台云手机，而一台物理机上可以启动多台云手机，并可以同时有多台物理机，需要正确的分配到一台设备。
有同学可能发现了，这个模式非常像"反向代理"，那么顺着这个思路，我们需要实现一个虚拟网关，负责通信和调度，我们来看一下大致过程：
此时用户已经分配到云手机，且可以看到实时画面。接下来就要解决如何通讯的问题，既然是通讯那么肯定首选长连接，我们需要与云手机建立SocketB，该Socket可以将页面的消息发送至云手机App并将App中的数据返回至平台。上述流程如图所示：
此时云手机通讯机制已经建立，我们可以请求云手机加载某个RN页面，但此时云手机无法"使用"，云手机需要支持基本的点击/滑动交互：
基于已经建立的通讯连接，我们可以远程"操控"云手机并获取到App中运行的信息以及日志，在平台侧进行展示，为在线联调提供了通道，目前主要开放了以下几个能力：
快捷工具栏：为了还原本地开发体验，我们将调试工具中常用的能力进行了可视化，在云手机一侧提供了工具栏，进行快速使用。
运行状态栏:在底部状态栏的左侧显示了目前云手机的设备信息以及当前App的信息。
日志信息栏:显示当前warning,error的数量，点击后展开Console面板，查看当前Metro日志信息，对齐ChromeConsole体验。
至此，前文提到在线开发的7个问题均已解决，我们来看最后一个问题，如何与低码进行结合
在C端场景Tango也保持了社区常见的交互形式，通过页面结构树面板可以对页面中的节点进行增删改查，调整位置等操作。
常见交互为大纲树和设计器都需要在点击后回显选中的节点，由于RN代码实际运行在客户端中，此处就带来了另一个问题:静态的RN代码节点与客户端运行时的节点如何映射，确实是一个比较有趣的问题，我们可以延续之前模拟点击交互传的思路，大致如下：
通过标记节点，客户端计算返回选中的节点坐标宽高信息，模拟选中框覆盖在云手机上，达到选中的效果。
对于专业RN开发同学，或复杂场景需切换至源码进行开发，我们也对源码模式下的开发体验进行了增强，提供"左看右写"的模式，结合完善的在线调试工具，典型场景下，可以完全脱离本地开发环境，使用线上进行开发。
Tango低码的理念不仅限于"在线"，"可视化搭建"，旨在构建一个以源码为中心，完整的低码研发生态体系。
低码接入的组件能力完善与否也直接影响开发搭建效率，我们针对典型场景使用的高频组件进行细分，对此类组件进行"低码化"增强，减少原子组件重复低效使用的问题。
云手机顾名思义就是取代了物理手机，目前依赖物理手机的场景大部分都可以通过云手机进行平替，并且由于云手机拥有建全的通信机制，交互能力，可以畅享更多的可能性，以下罗列了一些比较常见的应用场景：
篇幅较长，如果您看到这里了，非常感谢，希望能给各位带来一些收获。最后还是想聊一点题外话，市面上大大小小的"低码"产品非常多，包括不限于各种可视化搭建平台，(X)aaS平台，代码插件工具等。
低码理念的出现本质上是为了解决某个(类)问题或某个(些)场景。在近几年社区低码概念的发展以及业务实践经验来看:
不够贴合业务，无法开箱即用，接入成本高，门槛高，拓展性强。
贴合业务场景，可以开箱即用，接入成本低，门槛低，拓展性差。
这就是一个"天平"问题，如何寻找到平衡点是一个值得持续探讨的问题，低码的本质是提效，是解决问题，在这个大前提下，如何做到高内聚，低耦合的T型架构，是值得低码从业者持续思考和实践的~共勉~