低代码组件通信方案复盘、随机数细节解析 | 酱酱的下午茶第148期
本文字数 1800+，阅读时间大约需要 6 分钟。
今日主理人｜下午茶
每日干货｜下午茶
主理人们会对近期（1-3 天）社区深度技术好文进行挖掘和筛选，优质的技术文章有机会出现在下方列表，排名不分先后。
『前端』
我们先去探讨如何写出丝滑的scroll动画，看了这么多网站之后才发觉他们都是使用gsap去做这些过度动画，并且实现起来并不是很困难！
长列表优化的话题是一个老生常谈的话题，我们常用的解决方案无非就是虚拟列表，分页加载的方案。
其中 分页加载 能够解决返回的数据量过大从而首次渲染慢的问题，但是无法解决DOM数量过多造成的渲染性能问题。 而 虚拟列表 能够解决渲染的DOM数量过多问题，但是无法解决首次渲染请求数据过大的问题，同时虚拟列表还存在js运行时以及动态渲染导致的重排重绘从而列表渲染帧率降低的问题。因此我们常常结合这两种技术方案来渲染长列表。
但是纵观列表数据渲染的流程，我们发现列表渲染体验除了受数据量大小，DOM数量因素影响以外，其实还受 接口响应返回时长 影响。我们一般称前者是影响用户体验的 渲染瓶颈 ，后者是影响用户体验的 网络瓶颈 ，本文将着重网络瓶颈问题给出解决方案。
之前也在社区分享了很多低代码和零代码的技术实现, 接下来继续和大家聊聊低代码平台中组件与组件之间的通信方案设计.
啥是区块链，凭啥能安全分布存储？
『后端』
在互联网流量见顶和用户需求分层的背景下，如何快速迭代产品功能，满足用户需求成为了开发首要面对的问题。游戏中心低代码平台从产品定位入手，以组件化方式搭建用户端页面，快速支撑产品需求，提升了研发效率，缩短了项目周期。本文首先介绍背景与痛点，然后阐述了游戏中心是如何搭建低代码平台，最后展示了低代码平台带来的收益和未来建设方向。
I/O密集型业务，线程数量要设置成 CPU 的 2 倍！
也不知道这是哪本书的坑爹理论，现在总有一些小青年老拿着这样的定理来说教。说的信誓旦旦，毋庸置疑，仿佛是权威的化身。讨论时把这样的理论当作前提，真的是受害不浅。
为了帮助大家更好的理解这种虚无缥缈的概念，也为了更好的减少大家在新词频出的IT行业工作的痛苦，作者尝试用人话来解释下DDD，并且最后会举DDD在不同层面上使用的例子，来帮助大家彻底理解这个所谓的“高大上”的概念。
本文整理自字节跳动基础架构研发工程师单既喜在 ArchSummit 全球架构师峰会上的演讲，主要介绍字节跳动离线训练发展的三个阶段和关键节点，以及云原生离线训练中非常重要的两个部分——计算调度和数据编排，最后将结合前两部分分享字节跳动在实践中沉淀的 4 个案例。
在计算机领域，随机数是一个十分重要的机制，除了模拟客观世界的随机现象，有一些场景本身就需要随机数，比如 AES 对称机密算法中需要一个随机数作为密钥，以及 TCP 连接”三次握手“时 TCP 头的 seq 字段应该初始化为随机值。对于人类来说，人脑无法凭空创造出随机数，至少无法证明构思的数字是一个随机数，人类只能借助硬币和骰子等工具来得到一个随机的数字。作为在计算方面比人脑更强大的计算机，能否创造出随机数呢，还是计算机也需要“骰子”呢？
『移动端』
本文阐述了个人对移动端页面加载耗时监控的一些理解，主要从：节点划分及对应的实现方案，线上监控注意点，后续还能做的事 三个方面来和大家分享。
在跨端开发越来越频繁的今天，矛盾也就越来越凸显，对于 H5 开发的同学或者 Flutter 开发的同学来讲，埋点出现查不到或者埋入错误的问题后，需要耗费大量的时间和精力来排查原因，所以迫切需要一个能实时查看埋点是否正确的方式。
📖 投稿专区｜下午茶
大家可以在评论区推荐认为不错的文章，并附上链接和推荐理由，有机会登上下一期。文章创建日期必须在近 1-3 天内；可以推荐自己的文章、也可以推荐他人的文章。