摸鱼精选第 32 期

本教程展示了如何 从零开始 用 Rust 语言写一个基于 RISC-V 架构的 类 Unix 内核 。

本网站针对 GPT 的 Promt 进行优化。大部分人能够说话，但不懂聊天，俗称口才不行。感觉在 GPT 领域也是一样，同一件事，不同的 Promt 得出的答案有很大区别。

本指南的目的是通过详细描述在 Uber 编写 Go 代码的注意事项来管理这种复杂性。这些规则的存在是为了使代码库易于管理，同时仍然允许工程师更有效地使用 Go 语言功能。

中文翻译：uber_go_guide_cn (opens in a new window)

本文档为《前沿课—吴军讲 GPT》的课程笔记。 每小节包含两部分： 1.课程关键句（问题） 2.思维导图（点开更清晰）

本书是 Linux 内核大牛 paul 的力作， 主要讲解并行编程的内容。

最新的英文版是 v2023.06.11a。

有一个很老的中文翻译版本：《深入理解并行编程》 (opens in a new window)

最全的中华古典文集数据库，包含 5.5 万首唐诗、26 万首宋诗、2.1 万首宋词和其他古典文集。诗人包括唐宋两朝近 1.4 万古诗人，和两宋时期 1.5 千古词人。数据来源于互联网。

Xcode 最让开发者诟病的可能就是开放性了，插件 API 能做的事情太少，只能针对 Editor 部分加砖添瓦。但还是有很多人在 Xcode 上面不懈努力，尤其是 Copilot 出来之后，iOS/Mac 开发者对 VS Code 简直是羡慕嫉妒恨，所以 Copilot for Xcode (opens in a new window) 出来了。但是 Copilot 或者 chatGPT 都要收费，所以目前我的 VS Code 使用的是 Codeium (opens in a new window)，一个免费的 AI 代码助手。

学习如何在 Figma 中创建一个设计系统，并逐步练习，包括创建 Figma 样式和变量，以实现一致和高效的设计工作流程。

尼尔森的十大可用性原则被广泛运用于网页、APP 以及各种人机交互领域。

Node.js 最佳实践。

有中文翻译: nodebestpractices (opens in a new window)

• Riverpod 之 Provider(一) (opens in a new window)，使用 Provider 讲解了 WidgetRef 和 Ref 的 watch 要点

• Riverpod 之 StateProvider（二） (opens in a new window),讲解了 StateProvider 的内部流程，主要涉及的是其内部的名叫 state 的 Provider。

• Riverpod 之 Provider&StateProvider(三) (opens in a new window),讲解了 Provider 和 StateProvider 的组合使用。

• Riverpod 之 StateNotifierProvider（四） (opens in a new window),介绍了 StateNotifierProvider 的使用。

• Riverpod 之 FutureProvider（五） (opens in a new window),介绍了 FutureProvider 的使用。

• Riverpod 之 select（六） (opens in a new window),介绍了 Provider 的 select 方法使用和原理。

• Riverpod 之 family（七） (opens in a new window)，介绍了 family 方法得使用和内部流程

• Riverpod 之 autoDispose(八) (opens in a new window)，介绍了 autoDispose 方法的使用和内部流程

• Riverpod 之 override（九） (opens in a new window)，介绍了 override 属性的使用和内部流程

RocksDb 源码剖析系列

在使用 Swift 的 Combine 时，注意订阅事件时的sink(receiveValue:)方法如果传递是实例方法 handle(value:)，会默认 capture self。

class ViewModel {

    var cancellables = Set<AnyCancellable>()

    init() {
        publisher
            .sink(receiveValue: handle(value:))
            .store(in: &cancellables)
    }

    func handle(value: String) {
        // `self` can be used here
    }
}

这里相当于:

class ViewModel {
  ...
  init() {
        publisher
            .sink(receiveValue: {
              self.handle(value: $0)
            })
            .store(in: &cancellables)
  }
  ...
}

在 WWDC 23 中，Apple 推出了全新的 Observation 框架，旨在解决 SwiftUI 上的状态管理混乱和性能问题。这个框架的工作方式看似非常神奇，甚至无需特别声明，就能在 View 中实现属性粒度的订阅，从而避免不必要的刷新。本篇文章将深入探讨背后的原理，帮助您：

• 理解 Observation 框架的实质和实现机制
• 比较其与之前解决方案的优势所在
• 介绍一种把 Observation 前向兼容到 iOS 14 的方式
• 探讨在处理 SwiftUI 状态管理时的一些权衡与考虑

本文主要阐述以下观点，如果你早已知晓，请忽略本条内容：

• Apple 在 2008 年 7 月 11 日 推出的 iOS2 里，带来了 NSKeyedArchiver、NSKeyedUnarchiver，2018 年 9 月 10 日发布的 iOS12 几乎废弃了 NSKeyedArchiver、NSKeyedUnarchiver 中所有的方法，甚至包括 init 方法。Apple 花了 10 年时间，发现 NSCoding 是一个坑。
• iOS6 推出的 NSSecureCoding 是高配版本的 NSCoding，NSCoding 并不适合你用，请及早弃坑。而这不是你的问题，是 NSCoder、NSKeyedArchiver、NSKeyedUnarchiver 内部实现有问题。iOS6 修复了 NSCoder 的问题，iOS12 修复的是 NSKeyedArchiver、NSKeyedUnarchiver。
• UIKit 出厂时还在用 NSCoding，Foundation 出厂时，标配 NSSecureCoding。
• Foundation 中任何类都可以遵循 NSCoding，但是 NSObject 出厂时，并没有遵循。所以实现 -initWithCoder: 时，不能总是调用父类的 [super initWithCoder:]，有时要调 [super init]。
• Nib 与 Storyboard 方式加载的 UIViewController ，是通过 -initWithNibName:bundle: 来声明文件路径，-initWithCoder: 与 NSKeyedUnarchiver 来加载的。了解这一点，有助于理解 UIViewController 生命周期。
• 当一个对象被初始化时，init 方法可能并不会被执行，可能是通过执行 -initWithCoder: 初始化，所以只在 init 进行初始化，可能会丢失数据、属性。 -initWithCoder: 常常被忽略。

九宫格预览时，会用 ➋➌➍➎➏➐➑➒ 替代 A-Z 的位置，当用户在预览选择了具体的词汇之后，textField 的 text 才会回调真实的文本。

本文章基于 WWDC23 中 Beyond the basics of structured concurrency (opens in a new window) 进行创作：

• 结构化任务在任务取消上相较于非结构化任务的优势
• 结构化任务在任务优先级传递上的优势
• 结构化任务结合 TaskLocal 包裹值在单个任务中复用任务维度属性的优势
• 结构化任务在全链路性能追踪中的优势

本文整理自美团技术沙龙第 76 期《大前端研发协同效能提升与实践》，为大家介绍了美团到店前端研发框架 Rome 实践和演进趋势。

具体来讲，本文首先介绍了 Rome 整体的工程生态、演变路径、规模化升级以及工程框架外的开发辅助工具；第二部分，重点阐述了如何做框架度量和相关的业务实践；最后做整体的总结以及对工程框架的下一阶段的思考。希望能对大家带来一些帮助或启发。

本文会先带领大家一起简单回顾下跨端技术背景与演进历程与在这一波儿接着一波儿的跨端浪潮中的饿了么跨端现状，以及在这个背景下，相较于业界基于 React/Vue 研发习惯出发的各种跨端方案，饿了么为什么会选择走另外一条路，这个过程中我们的一些思考、遇到及解决的问题和取得的一些成果，希望能给大家带来一些跨端方面的新思路。

本文主要探讨了 Redis Sorted Set 数据类型底层的实现原理和游戏排行榜实战。

对 Flutter 中的线程模型和单线程异步原理有了更深入的理解，开发时也能更好更安全地运用 Flutter 的 Isolate，Future 和 await。

总结下文章的核心内容：

• Isolate是Dart平台对线程的实现方案。和普通Thread不同，Isolate 拥有独立的内存，由线程和独立内存构成。Isolate线程之间并不存在资源抢夺的问题，所以也不需要线程同步机制；
• 简单耗时任务，可以使用简版Isolate：compute；
• Isolate通过事件循环和消息队列来实现单线程异步并发，这比多线程异步并发要轻便；
• 可以通过Future进行单线程异步并。Future异步的特点是提供了链式调用，可以解决回调地狱，异常捕获和代码执行依赖等问题；
• 也可以通过async和await实现单线程异步并发，它是同步风格的异步操作，比Future更简洁美观；
• Root Isolate支持IO耗时操作，但不支持高CPU耗时操作。

本文主要介绍 React 18 中的 Streaming。

jenkins 有 2 种流水线分为声明式流水线与脚本化流水线，脚本化流水线是 jenkins 旧版本使用的流水线脚本，新版本 Jenkins 推荐使用声明式流水线。文档只介绍声明流水线。

本文旨在探讨长连接技术在移动端的实践，针对百度 iOS 端在建设长连接过程中的技术选型和整体架构逻辑将做重点展开。同时结合 IM 即时通讯案例的介绍和分析，展示长连接是如何在移动应用领域为类似业务场景提供解决方案的。

本文将分为五个主要部分。首先，对长连接技术进行概述，包括定义、与短连接的对比以及在移动互联网领域的常见应用。接下来，会简单介绍百度长连接服务，包括搭建的背景以及建成后提供的服务核心主流程。然后，将重点讨论百度 iOS 端长连接 SDK 搭建过程中的挑战和解决方案，包含协议的选择、DNS 解析优化、长连接保活机制的设计等。紧接着，以 IM 即时通讯场景中的长连接实践为例，展示了长连接 SDK 是如何为业务实现请求数据转发、接收服务器主动推送等功能的。最后，对本文的主要内容做了总结，以及对长连接在移动端应用中未来的发展趋势和前景进行了展望。

重点介绍了 Redis 的 LRU 与 LFU 算法实现，并分析总结了两种算法的实现效果以及存在的问题。

Redis 4.0 版本开始就提供了 8 种内存淘汰策略，其中 4 种都是基于 LRU 或 LFU 算法实现的，本文就这两种算法的 Redis 实现进行了详细的介绍，并阐述其优劣特性。

通过对 Redis LRU 与 LFU 算法实现的介绍，我们可以大体了解两种算法策略的优缺点，在 Redis 运维过程中，可以依据业务数据的特性去选择相应的算法。

如果业务数据的访问较为均匀，OPS 或 CPU 利用率一般不会出现周期性的陡升或陡降，数据没有体现出相对的“冷热”特性，即建议采用 LRU 算法，可以满足一般的运维需求。

相反，业务具备很强时效性，在活动推广或大促期间，业务某些数据会突然成为热点数据，监控上呈现出 OPS 或 CPU 利用率的大幅波动，为了能抓取热点数据便于后期的分析或优化，建议一定要配置成 LFU 算法。

在 Used_memory 接近 Maxmemory 的情况下，Redis 一直都采用随机的方式筛选数据，且筛选的个数极其有限，所以，LFU 算法无法展现出较大的优势，也可能会淘汰掉比较热的数据。

本文来自快手电商无线团队，主要介绍了 ReactNative 里常见的状态管理方式，包括 RN 官方提供的方案与其他第三方框架的对比，同时也给出了 Redux ToolKit 和 Zustand 的最佳实践。

百度 APP iOS 端包体积优化系列文章的前两篇重点介绍了包体积优化整体方案、各项优化收益和图片优化方案，图片优化是从无用图片、Asset Catalog 和 HEIC 格式三个角度做深度优化。本文重点介绍资源优化，在百度 APP 实践中，资源优化包括大资源优化、无用配置文件和重复资源优化。不管是资源优化还是代码优化，都需要分析 Mach-O 文件，以获取资源和代码的引用关系，本文先详细介绍 Mach-O 文件。

百度 APP iOS 端包体积优化实践系列文章回顾：

• 《百度 APP iOS 端包体积 50M 优化实践(一)总览》 (opens in a new window)
• 《百度 APP iOS 端包体积 50M 优化实践(二) 图片优化》 (opens in a new window)