本文主要记录了作者与自己的心魔展开 “殊死搏斗”，最终建立起了一套良好的阅读与写作循环的过程。希望本文可以帮助更多的人破除自己的“心魔”，通过阅读与写作过上更加充实的人生。
积分体系作为一种常见营销工具，几乎是每一家企业会员营销的必备功能之一，在生活中随处可见，随着vivo互联网业务发展，vivo积分体系的能力也随之得到飞速提升，本篇主要介绍vivo积分任务体系的系统建设历程。
vivo推送平台是vivo公司向开发者提供的消息推送服务，通过在云端与客户端之间建立一条稳定、可靠的长连接，为开发者提供向客户端应用实时推送消息的服务，支持百亿级的通知/消息推送，秒级触达移动用户。 推送系统主要由接入网关，逻辑推送节点，长连接组成，长连接负责与用户手机终端建立连接，及时把消息送达到手机终端。 推送系统的特点是并发高、消息量大、送达及时性较高。 vivo推送系统现状最高推送速度140w/s，单日最大消息量200亿，端到端秒级在线送达率99.9%。同时推送系统具备不可提前预知的突发大流量特点。针对推送系统高并发，高时效，突发流量等特点，如何保证系统可用性呢？本文将从系统架构，存储容灾，流量容灾三个方面进行讲述，推送系统是如何做容灾的。
最近这段时间收到了一些读者的私信，问我某个技术要不要学，还有一些在国外的同学竟然对 Java 图形化很感兴趣，还想找这方面的工作。 比较忙，一直没抽出时间去回答这类问题，刚好看到我关注的一位大佬回答过，这里分享一下，希望对你能有帮助。
今天我们来聊一个 JavaScript 不是特别常用的语法 Generator ，我在实际的项目开发中很少看到有人去用，可能因为它的语法相对复杂，使用 async/awiat 也都能实现，所以大家实际很少去使用。但是在一些复杂的流程控制、状态判断的需求场景中 Generator 还是挺好用的。 今天我们就从基础到实践再来学习一下 Generator 。
笔者之前发表的音视频文章，有图像的处理，音频的重采样等等，都属于入门级别。通过阅读它们，读者能对音视频有了了解。可在 Gitee 上面回顾。 2023 年，笔者将整理下 关于OpenGLES的实验室系列 并进行发表。首先为读者带来2D篇的系列，它大多是x y坐标，不涉及z坐标，所以用 2D篇。内容上，它不对OpenGLES的基础知识进行细说与讨论。但如果对OpenGLES不了解或者了解一点，仍可通过本实验室系列了解OpenGLES。它旨在激起读者的兴趣，扩展到实际的应用上。总的来说，这些实验& Demo将是额外的，即对基础学习的补充，通过这些它们的实践和运用，能让读者进一步了解OpenGLES。
Android 项目一般使用 Gradle 作为构建打包工具，随着业务需求的不断迭代，代码量提升的同时，Gradle 编译耗时也在不断的增长，而编译速度会直接决定开发流程效率的高低，影响面主要涉及到开发和测试阶段。 对于火车票项目，经过长期的迭代过程导致模块众多工程庞大，优化前一次干净的全量编译时间可达到10m39s，造成开发和测试都需要长时间等待编译出包，严重影响到开发和测试的效率。因此对火车票 App 进行编译速度优化是件亟待解决的事情。 本次编译速度优化采用的方案是模块AAR方案, 优化目标为: 优化后一次干净的全量编译时间缩减为原来编译时间的50%以下。
最近一年，小玉所在的业务部门发起了轰轰烈烈的微服务化运动，大量业务中台应用被拆分成更细粒度的微服务应用。为了迎接即将到来的双十一大促重保活动，小玉的主管让她在一周内梳理出订单中心的全局关键上下游依赖，提前拉通各方对齐重保方案。这个任务可愁坏了小玉，平时她只与直接上下游业务方打交道，现在要梳理出订单中心完整的依赖路径，头发愁掉了一大把仍然不知道该如何下手。无奈之下，小玉再次求助于万能的小明。 针对小玉的问题，小明提出了一个想法，首先调用链可以追踪一次请求的完整调用路径，但是单条调用链无法反映出所有的调用分支，也无法通过流量大小体现出依赖的强弱，而逐条分析调用链的成本又太高。那么，是否可以通过程序将一批具有相同特征（比如经过某个应用，或者调用了某个接口）的调用链聚合成一颗树，通过分析这棵树的形态与流量，就可以快速梳理出关键节点与依赖路径，而这就是链路拓扑功能的雏形。
