Rachel 高考顺利。很久没看见你了，感谢一直关注本频道～（怎么感觉好像很稀奇订阅者一样，真是贪 star 太少成病了么……）

当知道要重写的代码分成 data/operation，而且不同的部分在不同的文件里，且解析器是高耦合的时候，我非常惊恐。

当知道要重写的代码没有严格面向对象，而是使用 singleton data storage + clear()，并且使用 subsequence 式解析数据提取法，我更慌了。

StringChunk 和 style 的 offset 计算方式扑朔迷离，令人窒息…… 原来 copyByte 的第一个参数是 offset，第二个是 size…… 我还以为是 index range 呢

我感觉我在一大堆 magic number 里尝试揣度这到底是要提取哪个位置的数据。
让自己觉得看懂这样的代码非常简单，但想理解很烧脑，尤其是我这种人在看 4, 8, ... 4??? 这些参数的时候。

我去，这注释位置也太离奇了吧！为什么不注释在下面呢？上面谁知道那个 8 是啥意思啊？

awsl

太难了！

这扑朔迷离的名词 stylePool，在是 int 的同时又是 byte[]

这个特化处理也太难了吧！我感觉我是在写 radare2 脚本。

我死了，今天肯定做不完的

但是，这里所认为的 AXML 文件基本结构，我们之前写的复用库里可全都包含在内呦。上面的例子就是经典的 Cond(flag, item), 这里 flag = int32

我最后考虑了一下，好像 Writer 还是必须支持 position 的…… Java 的 ByteArrayOutputStream 在内部就保留有…… 然后就可以有 aligned 这个 pattern

为了 Cond 的 flag 在一些极端情况下的可用性（比如 flag 的 index 是从 1000+ 开始编列的）
必须有一个 map 的 pattern helper，来把输出映射到特定值，再映射回来。

aligned 不应该作为一个 pattern 出现，因为它实在不好取类型，Nothing? 是错误的办法
但可以作为类似 EndianSwitch (PrePost) 的东西出现

特立独行的 pattern

#dev 汲取之前的教训，我再也不为了让测试通过而想当然地改代码了，至少在调试分析以后找出问题根本原因所在，才能算成功。

任何可能出错的地方都会出错……
当时我还检查了很多遍，自以为该 update 某变量的所有地方都检查了，看来好眼睛不如好实例代码、熟练的 IDE 分析工具使用，重点是难以抓住的，肯定要多测试。

结构和解析器，完全可以写在一起。

现在 Int16/Int32 vs. Short/Int 又成问题了，唉，项目里真的没办法完全统一啊

目前和二进制数据模式相关的基本是 Int8 式位长名字，无关的则是 Byte 这样的 kotlin 式名字

如何？EDSL 式的定义方式

想了半天，我觉得要最下面那个就够了。