不久前在北京举办的世界人形机器人运动会上，出现了许多令人忍俊不禁的场景：机器人对着空气挥拳、跑步时左摇右摆、踢球时相互碰撞后集体倒地。尽管这些画面看起来颇为滑稽，但回顾过去几年人形机器人的发展历程就会发现，即便当前的产品仍存在诸多不足，其进步却是惊人的。按照这样的发展速度，也许在十年甚至更短的时间内，人形机器人就将走进我们的日常生活，满足各种实际需求。

Alignment refers to the practice of placing data or code at memoryaddresses that are multiples of a specific value, typically a power of2. This is typically done to meet the requirements of the programminglanguage, ABI, or the underlying hardware. Misaligned memory accessesmight be expensive or will cause traps on certain architectures.

This blog post explores how alignment is represented and managed asC++ code is transformed through the compilation pipeline: from sourcecode to LLVM IR, assembly, and finally the object file. We'll focus onalignment for both variables and functions.

Alignment in C++ source code

C++ [basic.align]specifies

Object types have alignment requirements ([basic.fundamental],[basic.compound]) which place restrictions on the addresses at which anobject of that type may be allocated. An alignment is animplementation-defined integer value representing the number of bytesbetween successive addresses at which a given object can be allocated.An object type imposes an alignment requirement on every object of thattype; stricter alignment can be requested using the alignment specifier([dcl.align]). Attempting to create an object ([intro.object]) instorage that does not meet the alignment requirements of the object'stype is undefined behavior.

alignas can be used to request a stricter alignment. [decl.align]

An alignment-specifier may be applied to a variable or to a classdata member, but it shall not be applied to a bit-field, a functionparameter, or an exception-declaration ([except.handle]). Analignment-specifier may also be applied to the declaration of a class(in an elaborated-type-specifier ([dcl.type.elab]) or class-head([class]), respectively). An alignment-specifier with an ellipsis is apack expansion ([temp.variadic]).

Example:

1
2

alignas(16) int i0;
struct alignas(8) S {};

If the strictest alignas on a declaration is weaker thanthe alignment it would have without any alignas specifiers, the programis ill-formed.

1
2
3
4
5

% echo 'alignas(2) int v;' | clang -fsyntax-only -xc++ -
<stdin>:1:1: error: requested alignment is less than minimum alignment of 4 for type 'int'
    1 | alignas(2) int v;
      | ^
1 error generated.

However, the GNU extension __attribute__((aligned(1)))can request a weaker alignment.

1

typedef int32_t __attribute__((aligned(1))) unaligned_int32_t;

Further reading: Whatis the Strict Aliasing Rule and Why do we care?

LLVM IR representation

In the LLVM Intermediate Representation (IR), both global variablesand functions can have an align attribute to specify theirrequired alignment.

Globalvariable alignment:

An explicit alignment may be specified for a global, which must be apower of 2. If not present, or if the alignment is set to zero, thealignment of the global is set by the target to whatever it feelsconvenient. If an explicit alignment is specified, the global is forcedto have exactly that alignment. Targets and optimizers are not allowedto over-align the global if the global has an assigned section. In thiscase, the extra alignment could be observable: for example, code couldassume that the globals are densely packed in their section and try toiterate over them as an array, alignment padding would break thisiteration. For TLS variables, the module flag MaxTLSAlign, if present,limits the alignment to the given value. Optimizers are not allowed toimpose a stronger alignment on these variables. The maximum alignment is1 << 32.

Function alignment

An explicit alignment may be specified for a function. If notpresent, or if the alignment is set to zero, the alignment of thefunction is set by the target to whatever it feels convenient. If anexplicit alignment is specified, the function is forced to have at leastthat much alignment. All alignments must be a power of 2.

A backend can override this with a preferred function alignment(STI->getTargetLowering()->getPrefFunctionAlignment()),if that is larger than the specified align value. (https://discourse.llvm.org/t/rfc-enhancing-function-alignment-attributes/88019/3)

In addition, align can be used in parameter attributesto decorate a pointer or vector of pointers.

LLVM back end representation

Global variablesAsmPrinter::emitGlobalVariable determines the alignment forglobal variables based on a set of nuanced rules:

• With an explicit alignment (explicit),
  • If the variable has a section attribute, returnexplicit.
  • Otherwise, compute a preferred alignment for the data layout(getPrefTypeAlign, referred to as pref).Returnpref < explicit ? explicit : max(E, getABITypeAlign).
• Without an explicit alignment: returngetPrefTypeAlign.

getPrefTypeAlign employs a heuristic for global variabledefinitions: if the variable's size exceeds 16 bytes and the preferredalignment is less than 16 bytes, it sets the alignment to 16 bytes. Thisheuristic balances performance and memory efficiency for common cases,though it may not be optimal for all scenarios. (See Preferredalignment of globals > 16bytes in 2012)

For assembly output, AsmPrinter emits .p2align (power of2 alignment) directives with a zero fill value (i.e. the padding bytesare zeros).

1
2
3
4
5
6
7
8
9
10

% echo 'int v0;' | clang --target=x86_64 -S -xc - -o -
        .file   "-"
        .type   v0,@object                      # @v0
        .bss
        .globl  v0
        .p2align        2, 0x0
v0:
        .long   0                               # 0x0
        .size   v0, 4
...

Functions For functions,AsmPrinter::emitFunctionHeader emits alignment directivesbased on the machine function's alignment settings.

1
2
3
4
5
6
7
8

void MachineFunction::init() {
...
  Alignment = STI.getTargetLowering()->getMinFunctionAlignment();

  // FIXME: Shouldn't use pref alignment if explicit alignment is set on F.
  if (!F.hasOptSize())
    Alignment = std::max(Alignment,
                         STI.getTargetLowering()->getPrefFunctionAlignment());

• The subtarget's minimum function alignment
• If the function is not optimized for size (i.e. not compiled with-Os or -Oz), take the maximum of the minimumalignment and the preferred alignment. For example,X86TargetLowering sets the preferred function alignment to16.

1
2
3
4
5
6
7
8
9
10
11
12

% echo 'void f(){} [[gnu::aligned(32)]] void g(){}' | clang --target=x86_64 -S -xc - -o -
        .file   "-"
        .text
        .globl  f                               # -- Begin function f
        .p2align        4
        .type   f,@function
f:                                      # @f
...
        .globl  g                               # -- Begin function g
        .p2align        5
        .type   g,@function
g:                                      # @g

The emitted .p2align directives omits the fill valueargument: for code sections, this space is filled with no-opinstructions.

Assembly representation

GNU Assembler supports multiple alignment directives:

• .p2align 3: align to 2**3
• .balign 8: align to 8
• .align 8: this is identical to .balign onsome targets and .p2align on the others.

Clang supports "direct object emission" (clang -ctypically bypasses a separate assembler), the LLVMAsmPrinter directlyuses the MCObjectStreamer API. This allows Clang to emitthe machine code directly into the object file, bypassing the need toparse and interpret alignment directives and instructions from atext-based assembly file.

These alignment directives has an optional third argument: themaximum number of bytes to skip. If doing the alignment would requireskipping more bytes than the specified maximum, the alignment is notdone at all. GCC's -falign-functions=m:n utilizes thisfeature.

Object file format

In an object file, the section alignment is determined by thestrictest alignment directive present in that section. The assemblersets the section's overall alignment to the maximum of all thesedirectives, as if an implicit directive were at the start.

1
2
3
4
5
6
7

.section .text.a,"ax"
# implicit alignment max(4, 8)

.long 0
.balign 4
.long 0
.balign 8

This alignment is stored in the sh_addralign fieldwithin the ELF section header table. You can inspect this value usingtools such as readelf -WS (llvm-readelf -S) orobjdump -h (llvm-objdump -h).

Linker considerations

The linker combines multiple object files into a single executable.When it maps input sections from each object file into output sectionsin the final executable, it ensures that section alignments specified inthe object files are preserved.

How the linker handlessection alignment

Output section alignment: This is the maximumsh_addralign value among all its contributing inputsections. This ensures the strictest alignment requirements are met.

Section placement: The linker also uses inputsh_addralign information to position each input sectionwithin the output section. As illustrated in the following example, eachinput section (like a.o:.text.f or b.o:.text)is aligned according to its sh_addralign value before beingplaced sequentially.

1
2
3
4
5
6
7
8
9

output .text
  # align to sh_addralign(a.o:.text). No-op if this is the first section without any preceding DOT assignment or data command.
  a.o:.text
  # align to sh_addralign(a.o:.text.f)
  a.o:.text.f
  # align to sh_addralign(b.o:.text)
  b.o:.text
  # align to sh_addralign(b.o:.text.g)
  b.o:.text.g

Link script control A linker script can override thedefault alignment behavior. The ALIGN keyword enforces astricter alignment. For example .text : ALIGN(32) { ... }aligns the section to at least a 32-byte boundary. This is often done tooptimize for specific hardware or for memory mapping requirements.

The SUBALIGN keyword on an output section overrides theinput section alignments.

Padding: To achieve the required alignment, thelinker may insert padding between sections or before the first inputsection (if there is a gap after the output section start). The fillvalue is determined by the following rules:

• If specified, use the =fillexpoutput section attribute (within an output sectiondescription).
• If a non-code section, use zero.
• Otherwise, use a trap or no-op instructin.

Padding and sectionreordering

Linkers typically preserve the order of input sections from objectfiles. To minimize the padding required between sections, linker scriptscan use a SORT_BY_ALIGNMENT keyword to arrange inputsections in descending order of their alignment requirements. Similarly,GNU ld supports --sort-commonto sort COMMON symbols by decreasing alignment.

While this sorting can reduce wasted space, modern linking strategiesoften prioritize other factors, such as cache locality (for performance)and data similarity (for Lempel–Ziv compression ratio), which canconflict with sorting by alignment. (Search--bp-compression-sort= on Explain GNU stylelinker options).

ABI compliance

Some platforms have special rules. For example,

• On SystemZ, the larl (load address relative long)instruction cannot generate odd addresses. To prevent GOT indirection,compilers ensure that symbols are at least aligned by 2. (Toolchainnotes on z/Architecture)
• On AIX, the default alignment mode is power: for doubleand long double, the first member of this data type is aligned accordingto its natural alignment value; subsequent members of the aggregate arealigned on 4-byte boundaries. (https://reviews.llvm.org/D79719)
• z/OS caps the maximum alignment of static storage variables to 16.(https://reviews.llvm.org/D98864)

The standard representation of the the Itanium C++ ABI requiresmember function pointers to be even, to distinguish between virtual andnon-virtual functions.

In the standard representation, a member function pointer for avirtual function is represented with ptr set to 1 plus the function'sv-table entry offset (in bytes), converted to a function pointer as ifbyreinterpret_cast<fnptr_t>(uintfnptr_t(1 + offset)),where uintfnptr_t is an unsigned integer of the same sizeas fnptr_t.

Conceptually, a pointer to member function is a tuple:

• A function pointer or virtual table index, discriminated by theleast significant bit
• A displacement to apply to the this pointer

Due to the least significant bit discriminator, members function needa stricter alignment even if __attribute__((aligned(1))) isspecified:

1

virtual void bar1() __attribute__((aligned(1)));

Side note: check out MSVC C++ ABI MemberFunction Pointers for a comparison with the MSVC C++ ABI.

Architecture considerations

Contemporary architectures generally support unaligned memory access,likely with very small performance penalties. However, someimplementations might restrict or penalize unaligned accesses heavily,or require specific handling. Even on architectures supporting unalignedaccess, atomic operations might still require alignment.

• On AArch64, a bit in the system control registersctlr_el1 enables alignment check.
• On x86, if the AM bit is set in the CR0 register and the AC bit isset in the EFLAGS register, alignment checking of user-mode dataaccessing is enabled.

Linux's RISC-V port supportsprctl(PR_SET_UNALIGN, PR_UNALIGN_SIGBUS); to enable strictalignment.

clang -fsanitize=alignment can detect misaligned memoryaccess. Check out my write-up.

In 1989, US Patent 4814976, which covers "RISC computer withunaligned reference handling and method for the same" (4 instructions:lwl, lwr, swl, and swr), was granted to MIPS Computer Systems Inc. Itcaused a barrier for other RISC processors, see The Lexra Story.

Almost every microprocessor in the world can emulate thefunctionality of unaligned loads and stores in software. MIPSTechnologies did not invent that. By any reasonable interpretation ofthe MIPS Technologies' patent, Lexra did not infringe. In mid-2001 Lexrareceived a ruling from the USPTO that all claims in the the lawsuit wereinvalid because of prior art in an IBM CISC patent. However, MIPSTechnologies appealed the USPTO ruling in Federal court, adding toLexra's legal costs and hurting its sales. That forced Lexra into anunfavorable settlement. The patent expired on December 23, 2006 at whichpoint it became legal for anybody to implement the complete MIPS-Iinstruction set, including unaligned loads and stores.

Aligning code forperformance

GCC offers a family of performance-tuning options named-falign-*, that instruct the compiler to align certain codesegments to specific memory boundaries. These options might improveperformance by preventing certain instructions from crossing cache lineboundaries (or instruction fetch boundaries), which can otherwise causean extra cache miss.

• -falign-function=n: Align functions.
• -falign-labels=n: Align branch targets.
• -falign-jumps=n: Align branch targets, for branchtargets where the targets can only be reached by jumping.
• -falign-loops=n: Align the beginning of loops.

Important considerations

Inefficiency with Small Functions: Aligning smallfunctions can be inefficient and may not be worth the overhead. Toaddress this, GCC introduced -flimit-function-alignment in2016. The option sets .p2align directive's max-skip operandto the estiminated function size minus one.

1
2
3
4

% echo 'int add1(int a){return a+1;}' | gcc -O2 -S -fcf-protection=none -xc - -o - -falign-functions=16 | grep p2align
        .p2align 4
% echo 'int add1(int a){return a+1;}' | gcc -O2 -S -fcf-protection=none -xc - -o - -falign-functions=16 -flimit-function-alignment | p2align
        .p2align 4,,3

The max-skip operand, if present, is evaluated at parse time, so youcannot do:

1
2
3
4

.p2align 4, , b-a
a:
  nop
b:

In LLVM, the x86 backend does not implementTargetInstrInfo::getInstSizeInBytes, making it challengingto implement -flimit-function-alignment.

Cold code: These options don't apply to coldfunctions. To ensure that cold functions are also aligned, use-fmin-function-alignment=n instead.

Benchmarking: Aligning functions can make benchmarksmore reliable. For example, on x86-64, a hot function less than 32 bytesmight be placed in a way that uses one or two cache lines (determined byfunction_addr % cache_line_size), making benchmark resultsnoisy. Using -falign-functions=32 can ensure the functionalways occupies a single cache line, leading to more consistentperformance measurements.

LLVM notes: In clang/lib/CodeGen/CodeGenModule.cpp,-falign-function=N sets the alignment if a function doesnot have the gnu::aligned attribute.

A hardware loop typically consistants of 3 parts:

A low-overhead loop (also called a zero-overhead loop) is ahardware-assisted looping mechanism found in many processorarchitectures, particularly digital signal processors (DSPs). Theprocessor includes dedicated registers that store the loop startaddress, loop end address, and loop count. A hardware loop typicallyconsists of three components:

• Loop setup instruction: Sets the loop end address and iterationcount
• Loop body: Contains the actual instructions to be repeated
• Loop end instruction: Jumps back to the loop body if furtheriterations are required

Here is an example from Arm v8.1-M low-overhead branch extension.

1
2
3
4
5

1:
  dls lr, Rn    // Setup loop with count in Rn
  ...           // Loop body instructions
2:
  le lr, 1b     // Loop end - branch back to label 1 if needed

To minimize the number of cache lines used by the loop body, ideallythe loop body (the instruction immediately following DLS) should bealigned to a 64-byte boundary. However, GNU Assembler lacks a directiveto specify alignment like "align DLS to a multiple of 64 plus 60 bytes."Inserting an alignment after the DLS is counterproductive, as it wouldintroduce unwanted NOP instructions at the beginning of the loop body,negating the performance benefits of the low-overhead loopmechanism.

It would be desirable to simulate the functionality with.org ((.+4+63) & -64) - 4 // ensure that .+4 is aligned to 64-byte boundary,but this complex expression involves bitwise AND and is not arelocatable expression. LLVM integrated assembler would reportexpected absolute expression while GNU Assembler has asimilar error.

A potential solution would be to extend the alignment directives withan optional offset parameter:

1
2
3
4
5

# Align to 64-byte boundary with 60-byte offset, using NOP padding in code sections
.balign 64, , , 60

# Same alignment with offset, but skip at most 16 bytes of padding
.balign 64, , 16, 60

Xtensa's LOOP instructions has similar alignmentrequirement, but I am not familiar with the detail. The GNU Assembleruses the special alignment as a special machine-dependent fragment. (https://sourceware.org/binutils/docs/as/Xtensa-Automatic-Alignment.html)

老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

新手推荐

🐎 High Level Anatomy of a Camera Capturing Session

@AidenRao：这边文章用比较简单易懂的话，介绍苹果的相机从拍摄到 Swift 中展示的完整流程。文章不长，比较适合做个相机原理了解。

文章

🌟 🐕 从 DisplayList 到 Transaction: SwiftUI 调试实战

@Kyle-Ye: 文章介绍了如何通过 SwiftUI 中的相关环境变量，使用 DisplayList 输出分析视图渲染问题，通过符号断点和汇编调试深入分析 SwiftUI 内部机制，并使用 AttributeGraph 等调试工具进行问题定位。

🐕 Faster Equatable and Hashable conformances with Identifiable

@Smallfly：这篇文章聚焦 Swift 中 Equatable 与 Hashable 协议的性能优化，揭示了编译器自动合成实现的潜在瓶颈，并提出结合 Identifiable 协议的改进方案。核心内容包括：

• 问题分析：默认合成的 Equatable/Hashable 会逐成员比较或哈希，对含大集合（如 [User]）或嵌套结构的类型，复杂度达 O(N)，在 SwiftUI 视图更新、Set 操作中易成性能瓶颈。
• 优化方案：利用 Identifiable 的 id 属性（如 UUID），仅基于唯一标识实现 Equatable 和 Hashable，将操作复杂度降至 O(1)。
• 数据验证：基准测试显示，含 1000+ 员工的 Company 类型，Identifiable 方案的 Equatable 快 3 倍，Hashable 快 3 万倍。

文章结合编译器源码与 SwiftUI 实践，为性能敏感场景提供了可落地的优化思路。

🐢 What's New in UIKit

@Barney：这篇文章详细总结了 iOS 26 中 UIKit 的全面更新。尽管 UIKit 不再是 WWDC 的主角，但今年仍获得了大量新特性。
主要更新概况：
• Liquid Glass 设计语言：新增 UIGlassEffect、UIButton.Configuration 的玻璃按钮样式，以及 UIBarButtonItem 的共享背景支持
• 导航栏增强：UINavigationItem 新增 subtitle、largeTitle、attributedTitle 等属性，支持更丰富的标题展示
• 分割视图改进：UISplitViewController 支持新的 inspector 列，提供类似 macOS 的检查器面板
• 标签栏配件：UITabAccessory 允许在标签栏上方添加浮动工具栏，支持折叠展开动画
• HDR 色彩支持：UIColor 新增 HDR 初始化方法，UIColorPickerViewController 支持曝光调节
• 角落配置 API：UICornerConfiguration 提供统一的圆角设置方案，支持容器同心圆角
• 自然文本选择：UITextView 支持混合左右文字的自然选择，selectedRanges 替代 selectedRange
• 主菜单系统：UIMainMenuSystem 为 iPadOS 提供 macOS 风格的菜单栏
• 观察者模式集成：UIView 和 UIViewController 原生支持 Swift Observation 框架
• 滑块增强：UISlider 新增刻度配置和无拖柄样式
整体而言，iOS 26 的 UIKit 更新聚焦于视觉现代化、跨平台一致性和开发便利性的提升。

🐕 SwiftUI for Mac 2025

@Cooper Chen：这篇文章总结了 SwiftUI 在 macOS 26 上的多项改进，主要亮点包括：

• 统一图标格式：Xcode 26 新增 Icon Composer，可用 SVG 分层生成跨平台图标，并向下兼容旧系统。
• Liquid Glass 风格：按钮、滑块、切换等控件拥有玻璃质感与动态反馈，UI 更现代。
• 原生 WebView：SwiftUI 首次内置 WebView，无需桥接即可加载网页并追踪导航事件。
• 列表性能优化：List 在处理上万条数据时依然流畅，适合大数据量展示。

整体来看，SwiftUI 在 Mac 上的易用性与表现力进一步提升，对想要打造现代化界面的开发者非常有参考价值。

🐎 Git 2.51 support push/pull stash

@david-clang：过去 git stash 难以在不同机器之间迁移，Git 在 8 月 18 日发布的 2.51.0 版本支持 push/pull stash，实现跨机器共享 stash。但要在 GUI 工具上应用该特性，还要再等等，目前 Fork 支持的 Git 版本是 2.45.2。

内推

重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

What's Changed

• fix #5107 by @BarneyZhaoooo in #5117

Full Changelog: #347...#348

滤镜最早应用在电视影视业，对剧和电影作品后期进行调色效果。如今拍照、修图都离不开滤镜效果。我们在微博、朋友圈、电视、影院里看到的照片视频，无一没有滤镜的效果，滤镜已经深入我们生活的方方面面。

这里浅略地揭秘一下当前图像处理中滤镜底层的原理。

RGB颜色

RGB色彩模式是工业界的一种颜色标准，是通过对红®、绿(G)、蓝(B)三个颜色通道的变化以及它们相互之间的叠加来得到各式各样的颜色的，RGB即是代表红、绿、蓝三个通道的颜色，这个标准几乎包括了人类视力所能感知的所有颜色，是运用最广的颜色系统之一。

对于一张图片的每一个像素，都可以由唯一的颜色（R，G，B）表示，其中RGB的范围是0~255。0代表最暗，255代表最亮。

颜色查找表

滤镜的本质就是颜色的变换。我们可以把一个像素的颜色（R，G，B）看成是一个三维空间上的一个坐标点。颜色变换相当于是三维空间的 [一个坐标点] 到 [另一个坐标点] 的映射关系。也就是：

1
2
3
4
5
6
7
8
9
10
11
12

         （old R，old G，old B）  --->   （new R，new G，new B）

例如：

        （23，77，134）  --->      （122，34，255）

        （189，65，138）  --->      （5，65，21）

        （0，0，2）  --->      （33，0，1）

                ………………

即每一个（R，G，B）都有一个一一对应的目标颜色，那么一个完整的RGB颜色查找表总共有 256×256×256 = 2^24 条。

显然 2^24 这个数字有点太大了，存储它需要至少16Mb的空间，加载到内存也至少需要吃掉16Mb的内存
（问题1：这里可以先思考一下为什么是16Mb？后面会给出解释）

因此我们在实际查找表应用中一般使用 64×64×64 的查找表，RGB每个通道都将 [连续的4个坐标] 映射成 [1个目标坐标]

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

（0，X，X）    --->   （34，X，X）

（1，X，X）    --->   （34，X，X）

（2，X，X）    --->   （34，X，X）

（3，X，X）    --->   （34，X，X）


（4，X，X）    --->   （128，X，X）

（5，X，X）    --->   （128，X，X）

（6，X，X）    --->   （128，X，X）

（7，X，X）    --->   （128，X，X）

但显然这样会导致原始图片颜色精度的丢失（例如上面的0~3的亮度映射后都变成了无差别的34），那么就需要想办法降低这种精度丢失的问题
（问题2：这里可以先思考一下有哪些补偿精度的方法？后面会给出解答）

LUT图

有了颜色映射表，接下来需要考虑如何去表达这些映射关系了。有一个笨办法是用文本去存储这 64×64×64 这么多条 （old R，old G，old B） —> （new R，new G，new B）这样的映射关系。聪明的你肯定意识到了这个文本的大小会是一个天文数字。那么有没有更好的表达方法呢？优秀的前辈们发现可以用一个图片去表示这个映射关系，这就是LUT图：

这个LUT图的尺寸是 512×512 ，正好等于 64×64×64（查找表的数量），也就是刚好每一个像素可以表示一条 （old R，old G，old B） —> （new R，new G，new B）这样的映射关系！

我们可以用 [图片的像素坐标] 表示（old R，old G，old B），用这个坐标所在的 [像素的颜色] 表示（new R，new G，new B），这样就实现了映射表的一一对应关系。

我们可以先从比较简单的开始看，为什么用这个坐标所在的 [像素的颜色] 表示（new R，new G，new B）？因为图片本身每个像素就是由（R，G，B）组成，并且都是0~255，刚好可以完美表示一个（new R，new G，new B）。

再来看看比较复杂一丁点的，如何用 [图片的像素坐标] 表示（old R，old G，old B）？因为一个图片的坐标是二维坐标（x，y），要如何表示一个三维的（old R，old G，old B）呢？

可以看到这个图片每一行有8个小正方形，每一列也有8个小正方形，总共有64个小正方形。每个小正方形都是一张 64×64的图片。

我们先从一个小正方形开始看。其实每一个小正方形都代表了完整的（old R，old G） —> （new R，new G）的映射。其中像素Target坐标（x，y）代表（old R，old G），像素Target的颜色的RG值就代表（new R，new G）。

例如下面这张图片：

1.假设（old R，old G） = （100，150），那么Target的坐标就是（100 / 4，150 / 4）= （25，37）

2.如果这个图片里坐标是（25，37）的Target的像素值是（213， 88），那么（new R，new G）=（213， 88）

2.即完成了（old R，old G） = （100，150） —> （new R，new G）=（213， 88） 的映射关系！

至此已经完成了R通道和G通道的映射，那么如何确定B通道的映射关系呢？前面说到一个完整LUT图有8×8=64个小正方形，这64个小正方形就是用来确定B通道的映射关系的。

我们把这64个小正方形按从左到右从上到下排列，编号0~63，我们就可以把（old B）映射到其中的某个小正方形格子。

拿下面这个示例图比较能说明过程：

假如（old B） = （50），那么最终的颜色落在第（50 / 4）=（12）个格子上。

但注意，这里的（12）并不是（new B），（12）仍然只是图片的 [坐标]，因此它代表的其实还是（old B），仅仅 / 4 了而已。

我们回到上面一步的步骤，确定了在是哪个小正方形，就可以在这个小正方形里根据（old R，old G）确定最终的Target。那么（new B）就等于 像素Target颜色的B值！

聪明的你也许已经意识到了，在这64个小正方形里，每个小正方形相同（x，y）坐标所对应Target像素颜色的（R，G）都是一样的，仅仅只有B不一样。这也就是为什么B颜色最终是根据计算 [在哪个小正方形里] 来确定的。

我们再来完整走一遍LUT图颜色映射的全过程。

1.假如一个像素点原始的颜色是 （old R，old G，old B）=（38，201，88）

2.根据（old B）确定在哪个小正方形：88 / 4 = 22

3.在第22个小正方形里，根据（old R，old G）确定最终Target的坐标：（38 / 4，201 / 4）=（9，50）

4.假如第22个小正方形中，（9，50）所对应的Target像素的颜色是（50，3，126）

5.那么最终的颜色（new R，new G，new B）=（50，3，126），至此完成一个像素点颜色的映射。

6.遍历原始图片的每一个像素，都走一遍1~5的过程，完成对整张图片的滤镜效果。

这里先解答一下上面 [问题1] 和 [问题2] 的解答：

问题1：为什么是16Mb？

因为映射关系都用LUT图表示，每个像素代表一条映射，那么64×64×64 = 2^18，一张 2^18 个像素的无损图片（一般是.png）大小至少是256Kb，而 256×256×256 = 2^24 个像素的无损图片大小至少是16Mb。

问题2：有哪些补偿精度的方法？

注意到上面精度的丢失是因为像素颜色从 256 –> 64，我们上面在做除法的时候丢失了小数点，例如（38 / 4，201 / 4）=（9，50），但其实应该是（38 / 4，201 / 4）=（9.5，50.25），在实际运用的时候我们并不会抛弃小数点。

在计算的时候，如果计算得到的坐标不是位于一个像素的正中心，那么在取色时，会对相邻的几个像素进行加权平均，更靠近的像素权重越大。直观地说就是，理谁越靠近，那么谁就对最终的颜色有更重要的影响。

例如下面这个图，在最终确定颜色时，会考虑相邻的4个像素点的颜色。这就是双线性插值法，除此之外也有单线性插值法，有兴趣的朋友欢迎交流。

双线性插值法示意图：

如何制作一个LUT图？

1.打开Photoshop，打开一个你想调色的图片

2.通过各种调节，达到你所期待的颜色

3.载入一张原始LUT图

什么是原始LUT图：就是经过这个LUT颜色变化之后，还是原来的颜色，也就是 [什么颜色都不变]

它的映射关系：

1
2
3
4
5
6
7
8
9
10

（0，0，0） ---> （0，0，0）

（0，0，1） ---> （0，0，1）

        ………………

（254，255，255） ---> （254，255，255）

（255，255，255） ---> （255，255，255）

4.对这张LUT图也应用上对刚才图片的调色效果

至此一张LUT滤镜图就做好了：

怎么理解这个过程？

我的理解是，我们对图片进行 [调色的一系列操作]，再 [作用在原始LUT图上]，就相当于让这张原始LUT图记录下了 [这一系列操作]，记下来之后就可以拿去对任意的图片进行滤镜效果了。

最后附一个效果图

原文地址

据不完全统计，全世界每隔3秒就有一个人上传自己的自拍照，甚至不少人在P图上所花的时间都超过了化妆时间。

从十多年前“美图秀秀”的横空出世，再到近年来的实时美颜。到今天，美颜功能已经嵌入到各类手机系统当中，帮助大家实现完美自拍。有玩笑说，中国的P图术、韩国的整容术和日本的化妆术瓜三分天下。此秘术自诞生以来教众不断，但受用者，可瞬间变成天仙下凡，号称“传说中的3大东方神秘力量”。由此可见，随着朋友圈、微博等自拍社交越来越盛行，拍个美美的照片已经是人们的刚需了。

其实磨皮算法最底层的本质就是一种降噪算法，也可以说是模糊算法。即通过对脸部的模糊，把各种面部瑕疵模糊掉，以达到磨皮的效果。

本文很简单地介绍几种很基础的模糊算法以及磨皮后的边缘和细节还原。

一、磨皮核心——模糊算法

模糊算法也可以说是降噪算法，把清晰可见的东西变得模糊。磨皮的原理就是把脸部变“模糊”，把各种瑕疵、皱纹、痘印等变模糊，使得整个脸看起来很光滑平整。模糊算法就是这样，可以隐去很多细节，也可以说是可以用更少的图像信息量去表达一幅图，因此许多细节就在模糊的过程中被抹去。

如何使一张图片变模糊呢，我们不妨从微观看起。

我们来看一张3*3的图：

假设上面的数字都代表当前位置的像素值。

假如正中央的像素”9”代表一个瑕疵点，那么我们如何把这个”9”模糊掉呢？

1.中值滤波

对核心及周围的像素值排序，取中间值作为新的像素值。

2.均值滤波

将核心及周围的像素求和取平均值，作为新的像素值。

3.高斯滤波

在均值滤波的基础上，对每个像素加上一个权重。这个权重是一个高斯函数。概况地说，距离中心点越近，权重越大；距离中心点越远，权重越小。

一维高斯函数可以这样表示：

下图分别是一维高斯图像和二维高斯图像：

把二维高斯函数放到我们上面的3*3的区域中，并做归一化，就得到了权重：

那么最终的颜色这样计算：

4.双边滤波

在高斯滤波的基础上，再加上一个[像素差异]的权重：与中心颜色相差越大，权重越低；与中心颜色相差越小，权重越高。

这么做是为了能够在模糊的时候，较好地保护图像的边缘细节信息。这也是磨皮常用的模糊算法，因为磨皮就是需要保留人脸的一些纹路边缘细节，使得磨皮效果看起来更加自然。

可以这么理解：

高斯核是[空间域]上的权重：距离中心的空间距离越远，权重越小。

双边滤波多了一个[值域]上的权重：距离中心的像素差别越大，权重越小。

以下两个图片可以更好理解双边滤波：


还是拿上面3*3的区域应该这样算：

这里的值域核仅为了表达方便，实际应用中也需要做类似归一化的操作

我们可以看一下这几种模糊算法的效果：

原图：

中值滤波：

均值滤波：

高斯滤波：

双边滤波：

二、锐化——边缘和细节还原

锐化可以分成2步：第一步，提取边缘；第二步：边缘还原到原图上。第二步其实就是简单的把边缘图叠加到原图上，因此这里重点介绍边缘提取算法。

1.USM锐化

USM锐化是最常见的锐化，其主要利用了模糊图，原理如下：

上文说过的模糊算法其实就是把大部分细节抹去，用原图减去模糊图，就得到了这幅图像的边缘和细节了。得到细节之后，叠加回原图，就实现了锐化的效果。

如果想要更大的锐化怎么办呢？那就使用更模糊的图，以得到更大的差值：

2.拉普拉斯Laplace锐化

拉普拉斯锐化方式是通过对像素进行卷积遍历，以得到边缘。

以4领域卷积核为例：

如果当前像素与上下左右4个像素完全相同，那么计算得的结果为0，即代表当前像素并不是边缘；

反之如果计算结果不为0，说明当前像素与上下左右像素值存在差异，那么这个像素在一定程度上是边缘的一部分。

拉普拉斯锐化效果如下：

3.索贝尔sobel锐化

sobel锐化也是使用对像素的卷积遍历，不同的是它区分横纵卷积核。

以横向卷积核为例：

如果左边一列和右边一列像素完全相同，那么计算得的结果为0，即代表当前像素并不是边缘；

如果左边一列和右边一列像素值有所差别，那么计算结果不为0，代表当前像素正处在边缘部分。

sobel边缘提取效果如下：

效果图：

这个月我开了个新项目：制作 deep future 的电子版。

之所以做这个事情，是因为我真的很喜欢这个游戏。而过去一年我在构思一个独立游戏的玩法时好像进入了死胡同，我需要一些设计灵感，又需要写点代码保持一下开发状态。思来想去，我确定制作一个成熟桌游的电子版是一个不错的练习。而且这个游戏的单人玩法很接近电子游戏中的 4x 类型，那也是我喜欢的，等还原了原版桌游规则后，我应该可以以此为基础创造一些适合电子游戏特性的东西来。

另一方面，我自以为了解游戏软件从屏幕上每个像素点到最终游戏的技术原理，大部分的过程都亲身实践过。但我总感觉上层的东西，尤其是游戏玩法、交互等部分开发起来没有底层（尤其是引擎部分）顺畅。我也看到很多实际游戏项目的开发周期远大于预期，似乎开发时间被投进了黑洞。

在 GameJam 上两个晚上可以做出的游戏原型，往往又需要花掉 2,3 年时间磨练成成品。我想弄清楚到底遇到了怎样的困难，那些不明不白消耗掉的开发时间到底去了哪里。

这次我选择使用前几个月开发的 soluna 作为引擎。不使用前些年开发的 Ant Engine 的原因 在这个帖子里写得很清楚了。至于为什么不用现成的 unreal/unity/godot 等，原因是：

1. 我明白我要做什么事，该怎么做，并不需要在黑盒引擎的基础上开发。是的，虽然很多流行引擎有源码，但在没有彻底阅读之前，我认为它们对我的大脑还是黑盒。而阅读理解这些引擎代码工程巨大。

2. 我的项目不赶时间，可以慢慢来。我享受开发过程，希望通过开发明白多一些道理，而不是要一个结果。我希望找到答案，可能可以通过使用成熟引擎，了解它们是怎样设计的来获得；但自己做一次会更接近。

3. 自己从更底层开发可以快速迭代：如果一个设计模式不合适，可以修改引擎尝试另一个模式。而不是去追寻某个通用引擎的最佳实践。

4. 我会使用很多成熟的开源模块和方案。但通常都是我已经做过类似的工作，期望可以和那些成熟模块的作者/社区共建。

5. 这个项目几乎没有性能压力。我可以更有弹性的尝试不同的玩法。成熟引擎通常为了提升某些方面的性能，花去大量的资源做优化，并做了许多妥协。这些工作几乎是不可见的。也就是说，如果使用成熟引擎开发，能利用到的部分只是九牛一毛，反而需要花大量精力去学习如何用好它们；而针对具体需求自己开发，花掉的精力反而更有限，执行过程也更为有趣。

这篇 blog 主要想记录一下这大半个月以来，我是怎样迭代引擎和游戏的。我不想讨论下面列举出来的需求的最佳方案，现在已经完成的代码肯定不是，之后大概率也会再迭代掉。我这个月的代码中一直存在这样那样的“临时方案”、“全局状态”、甚至一些复制粘贴。它们可能在下一周就重构掉，也可能到游戏成型也放在那里。

重要的是过程应该被记录下来。

在一开始，我认为以立即模式编写游戏最容易，它最符合人的直觉：即游戏是由一帧帧画面构成的，只需要组帧绘制需要的画面就可以了。立即模式可以减少状态管理的复杂度。这一帧绘制一个精灵，它就出现在屏幕上；不绘制就消失了。

大部分成熟引擎提供的则是保留模式：引擎维护着一组对象集合，使用者创建或删除对象，修改这些对象的视觉属性。这意味着开发者需要做额外的很多状态管理。如果引擎维持的对象集合并非平坦结构，而是树状容器结构，这些状态管理就更复杂了。

之所以引擎喜欢提供保留模式大概是因为这样可以让实现更高效。而且在上层通过恰当的封装，立即模式和保留模式之间也是可以互相转换的。所以开发者并不介意这点：爱用立即模式开发游戏的人做一个浅封装层就可以了。

但我一开始就选择立即模式、又不需要考虑性能的话，一个只对图形 api 做浅封装的引擎直接提供立即模式最为简单。所以一开始，soluna 只提供了把一张图片和一个单独文字显示在屏幕特定位置的 api 。当然，使用现代图形 api ，给绘制指令加上 SRT 变换是举手之劳。（在 30 年前，只有一个 framebuffer 的年代，我还需要用汇编编写大量关于旋转缩放的代码）

在第一天，我从网上找来了几张卡牌的图片，只花了 10 分钟就做好了带动画和非常简单交互的 demo 。看起来还很丝滑，这给我不错的愉悦感，我觉得是个好的开始。

想想小丑牌也是用 Love2D 这种只提供基本 2d 图片渲染 api 的引擎编写出来的，想来这些也够用了。当然，据说小丑牌做了三年。除去游戏设计方面的迭代时间外，想想程序部分怎么也不需要这么长时间，除非里面有某些我察觉不到的困难。

接下来，我考虑搭一些简单的交互界面以及绘制正式的卡牌。

Deep future 的卡牌和一般的卡牌游戏还不一样。它没有什么图形元素，但牌面有很多文字版面设计。固然，我可以在制图设计软件里定下这些版面的位置，然后找个美术帮我填上，如果我的团队有美术的话……这是过去在商业公司的常规做法吧？可是现在我一个人，没有团队。这是一件好事，可以让我重新思考这个任务：我需要减少这件我不擅长的事情的难度。我肯定会大量修改牌面的设计，我得有合适我自己的工作流。

在 Ant 中，我们曾经集成过 RmlUI ：它可以用 css 设计界面。css 做排版倒是不错，虽然我也不那么熟悉，但似乎可以完成所有需求。但我不喜欢写 xml ，也不喜欢 css 的语法，以及很多我用不到的东西。所以，我决定保留核心：我需要一个成熟的排版用的结构化描述方案，但不需要它的外表。

所以我集成了 Yoga ，使用 Lua 和我自己设计的 datalist 语言来描述这个版面设计。如果有一天，我想把这个方案推广给其他人用，它的内在结构和 css 是一致的，写一个转换脚本也非常容易。

暂时我并不需要和 Windows 桌面一样复杂的界面功能。大致上有单个固定的界面元素布局作为 HUD （也就是主界面）就够了。当然，用 flexbox 的结构来写，自动适应了不同的分辨率。采用这种类 CSS 的排版方案，实际上又回到了保留模式：在系统中保留一系列的需要排版布局的对象。

当我反思这个问题时，我认为是这样的：如果一个整体大体是不变的，那么把这个整体看作黑盒，其状态管理被封装在内部。使用复杂度并没有提高。这里的整体就是 HUD 。考虑到游戏中分为固定的界面元素和若干可交互的卡片对象，作为卡牌游戏，那些卡牌放在 HUD 中的容器内的。如果还是用同样的方案管理卡片的细节，甚至卡片本身的构图（它也是由更细分的元素构成的）。以保留模式整个管理就又变复杂了。

所以，我在 yoga 的 api 封装层上又做了一层封装。把界面元素分为两类：不变的图片和文字部分，和需要和玩家交互的容器。容器只是由 yoga 排版的一个区域，它用 callback 的形式和开发者互动就可以了。yoga 库做的事情是：按层次结构遍历处理完整个 DOM ，把所有元素平坦成一个序列，每个元素都还原成绝对坐标和尺寸，去掉层次信息，只按序列次序保留绘制的上下层关系。在这个序列中，固定的图片和文字可以直接绘制，而遇到互动区，则调用用户提供的函数。这些函数还是以立即模式使用：每帧都调用图形 API 渲染任意内容。

用下来还是挺舒服的。虽然 callback 的形式我觉得有点芥蒂，但在没找到更好的方式前先这么用着，似乎也没踩到什么坑。

渲染模块中，一开始只提供了文字和图片的渲染。但我留出了扩展材质的余地。文字本身就是一种扩展材质，而图片是默认的基础材质。做到 UI 时，我发现增加一种新的材质“单色矩形”特别有用。

因为我可以在提供给 yoga 的布局数据中对一些 box 标注，让它们呈现出不同颜色。这可以极大的方便我调试布局。尤其是我对 flexbox 布局还不太熟练的阶段，比脑补布局结果好用得多。

另一个有用的材质是对一张图片进行单色渲染，即只保留图片的 alpha 通道，而使用单一颜色。这种 mask 可以用来生成精灵的阴影，也可以对不规则图片做简单遮罩。

在扩展材质的过程中，发现了之前预留的多材质结构有一些考虑不周全的设计，一并做了修改。

到绘制卡牌时，卡牌本身也有一个 DOM ，它本质上和 HUD 的数据结构没什么区别，所以这个数据结构还是嵌套了。一开始，我在 soluna 里只提供了平坦的绘制 api ，并没有层次管理。一开始我做的假设是：这样应该够用。显然需要打破这个假设了。

我给出的解决方案是：在立即模式下，没必要提供场景树管理，但可以给一个分层堆栈。比如将当前的图层做 SRT 变换，随后的绘图指令都会应用这套变换，直到关闭这个图层（弹出堆栈）。这样，我想移动甚至旋转缩放 HUD 中的一个区域，对于这个区域的绘制指令序列来说都是透明的：只需要在开始打开一个新图层，结束时关闭这个图层即可。

另一个需求是图文混排，和文字排版。一开始我假设引擎只提供单一文字渲染的功能就够用，显然是不成立的。Yoga 也只提供 box 的排版，如果把每个单字都作为一个 box 送去 yoga 也不是不行，但直觉告诉我这不但低效，还会增加使用负担。web 上也不是针对每个单字做排版的。用 Lua 在上层做图片和文字排版也可以，但对性能来说太奢侈了。

这是一个非常固定的需求：把一块有不同颜色和尺寸的文字放在一个 box 中排版，中间会插入少许图片。过去我也设计过不少富文本描述方案，再做一次也不难。这次我选择一半在 C 中实现，一半在 Lua 中实现。C 中的数据结构利于程序解析，但书写起来略微繁琐；Lua 部分承担易于人书写的格式到底层富文本结构的转换。Lua 部分并不需要高频运行，可以很方便的 cache 结果（这是 Lua 所擅长的），所以性能不是问题。

至于插入的少许图片，我认为把图片转换为类似表情字体更简单。我顺手在底层增加了对应的支持：用户可以把图片在运行时导入字体模块。这些图片作为单独的字体存在，codepoint 可以和 unicode 重叠。并不需要以 unicode 在文本串中编码这些图片，而将编码方式加入上述富文本的结构。

在绘制文本的环节，我同时想到了本地化模块该如何设计。这并非对需求的未雨绸缪，而是我这些年来一直在维护群星的汉化 mod 。非常青睐 Paradox 的文本方案。这不仅仅是本地化问题，还涉及游戏中的文本如何拼接。尤其是卡牌游戏，关于规则描述的句子并非 RPG 中那样的整句，而是有很多子句根据上下文拼接而来的。

拼句子和本地化其实是同一个问题：不同语言间的语法不同，会导致加入一些上下文的句子结构不同。P 社在这方面下了不少功夫，也经过了多年的迭代。我一直想做一套类似的系统，想必很有意思。这次了了心愿。

我认为代码中不应该直接编码任何会显示出来的文本，而应该统一使用点分割的 ascii 字串。这些字串在本地化模块那里做第一次查表转换。

有很大一部分句子是由子句构成的，因为分成子句和更细分的语素可以大大降低翻译成不同语言的工作量。这和代码中避免复制粘贴的道理是一样的：如果游戏中有一个术语出现在不同语境下，这个术语在本地化文本中只出现在唯一地方肯定最好。所以，对于文本来说，肯定是大量的交叉引用。我使用 $(key.sub.foobar) 的方式来描述这种交叉引用。注：这相当于 P 社语法中的 $key.sub.foobar$ 。我对这种分不清开闭的括号很不感冒。

另一种是对运行环境中输入的文本的引用：例如对象的名字、属性等。我使用了 ${key} 这样的语法，大致相当于 P 社的 [key] 。但我觉得统一使用 $ 前缀更好。至于图标颜色、字体等标注，在 P 社的语法中花样百出，我另可使用一致的语法：用 [] 转义。

这个文本拼接转换的模块迭代了好几次。因为我在使用中总能发现不完善的实现。估计后面还会再改动。好在有前人的经验，应该可以少走不少弯路吧。

和严肃的应用不同，游戏的交互是很活泼的。一开始我并没有打算实现元素的动画表现，因为先实现功能仿佛更重要。但做着做着，如果让画面更活泼一点似乎心情更愉悦一点。

比如发牌。当然可以直接把发好的牌画在屏幕指定区域。但我更希望有一个动态的发牌过程。这不仅仅是视觉感受，更能帮助不熟悉游戏规则的玩家尽快掌控卡牌的流向。对于 Deep Future 来说更是如此：有些牌摸出来是用来产生随机数的、有些看一眼就扔掉了、不同的牌会打在桌面不同的地方。如果缺少运动过程的表现，玩家熟悉玩法的门槛会高出不少。

但在游戏程序实现的逻辑和表现分离，我认为是一个更高原则，应尽可能遵守。这部分需要一点设计才好。为此，我并没有草率给出方案尽快试错，而是想了两天。当然，目前也不是确定方案，依旧在迭代。

css 中提供了一些关于动画的属性，我并没有照搬采用。暂时我只需要的运动轨迹，固然轨迹是对坐标这个属性的抽象，但一开始没必要做高层次的抽象。另外，我还需要保留对对象的直接控制，也就是围绕立即模式设计。所以我并没有太着急实现动画模块，而且结合另一个问题一起考虑。

游戏程序通常是一个状态机。尤其是规则复杂的卡牌游戏更是。在不同阶段，游戏中的对象遵循不同的规则互动。从上层游戏规则来看是一个状态机，从底层的动画表现来看也是，人机交互的界面部分亦然。

从教科书上搬出状态机的数据结构，来看怎么匹配这里的需求，容易走向歧途；所以我觉得应该先从基本需求入手，不去理会状态机的数据结构，先搭建一个可用的模块，再来改进。

Lua 有 first class 的 coroutine ，非常适合干这个：每个游戏状态是一个过程（相对一帧画面），有过程就有过程本身的上下文，天然适合用 coroutine 表示。而底层是基于帧的，显然就适合和游戏的过程分离开。

以发牌为例：在玩家行动阶段，需要从抽牌堆发 5 张牌到手牌中。最直接的做法是在逻辑上从牌堆取出 5 张牌，然后显示在手牌区。

我需要一个发牌的视觉表现，卡牌从抽牌堆移动到手牌区，让玩家明白这些牌是从哪里来的。同时玩家也可以自然注意到在主操作区（手牌区）之外还有一个可供交互的牌堆。

用立即模式驱动这个运动轨迹，对于单张牌来说最为简单。每帧计算牌的坐标，然后绘制它就可以了。但同时发多张牌就没那么直接了。

要么一开始就同时记录五张牌的目的地，每帧计算这五张牌的位置。这样其实是把五张牌视为整体；要么等第一张牌运动到位，然后开始发下一张牌。这样虽然比较符合现实，但作为电子游戏玩，交互又太啰嗦。

通常我们要的行为是：这五张牌连续发出，但又不是同时（同一帧）。牌的运动过程中，并非需要逐帧关注轨迹，而只需要关注开始、中途、抵达目的地三个状态。其轨迹可以一开始就确定。所以，卡牌的运动过程其实处于保留模式中，状态由系统保持（无需上层干涉），而启动的时机则交由开发者精确控制更好。至于中间状态及抵达目的地的时机，在这种对性能没太大要求的场景，以立即模式逐帧轮询应无大碍（必须采用 callback 模式）。

也就是，直观的书写回合开始的发牌流程是这样的：

for i = 1, 5 do
  draw_card() -- 发一张牌
  sleep(0.1)  -- 等待 0,1 秒
end

这段代码作为状态机逻辑的一部分天然适合放在单独的 coroutine 中。它可以和底层的界面交互以及图形渲染和并行处理。

而发牌过程，则应该是由三个步骤构成：1. 把牌设置于出发区域。2. 设定目的地，发起移动请求。3. 轮询牌是否运动到位，到位后将牌设置到目的地区域。

其中步骤 1,2 在 draw_card 函数中完成最为直观，因为它们会在同一帧完成。而步骤 3 的轮询应该放在上述循环的后续代码。采用轮询可以避免回调模式带来的难以管理的状态：同样符合直观感受，玩家需要等牌都发好了（通常在半秒之内）再做后续操作。

我以这样的模式开发了一个基于 coroutine 的简单状态机模块。用了几天觉得还挺舒适。只不过发现还是有一点点过度设计。一开始我预留了一些 api 供使用者临时切出当前状态，进入一个子状态（另一个 coroutine），完成后再返回；还有从一个过程中途跳出，不再返回等等。使用一段时间以后，发现这些功能是多余的。后续又简化掉一半。

至于动画模块，起初我认为一切都围绕卡牌来做就可以了。可以运动的基本元素就是不同的卡片。后来发现其实我还需要一些不同于卡片的对象。运动也不仅仅是位移，还包括旋转和缩放，以及颜色的渐变。

至于对象运动的起点和终点，都是针对的前面所述的“区域”这个概念。一开始“区域”只是一个回调函数；从这里开始它被重构成一个对象，有名字和更多的方法。“区域”也不再属于同一个界面对象，下面会谈到：我一开始的假设，所有界面元素在唯一 DOM 上，感觉是不够用的。我最终还是需要管理不同的 DOM ，但我依旧需要区域这个概念可以平坦化，这样可以简化对象可以在不同的 DOM 间运动的 API。

运动过程本身，藏在较低的层次。它是一个独立模块，本质上是以保留模式管理的。在运动管理模块中，保留的状态仅仅是时间轴。也就是逐帧驱动每个运动对象的时间轴（一个数字）。逐帧处理部分还是立即模式的，传入对象的起点和终点，通过时间进度立即计算出当前的状态，并渲染出来。

从状态管理的角度看，每帧的画面和动画管理其实并不是难题。和输入相关的交互管理更难一些，尤其是鼠标操作。对于键盘或手柄，可以使用比较直观的方式处理：每帧检查当下的输入内容和输入状态，根据它们做出反应即可。而鼠标操作天生就是事件驱动的，直到鼠标移动到特定位置，这个位置关联到一个可交互对象，鼠标的点击等操作才有了特别的含义。

ImGUI 用了一种立即模式的直观写法解决这个问题。从使用者角度看，它每帧轮询了所有可交互对象，在绘制这些对象的同时，也依次检查了这些对象是否有交互事件。我比较青睐这样的用法，但依然需要做一些改变。毕竟 ImGUI 模式不关注界面的外观布局，也不擅长处理运动的元素。

我单独实现了一个焦点管理模块。它内部以保留模式驱动界面模块的焦点响应。和渲染部分一样，处理焦点的 API 也使用了一些 callback 注入。这个模块仅管理哪个区域接收到了鼠标焦点，每个区域通过 callback 函数再以立即模式（轮询的方式）查询焦点落在区域内部的哪个对象上。

在使用层面，开发者依然用立即模式，通过轮询获取当前的鼠标焦点再哪个区域哪个对象上；并可查询当前帧在焦点对象上是否发生了交互事件（通常是点击）。这可以避免用 callback 方式接收交互事件，对于复杂的状态机，事件的 callback 要难管理的多。

一开始我认为，单一 HUD 控制所有界面元素就够了。只需要通过隐藏部分暂时不用的界面元素就可以实现不同游戏状态下不同的功能。在这个约束条件下，代码可以实现的非常简单。但这几天发现不太够用。比如，我希望用鼠标右键点击任何一处界面元素，都会对它的功能做一番解说。这个解说界面明显是可以和主界面分离的。我也有很大意愿把两块隔离开，可以分别独立开发测试。解说界面是帮助玩家理解游戏规则和交互的，和游戏的主流程关系不大。把它和游戏主流程放在一起增加了整体的管理难度。但分离又有悖于我希望尽可能将对象管理平坦化的初衷，我并不希望引入树状的对象层次结构。

最近的设计灵感和前面绘制模块的图层设计类似，我给界面也加入了图层的概念。永远只有一个操作层，但层次之间用栈管理。在每个状态看到的当下，界面的 DOM 都是唯一的。状态切换时则可以将界面压栈和出栈。如果后续不出现像桌面操作系统那样复杂的多窗口结构的话，我想这种栈结构分层的界面模式还可以继续用下去。

另一个变动是关于“区域”。之前我认为需要参与交互的界面元素仅有“区域”，“区域”以立即模式自理，逐帧渲染自身、轮询焦点状态处理焦点事件。最近发现，额外提供一种叫“按钮”的对象会更方便一些。“按钮”固然可以通过“区域”来实现，但实践中，处理“按钮”的不是“按钮”本身，而是容纳“按钮”的容器，通常也是最外层的游戏过程。给“按钮”加上类似 onclick 的 callback 是很不直观的；更直观的做法是在游戏过程中，根据对应的上下文，检查是否有关心的按钮被点击。

所有的按钮的交互管理可以放在一个平坦的集合中，给它们起上名字。查询时用 buttons.click() == "我关心的按钮名字" 做查询条件，比用 button_object.click() 做查询条件要舒服一点。

以上便是最近一个月的部分开发记录。虽然，代码依旧在不断修改，方案也无法确定，下个月可能还会推翻目前的想法。但我感觉找到了让自己舒适的节奏。

不需要太着急去尽快试错。每天动手之前多想想，少做一点，可以节省很多实作耗掉的精力；也不要过于执著于先想清楚再动手，毕竟把代码敲出带来的情绪价值也很大。虽然知道流畅的画面背后有不少草率的实现决定，但离可以玩的游戏更进一步的心理感受还是很愉悦的。

日拱一卒，功不唐捐。