简单的思路，虽然写了我很久 🤔...

其实有个大小端的问题... 虽然 AXML 作为一种二进制文件格式并不复杂（没有添加 alignment、不需要搞基流定位）
但是还是要求以小端格式存取，至少好像是 String Pool 必须这样 🤔

emmm... 唉

以下是基于这个文件和 https://gist.github.com/duangsuse/3ae94e339eb188fa4ec8a87b6e105331 分析出来确认有效的文件结构：

当然还有 https://github.com/aosp-mirror/platform_frameworks_base/tree/pie-release/tools/aapt2

AAPT2

https://github.com/aosp-mirror/platform_frameworks_base/blob/pie-release/tools/aapt2/cmd/Dump.cpp#L79

乘着 Telegram 还能够连上赶快

== BinaryDataReader 的必须基础操作，我所希望的

+ skipNBytes(n)
+ readNBytes(n)
+ readU8 / readI8
+ readU16 / readI16
+ readU32 / readI32
+ readU64 / readI64
+ readCStr / readXPrefixStr

+ readNX
+ skipX
+ checkX

和 java 的 DataInputStream 相比，它缺少：

+ readUTF
+ readLine
+ readFully <1 overloads>
+ read Float/Double/Char/Boolean

它实现了 ExtDataInput 扩展类的

+ skipInt（skipX）
+ readIntArray（readNX）
+ skipCheckX（checkX）
+ skipBytes（skipNBytes）（更努力地跳过这些字节，或者说坚持一定要跳过而不因为被打断而终止，定义如下）

proc int skipNBytes(int n) {
  int skipped = 0, now;
  while skipped < n AND now = super.skipBytes(n - skipped) >0 { total += now; }
  return skipped;
}

+ readNullEndedString （readCStr）

因为没有必要（只是处理二进制数据）。

首先：AXMLParser 它怎么看 AXML 文件格式：

Axml -> little-endian
int 0x00080003 （其实这种定义是不足够健壮的，它利用了 Top Chunk 的性质，硬编码了 Chunk Type 和 Chunk Header Length）
int chunkSize

StringBlock strb

StringBlock -> little-endian
skipCheckChunkTypeInt(CHUNK_STRINGPOOL_TYPE, CHUNK_NULL_TYPE)
int chunkSize

int stringCount
int styleCount
int flags
int stringsOffset
int stylesOffset
prop isUTF8 = flags & 0x00000100

int[stringCount] stringOffsets
prop stringOwns = [stringCount; -1]

if styleCount != 0 then int[styleCount] styleOffsets

prop size = if styleCount != 0 then stylesOffset else chunkSize end - stringsOffset
byte[size] strings
strings = readFully

if stylesOffset != 0 then
prop size = (chunkSize - stylesOffset)
styles = int[size / 4]
prop remaining = size % 4
if remaining >= 1 then while remaining-- >0 do skipByte

啊这种烂代码我真的不想再看下去了，写时一时爽，重构火葬场，需要那么复杂么？

我真的搞不懂为啥要算那么多... 而且为啥这些结构不在开始创建数据对象的时候就计算好，非得存下二进制每次使用的时候再去算... 连这点开销都受不起还是说从 C++ 翻译过来的...

好吧... 其实算和控制结构是必要的，所以我要吐槽的其实是为什么不『完整反序列化』、为什么要将他们单独字节数组存下来重新解析而不是用 stream reader 处理好了...
要知道，一个问题，两种解决方案风格可是很难看的...
写着觉得自己爽了，你看还用了个 ++i 哦、还用到了 block scoping 哦

过几天再读一下就爽了，还不如写简单点... 多用命名和列表处理方法... 🤔
这还没有解析完... 还是子字节数组... emmmm...

可见是这种代码写开心了... 23333333 难怪最后没机会写出整个完整的解析器了，二进制操作和控制流写的自我感觉超级棒，但是人脑也是有极限的...

🤔 AAPT 和 AAPT2，我觉得 AAPT 就已经足够，因为它已经能够 handle 很多软件包的 Manifest 和 AXML 了，ARSC 文件我下次再说

#Ruby #Project 一个失败的尝试，但是我也了解了二进制 IO 的一些信息

https://github.com/duangsuse/AxmlSerializer/tree/master/RubyAXML

失败是因为我没有时间去完成，但是我也成功设计了个可用的二进制读写器，可惜没有写功能测试。

和隔壁的 sdklite 纯 Java aapt 实现对比，情商（显然，二进制每次判计算、算偏移量小哥非常的...呃...秀操作，至于后面那个手动判断选择增加偏移量再索引的 UtfString 长度提取器，更是秀破天际）一目了然

但是 — 你写这么多有什么暖用呢？虽然看起来不明觉厉而且非常显得大佬，但是程序执行的速度也并不比 stream 法快多少 — 甚至可能更慢，因为分配了更多临时的数据子序列拷贝 🤔
况且这个可怜的秀库最后是没有写完烂尾的下场 — 其实很多时候，简单反而好（但不是说，因为简单是好的就不应该去了解学习复杂的东西）。

记得 The Little Schemer 上说，好的程序会反映出它所处理数据的结构

看着两段代码的对比，我觉得真的就是这样... 好的程序反映出它所处理数据的结构，给数据以表述式的灵活，而不是死板板地『间接』『富有计算性』操作存储器，然后把一切复杂度，放到程序员手中。
（基本只是类似的而已，因为很多其实... 呃，一些项目最后没有真正彻底的实现解析算法，所以我找了些差不多的）

😐 AAPT 的 restable.cpp 和 StringPool、Resources 都是有意思的源文件，可是他们都不包含解析器算法，不过我找到了序列化器。
😐 [不佳实践：没有真正按规范解析 AXML（partial，lossy 解析提取出不完整的结构，丢失了不少信息）、不够模块化] https://github.com/shazam/axmlparser/blob/master/src/main/java/com/shazam/axmlparser/AXMLParser.java#L255
😐 [不佳实践：创建了太多份拷贝、依赖静态类变量、手算偏移量、用 byte 数组替代其真正表达的 Int32 信息] https://github.com/duangsuse/AXMLEdit/blob/master/src/main/java/cn/wjdiankong/axmledit/chunk/EndNameSpaceChunk.java
👍 [Good OO Practice] https://github.com/sdklite/aapt/blob/master/src/main/java/com/sdklite/aapt/AssetEditor.java#L627

不错不错~

真理啊。 👊

Telegram Desktop was updated to version 1.6.2

#sysadmin #linux 🤔 很久没有更新 Fedora 了

这次更新的时候，我注意到 TexLive 也有更新

+ 一些不常见的软件包，我以为已经停止维护了的（比如 KAlgebra，这次更新了 Breeze 风格的新 UI、Sigil 电子书编辑器），居然也更新了
+ 下载了 2G 多的数据，更新花费了快一个小时
+ Blender 的 Eevee 渲染器还是没有在 2.79b 里出现

🤗但是还是更新了很多欸