如何减少react组件不必要的重新渲染、5个接口性能提升的通用技巧 | 酱酱的下午茶第146期
本文字数 1800+，阅读时间大约需要 6 分钟。
今日主理人｜下午茶
每日干货｜下午茶
主理人们会对近期（1-3 天）社区深度技术好文进行挖掘和筛选，优质的技术文章有机会出现在下方列表，排名不分先后。
『前端』
上两个arco design table的bug
如何实现一个带壳截图小程序并发布上线
平常业务开发多多少少都会用到如 Element-ui 、Element PLus 、 Ant design 之类的组件库进行开发， 但是对于其中的实现都是不得其解.
如果出现需要自己手动封装或者二次封装的场景，了解其中的原理对于开发类似的功能来说也能如鱼得水.
出于学习的目的，我会着重将核心实现 和 具体流程 进行讲解，后面会再实现一个丐版Message组件供大家理解
如何减少react组件不必要的重新渲染
有没有办法通过 CSS 实现中间颜色的获取呢？今天来一起探讨这个问题，聊一聊关于颜色合成的相关技巧。
『后端』
本章节将以保姆级教程来介绍一下如何在OpenTelemetry Java Instrumentation上进行二次开发
作为后端开发人员，我们总是在编写各种API，无论是为前端web提供数据支持的HTTP REST API ，还是提供内部使用的RPC API。这些API在服务初期可能表现不错，但随着用户数量的增长，一开始响应很快的API越来越慢，直到用户抱怨：“你的系统太糟糕了。” 我只是浏览网页。为什么这么慢？”。这时候你就需要考虑如何优化你的API性能了。
最近有个业务场景需要服务端(简称S)与客户端(简称C)设计一套基于UDP的通信协议--要求尽可能快的前提下可容忍一定丢包率，得以比较深入地学习和了解UDP通信和实践，在开发调试期间先后碰到了C端UDP发包无响应、响应Host Unreachable、响应Port Unreachable、再次C端UDP发包无响应这四种错误情况，不同于以往连接调试成功后万事大吉不再细究，这次有了好奇心想刨根问底的弄清楚造成不同错误的原因与错误通知的原理，并最终进一步了解了ICMP这个熟悉又陌生的协议。
监控服务平台是自研的、覆盖全场景的可用性保障系统。经过多年深耕，vivo监控团队已经成体系构筑起一整套稳定性保障系统，随着云原生可观测技术变革不断深化，监控团队如何掌舵前行？下面就平台的建设历程、思考、探索，做一下简单介绍。
常见的高级语言都有自己的 Garbage Collection（GC）机制来管理程序运行的内存，例如 Java、Go 等。而 Rust 引入了一种全新的内存管理机制，就是 ownership（所有权）。它在编译时就能够保证内存安全，而不需要 GC 来进行运行时的内存回收。
『移动端』
本文主要说了四部分内容，第一部分内容是应用启动，第二部分内容是启动优化价值，第三部分内容是启动优化业务痛点，第四部分内容是总结与展望。
第三部分内容主要分为四个方面，第一个方面是防劣化机制建设，第二个方面是高性能工具，第三个方面是调度框架，第四个方面是业务框架。
OkHttp源码分析
📖 投稿专区｜下午茶
大家可以在评论区推荐认为不错的文章，并附上链接和推荐理由，有机会登上下一期。文章创建日期必须在近 1-3 天内；可以推荐自己的文章、也可以推荐他人的文章。