本文将深入介绍 Chromium 内核组成结构，并以渲染流水线为主线，从接收字节码开始，按渲染流程来一步一步分析这个字节码究竟是如何转变成屏幕上的像素点的。
本文主要针对Feeds流进行介绍，将从Feeds流的演变入手，带你一步步了解Feeds流，而后学习如何从开发角度入手，对其进行建模，抽象出Feeds流常见的架构，最终搭建高可用、高扩展、高性能的Feeds流应用。
近期，我们接管并重构了十多年前的 Query 理解祖传代码，代码量减少80%，性能、稳定性、可观测性都得到大幅度提升。本文将介绍重构过程中系统实现、DIFF修复、coredump 修复等方面的优化经验。
近期，我们接管并重构了十多年前的 Query 理解祖传代码，代码量减少80%，性能、稳定性、可观测性都得到大幅度提升。本文将介绍重构过程中系统实现、DIFF修复、coredump 修复等方面的优化经验。
本文简述了 GPU 的渲染管线和硬件架构，对一些常见问题进行了讨论和分析。有以下几点核心内容：（1）移动平台渲染管线 TBDR 的介绍；（2）GPU 缓存体系的介绍；（3）Warp 的执行机制；（4）常见的如 AlphaTest 或者分支对性能的影响。
Serverless 炙手可热，被称为云原生未来发展的方向。信通院报告显示：在核心业务中使用 Serverless 的用户占到18.11%，已经开始和计划使用 Serverless 技术的用户超过了70%。Serverless 广受追捧，得益于它在“快速的开发交付”、“极高的运维效率”、“极低的资源成本”这三个方面上的优势。 Serverless 可以让业务更快上云，让用户用最小的运维投入享受云带来的便利性。底层资源规划及运维交给更专业的云平台处理，使用户可以更专注业务和产品本身，从而更好地提升产品和业务的核心竞争力。 Serverless 的优势如此明显，但在实际落地使用中，无论是云厂商还是用户，均处在摸着石头过河的阶段，仍在不断学习不断试错，主要原因是 Serverless 在带来便利性的同时，也打破了传统 Serverful 模式下的种种用户使用习惯，对企业各个组织均造成了冲击；其先进的产品形态在老的架构上又引入了较高的适配复杂度。具体表现在：
为了应对大流量，现代应用/中间件通常采用分布式部署，此时不得不考虑 CAP 问题。ZooKeeper（后文简称 ZK）是面向 CP 设计的一个开源的分布式协调框架，将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用，分布式应用程序可以基于它实现诸如 数据发布/订阅、负载均衡、命名服务、集群管理、Master 选举、分布式锁、分布式队列 等功能。ZK 之所以能够提供上述一套分布式数据一致性解决方案，核心在于其设计精妙的数据结构、watcher 机制、Zab 一致性协议等，下面将依次剖析。
还是先给出结论，没时间看分析过程的同学至少可以看一眼结论： 1. Channel本质上是由三个FIFO（First In FirstOut，先进先出）队列组成的用于协程之间传输数据的协程安全的通道；FIFO的设计是为了保障公平，让事情变得简单，原则是让等待时间最长的协程最有资格先从channel发送或接收数据； 2. 三个FIFO队列依次是buf循环队列，sendq待发送者队列，recvq待接收者队列。buf循环队列是大小固定的用来存放channel接收的数据的队列；sendq待发送者队列，用来存放等待发送数据到channel的goroutine的双向链表，recvq待接收者队列，用来存放等待从channel读取数据的goroutine的双向链表；sendq和recvq可以认为不限大小； 3. 跟函数调用传参本质都是传值一样，channel传递数据的本质就是值拷贝，引用类型数据的传递也是地址拷贝；有从缓冲区buf地址拷贝数据到接收者receiver栈内存地址，也有从发送者sender栈内存地址拷贝数据到缓冲区buf；
