知鸦日报2022-05-12

5天获客30w、1年赚10亿，这些App可真行！

Android Q 和 iOS 13 为我们带来了 Dark Mode，这已经不是什么新鲜事了，很多团队都已经拥有了各自适用的解决方案，起点读书的 Dark Mode 设计解决方案也终于从幕后开始进入到项目落地环节，从时间跨度上来讲已经大半年过去了。这段时间经历了各产品解决方案的轰炸与洗礼，我们又结合起点本身的产品定位与结构特点，在此背景下一套融合 Dark Mode 和主题皮肤设计的解决方案应运而生。

本文会重点聚焦设计落地执行的解决方案，视觉解决方案每个产品都有自身不同特点，且 Android 和 iOS 官方都各自拥有符合各自平台的设计解决方案，因此不在此一一赘述。

互联网企业里，谈产品很自然，不谈产品才奇怪。但是在传统企业的IT侧，比较熟悉的是“系统、项目”等，对“产品”还很陌生。在互联网企业的不断冲击下，传统企业也意识到需要用产品思维的方式去创造价值。希望本文能够对当前在这类组织、以及未来可能参与到类似组织里的伙伴，提供些帮助。

弹幕作为一种即时性互动方式，直观地呈现了观众对特定内容的反应。由此而衍生了弹幕文化，也记录了年轻群体及时代的变迁。随着用户及内容的增长，发送弹幕逐渐成为年轻人常用的评论行为，除了现有的弹幕样式，还有哪些可挖掘的玩法呢？

基于字节跳动分布式治理的理念，数据平台数据治理团队自研了 SLA 保障平台，目前已在字节内部得到广泛使用，并支持了绝大部分数据团队的 SLA 治理需求，每天保障的 SLA 链路数量过千，解决了数据 SLA 难对齐、难保障、难管理的问题。

信也科技基础架构部为解决服务调用不统一、异构语言和异构框架服务治理等问题，采用istio落地Service Mesh，进行了云原生的落地。本文将分享我们在大规模落地istio过程中遇到的两个挑战。

自从著名设计师 Ethan Marcotte（@beep）在 A List Apart上发表了一篇名为《 Responsive Web Design》的文章之后，响应式网页设计（RWD，即 Responsive Web Design）的身影就出现在了公众面前。自此就有了响应式 Web 设计这个概念。从提出这个概念到今天已经有十多年的时间了。在这十多年来，CSS 也发生了巨大的变化，新增了很多新的特性，近两年尤其如此，近两年尤其如此（详细请参阅《2022 年的 CSS》一文）。这些变化，对于响应式Web设计的开发也有较大的改变。Una Kravets（@Una）大神，在2021的Google I/O 大会上的分享，提出 新的响应式：组件驱动式 Web 设计。Web 生态即将进入响应式 Web 设计的新时代，并转变我们对其含义的看法，也为会Web设计带来新的变化。组件式驱动 Web 设计（或开发）也被称为是下一代响应式 Web 设计（或开发）。

本文将解析钉钉 Flutter 业务灰度过程中，在桌面端遇到并处理过的几个 FlutterEngine 层面的 Bug。

In this post, I want to give a nuanced perspective on our experience porting YJIT from C to Rust. I'll talk about the positives, but also discuss the things that we found challenging or suboptimal in our experience.

买早餐的时候会遇到，支付宝和微信两个二维码一起被识别出来的情况，处理起来比较麻烦。最近有时间，就来分享记录一下图片中多个二维码选择的实现过程。

Electron 是以 Nodejs 和 Chromium 为内核的跨平台开发框架。本文结合网易云信的实践经验，对 js 和 C++ 混合编程在 Electron 桌面程序中的应用进行介绍。

单元测试是工程交付前质量保障的第一环，在工程重构演进时起到至关重要的作用。

umi是一个插件化的企业级前端应用框架，在开发中后台项目中应用颇广，确实带来了许多便利。由于这个契机，便有了我们接下来的“umi3源码解析”系列。

从现有方案可以看出，现在PHP调用Java接口步骤是很繁琐的，开发效率偏低。而且还有两个问题：泛型无法解析、不便本地调试。所以要进行重构来解决这些问题。

如何根据公司网络架构和业务特点，锁定正常请求被误判为跨域的原因并解决。

从CDH集群滚动升级到HDP集群的实践案例。

提到分区表，一般按照范围（range）来对数据拆分居多，以哈希来对数据拆分的场景相来说有一定局限性，不具备标准化。接下来我用几个示例来讲讲 MySQL 哈希分区表的使用场景以及相关改造点。

近几年之家基于Go在不同的业务场景下（高并发服务、云原生、中间件、机器学习、用户产品、嵌入式等）有着丰富的开发实践，接下来会基于这些场景分享一些典型案例。

我们在特征服务DataService中利用Disruptor替换线程池后试图解决机器cpu利用率不高，长尾请求延迟不线性等问题。本文简单介绍了一下对Disruptor的个人理解以及落地的结果。

《iOS15动态链接fixup chain原理详解》[1]对 iOS15+ 动态链接过程性能优化的深度解析，引发了字节跳动APM团队对MachO文件的编译链接过程探索的兴趣。在学习的过程中，初学者常常会因为对该领域的不熟悉而陷入误区。本文整理了初学者比较容易犯的三大认知误区，避免大家重蹈覆辙。

如果你要开发一个电商库存系统，最担心的是什么？当然是高并发和防超卖了！本文给出一个统筹考虑。

当需要处理的数据非常多，比如行情数据，一秒处理非常多的数据的时候，可以考虑用无锁队列。但是如果一秒只需要处理几百或者几千的数据，是没有必要考虑用无锁队列的。用互斥锁就能解决问题，数据量相对少的时候互斥锁与无锁队列之间差别并不是很明显。

公司近两年快速发展，社区线C端代码分散在不同仓库中，每个仓库中采用不同的前端框架和选型，且均含有几条业务线的代码，团队整体采用敏捷模式快速迭代，导致开发管理成本较高，升级改造麻烦。比如，所关联的三个仓库中的代码均引了一个内部基础组件库，该组件有非必现bug，导致三个仓库的不同页面均出现了不同表现的异常，由具体负责的不同测试分别报到前端开发，分别沟通、排查、解决并走独立的发布上线流程，耗时耗力。当同一仓库中活跃着不同业务线的开发，一个公共的地方需要修改，开发没有沟通清楚导致冲突线上bug。

此外，公司C端体验分析的统计和报表是应用粒度的，先前代码耦合了其他业务的内容，导致我所在业务线的统计数据不置信。

近期团队对C端项目进行重构，将不同仓库中的代码汇总到一个仓库中管理。以期减少管理成本及方便后续对组内项目做优化和升级改造。

InnoDB层的文件除日志文件外，都具有较为统一的物理结构。所有物理文件由页（page 或 block）构成，在未被压缩情况下，一个页的大小为UNIV_PAGE_SIZE（16384，16K）。不同用途的页具有相同格式的文件头和文件尾，其中记录了页面校验值、页面编号、表空间编号、LSN等通用信息。根据不同的应用场景和功能可以将页面分为多种类型，比如：每隔一定数量的页面后会使用extern描述页来记录每页空闲与否；Inode页面用于存储segment信息，segment是表空间管理的逻辑单位，每个索引占用2个segment，分别用于管理叶子节点和非叶子节点；索引页用于存储索引和用户记录；Blob页面用于记录溢出行的内容等等。InnoDB文件的结构可以详见《浅析InnoDB文件结构》。

本文主要讨论用户记录存储相关的数据页面（索引页和外部存储页）的物理结构以及组织方式。InnoDB用B+树的方式管理用户记录数据，每个索引对应一个B+树。B+树是通过索引页构建的，用户记录的数据存储在聚簇索引的叶子结点中。如果有变长字段（如text、blob、varchar）的长度过长，则可能会将该字段的全部数据或部分数据存储到外部存储页（blob页面）。