你遇到过 Mysql--index merge 死锁吗？

Android 应用堆栈是 Android 应用程序的一种重要组件，它提供了对所有正在运行的应用程序的信息。Android 应用堆栈可以帮助开发者更好地理解应用程序的运行状态，帮助开发者进行性能调优，以及更好地排查应用程序中可能存在的问题。

在严选基于webview+APP的混合开发模式下，前端和客户端的协作显得尤为重要。细节、标准与沟通可以说是我过去两年时间做混合开发的主要经验，本文中将从这几个方面展开，来从一个前端的角度讲述混合开发经验。

本文介绍了云音乐过去1年里在客户端性能监控方面的实践经验，探讨 CPU 高消耗、OOM、卡顿、ANR 等典型异常场景的监控原理和实施效果。

网易云音乐开源了曙光埋点 dawn，一个跨多端的全链路埋点解决方案，旨在构造一个完美的数据理想国。曙光埋点创造性的提出了埋点虚拟树（VTree），并在此基础上实现了诸多能力，解决大前端侧埋点困难、精度差、不稳定、质量不高的问题。

说起插件系统，大家或许会对这个概念感到陌生，但其实不然，这个看似很抽象的概念其实在我们日常生活中有着很多很直观体现。

经过两年多的积累和打磨，OSSA 终于在去年下半年顺利开源。作为Taro生态下的UI组件库，OSSA 一经开源，便获得了Taro官方的推荐。本文将带你了解OSSA的前世今生，并着重介绍OSSA在走向GitHub开源时所遇到的问题和挑战。

通过引入qiankun微前端框架，实现项目的渐进式升级，既能快速引入新的框架开发新的功能，又能灵活的根据需求逐步翻新已有的功能，直至整个项目完成重构升级。

SpringBoot应用已经作为Java开发中的首选方式，在云音乐中有着广泛的应用。在云音乐的实践中，为了简化拉取新工程的成本，有一个脚手架作为工程的初始化模版。本文描述了云音乐服务端应用启动时间优化过程，包括分析和落地实践阶段。

网易智企技术委员会是由各个事业部研发代表组成的网易智企技术工作的保障机构和技术标准审议机构，下设 7 个分委会，智企技术+会定期分享各分委会在智企技术保障工作中的建设经验与落地实践。本文为效能分委会专题技术文章，分享网易云信 Marvel 平台建设经验。

我们在工作中经常遇到的一个词，那就是“产品NPS调研”。当部分项目缺少专业的用研人员时，设计师、产品经理则经常会接受上级的要求，投身于NPS调研工作。

笔者也曾在2022年的某天突然接到一款产品年度NPS调研的任务。那么，NPS调研究竟该怎么做？下面将根据笔者的个人经历复盘，带领大家重温NPS的调研方法。

云音乐 iOS App 经历多年的迭代，积累了大量的 Objective-C 代码，现在开始探索 Swift 混编。本文介绍了云音乐主站在 Module 化过程中的分析与实践。

乐高（MINOS）的初衷是为了快速解决网易严选 C 端大促频繁配置 + 大量已有业务配置沉淀在 Apollo 的现状下，引发的对研发资源占用问题，希望能够把技术语言的配置转化为业务语言，同时将配置的角色扩散到产品、业务方等。

对于一款游戏而言，玩家/消费流失是其生命周期中最为关键的问题之一。消费流失，指曾在游戏内有历史消费，且累计消费金额达到一定规模，但最近一段时间不再消费的情况。通常情况下，该类人群和游戏流失用户有一定重合性，玩家从游戏中流失，自然便不会再有游戏内消费；另一种情况下，玩家在游戏内留存，但在消费上流失，这类玩家往往是游戏厂家非常想、也比较容易挽回的消费者。好消息是，他们对游戏仍然保有兴趣，相比游戏流失玩家更容易再次产生消费，坏消息是，游戏内目前的供给没有满足这些玩家的需求，导致玩家在消费上流失。

玩家从游戏中流失的原因是多种多样的，例如对游戏的角色设计、玩法内容等机制不满，或是养成过程中投入产出比过低，亦或是社交原因和个人原因。该类玩家的召回往往随缘，游戏更新的内容吸引力够强、或是转了一圈没有别的游戏就又回来了。当然，我们也可以通过信息渠道的触达去进行流失召回，但总体上，在根本问题没有解决的情况下，召回的效果是有限的。对这类玩家进行分析和调研的目的，不仅在于挽回这部分玩家，更在于亡羊补牢，及时发现问题，避免其他玩家因同样的问题流失。

玩家仍然在玩游戏、但不再消费的原因更是值得洞察的，我们期望听到他们的诉求，了解怎样才能让他们继续留在游戏当中。

压测是每个项目必不可少的一个测试领域，而压测范围的评估是压测中最重要的环节之一，那么我们如何在有限的时间资源内，通过合理地评估压测范围，尽可能去保证项目的压测质量呢？

在游戏社区中，无论是活动或者游戏相关的工具都需要有较为浓厚的游戏特色，才能较好的让用户能沉浸其中。因此要求设计师在设计时对游戏有一定的了解，根据游戏的特色去设计定制化的UI。

但有一些如以赛季为周期迭代的活动，因为每个赛季的风格不尽相同，因此UI的风格也需要随之变化。此时如果每个赛季都重新设计开发的话，需要投入较多的人力物力，可能会对活动收益造成一定的影响，所以我们需要在定制化的基础上将UI进行模板化设计。

这个时候可能会有读者好奇，定制化？模板化？这好像是两个截然不同的概念。

确实表面看来，又要定制又要模板，好像有点不太合理。但转换个思路，如果把定制化中可复用的部分提取出来，根据每赛季不同的风格对其重设计，遵循一定的规范原则，以某种方式替换，就能减少大量的开发成本，又可以在设计上做出满足不同风格的变化。