简介：Cube卡（立方体），以便应用主页可以实现敏捷更新。
第7号Codehub正式得出结论，Ant Group的技术专家“ Jingjun”分享了Nuggets社区的开发商Cube的新卡技术堆栈。
Jingjun解释了其围绕Cube技术架构逻辑的渲染和生产过程，并指导开发人员完成最初的技术调试。
从Windows时代开始，应用程序图标已成为用户（流量）的主要入口，并继续进入移动时代。图标是进入的方式。缺点不是直观的。至少一键单击您需要联系所需信息的信息。在此上下文中，iOS系统和一些Android系统已经意识到了内容和服务的卡，如下图所示：
此外，Hongmeng系统还提出了类似的卡片场景作为某些流量的入口。实际上，内部卡更为常见，因为内容显示和服务入口。例如，中国商人银行的Abipay主页和财务管理页面，每条都是卡片。对于操作，可以随时配置卡样式和内容。它也只需要等待随时升级应用程序版本即可。
立方体立方体（立方体）是蚂蚁组内的自发开发的横截面动态卡解决方案。它是应用程序页面内的区域动态技术，并运行内容以帮助产品技术提高开发效率和运行效率。每个橡皮饼的立方卡已独立嵌入本机页面中的区域。区域内容通过卡模板显示。
这是高性能。CUBE卡（Cube）正在追求亲密的本地体验。我们定义了两个维度：
一个是最终的性能。在Cube Mini -Prompromprogram功能的基础上，我们删除了一些复杂的CSS功能，例如伪-PSEUDO-元素，Inline/Block等。同时，我们还限制了JS功能（Rubik的Cube卡使用QuickJS作为脚本引擎）。此外，我们对QuickJS进行了一些优化，包括不限于离线原子编译和优化，异步GC优化等。我们还将WAMR作为QuickJS介绍为“合作者”，支持用户使用JavaScript和AssemblyScript来开发。通过这种方式，用户可以使用AssemBlyscript一些热功能或模块。
另一个维度是最终的内存。在信息瀑布的情况下，魔方的记忆增长与本机卡接近。我们使该卡的分级能力更细微。通过在开发过程中配置，减少了操作过程中的内存消耗。下面的图显示了一张简单的卡，如Rubik Cube卡的项目目录所示，以及钱包的真实代码和操作效果。
Rubik的立方卡（CUBE）支持独立开发工具，支持卡汇编，日志输出，真实时间预览和其他功能。VUE是当前开发模板的DSL语言，并支持JS和CSS编辑卡样式。
该卡的本地开发完成后，通过卡管理背景上载并发布了卡编译产品。您可以管理卡的卡版本。卡发布后，您可以在客户端上动态更新卡。
为了促进访问Rubik的Cube卡，我们引入了CardDk.CardsDK的概念，连接了一些业务层/服务器，并且一般能力由某些包装制成。通过cubecardsdk.in的服务器，cardDk还负责访问常见的JSAPI和第三部分组件。这样，rubik的Cube卡可以更多地关注卡产品本身。
立方体立方体（立方体）的系统架构主要包括JSengine，Cardengine，Renderngine和Platform的几个部分。大多数代码由C ++实现。
它主要负责监视卡JS逻辑执行和卡数据更改，从而支持开发人员在卡中编写一些业务逻辑功能，以实现卡片内容和样式的动态更改。
由于卡场景对性能，全面的包装尺寸和性能有很高的要求，因此我们选择了QuickJS作为JS基本引擎库，同时又实现了一个很小的JS响应框架（JSFM）来支持CardLogic Code中的卡片能力。
它主要负责卡数据，卡逻辑渲染，建筑物DOM指令，JSAPI管理，JSBINDING，本机事件通信等的分析和结合。
Card Dom树的初始化，我们没有将其放入JS中运行，而是直接通过C ++来生成指令和树构造在Card实例初始化中。另一方面，C ++具有更高的工作效率。
后端渲染基础负责卡布局计算，样式分析，层计算，自画组件，相同的层渲染，屏幕和其他过程以及手势和运动效果的过程。
平台相关的接口，包括原子视图包装，帆布API，三个选项组件的扩展协议，动画API等。
线程模型
立方体生命周期中的主线程包括业务线和发动机线程。业务线程是卡数据的初始化阶段。发动机线程是所有卡生命周期的共同线程，主要包括桥梁线，渲染线，油漆线和UI主线程。
JS线程也是DOM节点数据查询和处理线程。由于Rubik的Cube卡的较小而快速的定位，JS Logic只是卡辅助功能，并且没有太复杂的业务逻辑。因此，线程模式。
渲染相关的数据计算线程，包括渲染树的构建，节点层次计算，层分层绘图计算，手势数据计算和渲染任务构建。
绘制线程，执行层状绘图和卡节点的光栅任务。paint螺纹不是固定的线程。根据当前的任务模型，油漆线程可以是线程池中的主线程或子线程。在同步渲染模式下，油漆线直接是主线。以及异步渲染模式，疼痛任务是由线程池渲染的，以提高渲染效率，例如在列表中滑动场景。
UI操作的主线程是当前平台线程，主要包括手势识别，UI上屏幕和数据更新组件的数据更新。
除了上面涉及的主线程外，还有操场背景线程与监视有关。总体优先级相对较低。总体线程模型设计最大程度地减少了UI主线程的压力并提高了复杂的渲染效率。但是，仍然存在一些缺点，包括频繁的UI线程切换，较重的桥梁线程等，等等，等等。并将在以后继续优化线程模型。
数据模型
与线程模型相对应的数据模型主要包括三个树：Nodetree，Rendertree和Layrtree。此外，还有一个临时的画家。
卡的原始节点树，对应于前端DOM树，发动机将根据Nodetree计算和布局；
渲染数据树，这是一个变形树。在许多情况下，其树级结构与Nodetree相同。实际上，在设计和定义末端的数据模型时，我们仍然保留了与Nodetree相同的树。原因是该树可以更灵活地调整树的关系。如果将卡分为布局阶段和渲染阶段，则该树是渲染阶段的源树。
事实证明，我们的决定是正确的。我们随后支持的Zindex/静态的能力是因为该树的存在可以由发动机层很好地支持，而不是模拟平台层上的这种变化能力，以模拟更改更改能力的能力结果的水平。结果，包括将来的情况非常有限的方案支持，我们还可以从这棵树上考虑这棵树。
顾名思义，Layrtree树是一棵分层的树。节点是根据渲染树进行分层的。同一层的节点在同一渲染任务管道中绘制。不同的层彼此独立，可以同时渲染。
绘画者是一棵临时树。实际上，严格来说，通过Rendertree复制了一棵复制树。渲染时会暂时生成。当然，一些节点将被优化。例如，完全覆盖的节点将是优化的，避免重复渲染。每一层都有一个绘画者，并绘制节点以通过绘画者的形式与节点一起生成光栅指令或位置。
高性能列表渲染
对于在列表中使用卡的场景，它主要考虑口吃的影响，尤其是中端和低端机器设备。Rubik的立方体卡（Cube）支持异步渲染，因此在列表方案中可以平滑。同时，由于它支持多线程并发容量，因此可以渲染多个卡。因此，在异步渲染条件下，不会明显的白屏效应。
本地技术优化
我们希望卡服务能够在页面上显示页面的区域内容和简单的业务逻辑，并且更适合移动开发人员。即使我们使用的卡DSL语言描述是前端语言，我们也希望限制使用CSS和支持有限的CSS功能，但我们也希望涵盖某些开发人员通常使用的CSS功能。
因此，我们已经完成了CSS功能的特殊工作，并且我们已经与前端团队技术同学制定了CSS功能规格，并且我们限制了CSS功能。因此，即使在本机渲染引擎下，也很难支持支持。这些功能非常好，包括Zindex的支持，溢出等。因此，我们还根据某些依赖平台功能进行了优化。
层容器
我们介绍了层容器的概念。当我之前介绍数据模型时，我们提到了LayerTree。每个层节点是一个独立的渲染容器。平台视图是呈现其他虚拟节点的图层容器。如果是传统的方法是查看容器，我们使用两个视图组合为层容器（ios）来分离内容层和逻辑层。问题，剪切的内容层，切割catvas的内容层优化等
光栅
立方体渲染过程包括两种渲染模式：指令渲染和位图渲染。这两种模式将在不同的方案下切换，以优化不同方案的性能，例如帧速率和内存。该位置在Android上的渲染相对复杂。默认情况下，将位图用作离线渲染的缓存。缺点是它引入了额外的CPU/GPU内存副本，无法充分利用GPU资源。优势是良好的兼容性。我们试图将TextureView用作离线渲染缓冲区，并发现严重的兼容性问题以下是6.0以下，并且不同设备之间的稳定性很大。
同时，轻度测量能力的帆布API取决于平台系统。一些高级别方法将涉及硬件加速度的限制，包括Shadow API和系统对Glrender Buffer（Android平台）的限制。确保渲染性能。我们还使用Canvas API用Skia Canvas替换平台层API。
同时渲染
Cube（Cube）使用三个方组件作为独立的图层层单独更新数据，这对于扩展的三个 - 组件。基于系统的UI功能可以非常方便且有效地访问数据，从而使卡片中的扩展组件在卡中均匀地呈现。同时，它支持不同卡片上的组件的重复使用。在实际的业务场景中，同一层的渲染也带来了许多其他问题。组件（例如MAP/VIDEO/AINSITATION）通常伴随着大型性能记忆这些费用对卡的渲染有负面影响，尤其是在滚动列表时。对于地图/视频组件，我们与组件提供商合作以逐案解决问题，并尝试设置卡点在启动卡时。对于动画组件，Cube继续扩展属性动画/框架动画功能，并在帆布功能中构建了 -
目前，Cube已为主页，证券（股票），卡袋，旅行和其他20多个服务的商业场景提供服务。每日PV超过100亿。将来很长一段时间，“支撑件”中的业务情况将逐渐成为现有本机卡和H5卡的立方体。
因此，一方面，我们将继续在开发人员的经验（例如开发和调试工具链）方面做得很好。另一方面，我们还将继续优化基本性能，例如追求较小的袋子和较低的内存。
同时，已为MPAA推出了Cube卡（立方体）Beta，用于使用移动开发人员。在公共Beta期间，登录到MPAAS控制台，并立即免费提供十个卡模板。
将来计划的另一个方向是IoT设备的应用程序开发堆栈（例如RTOS）。确切地说，它不是立方卡，而是该卡和小程序的某种中间形式。
物联网设备的界面通常相对简单且靠近卡。但是，多个“卡”之间的路由功能需要更接近应用程序的形式。类似的混合物不仅可以保留内存/性能/软件包量的优势，而且还可以满足物联网设备应用程序开发的需求。
根据我们的调查，大多数RTOS应用程序开发环境仍然存在于传统的C语言中，并且性能和动态不是理想的选择。对于开发人员来说，立方体可能是一个不错的选择。
资料来源：阿里巴巴云