duangsuse::Echo
以下是基于这个文件和 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…
首先：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
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
This media is not supported in your browser
VIEW IN TELEGRAM
我真的搞不懂为啥要算那么多... 而且为啥这些结构不在开始创建数据对象的时候就计算好，非得存下二进制每次使用的时候再去算... 连这点开销都受不起还是说从 C++ 翻译过来的...
好吧... 其实算和控制结构是必要的，所以我要吐槽的其实是为什么不『完整反序列化』、为什么要将他们单独字节数组存下来重新解析而不是用 stream reader 处理好了...
要知道，一个问题，两种解决方案风格可是很难看的...
写着觉得自己爽了，你看还用了个 ++i 哦、还用到了 block scoping 哦
过几天再读一下就爽了，还不如写简单点... 多用命名和列表处理方法... 🤔
这还没有解析完... 还是子字节数组... emmmm...
好吧... 其实算和控制结构是必要的，所以我要吐槽的其实是为什么不『完整反序列化』、为什么要将他们单独字节数组存下来重新解析而不是用 stream reader 处理好了...
要知道，一个问题，两种解决方案风格可是很难看的...
写着觉得自己爽了，你看还用了个 ++i 哦、还用到了 block scoping 哦
过几天再读一下就爽了，还不如写简单点... 多用命名和列表处理方法... 🤔
这还没有解析完... 还是子字节数组... emmmm...
duangsuse::Echo
🤔 AAPT 和 AAPT2，我觉得 AAPT 就已经足够，因为它已经能够 handle 很多软件包的 Manifest 和 AXML 了，ARSC 文件我下次再说
#Ruby #Project 一个失败的尝试，但是我也了解了二进制 IO 的一些信息
https://github.com/duangsuse/AxmlSerializer/tree/master/RubyAXML
失败是因为我没有时间去完成，但是我也成功设计了个可用的二进制读写器，可惜没有写功能测试。
https://github.com/duangsuse/AxmlSerializer/tree/master/RubyAXML
失败是因为我没有时间去完成，但是我也成功设计了个可用的二进制读写器，可惜没有写功能测试。
GitHub
duangsuse/AxmlSerializer
Android AAPT2-compatible AXML Binary XML format parser/generator - duangsuse/AxmlSerializer
和隔壁的 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
不错不错~
真理啊。 👊
但是 — 你写这么多有什么暖用呢？虽然看起来不明觉厉而且非常显得大佬，但是程序执行的速度也并不比 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
不错不错~
真理啊。 👊
GitHub
aosp-mirror/platform_frameworks_base
Contribute to aosp-mirror/platform_frameworks_base development by creating an account on GitHub.
Telegram Desktop was updated to version 1.6.2
duangsuse::Echo
#sysadmin #linux 🤔 很久没有更新 Fedora 了
这次更新的时候，我注意到 TexLive 也有更新
+ 一些不常见的软件包，我以为已经停止维护了的（比如 KAlgebra，这次更新了 Breeze 风格的新 UI、Sigil 电子书编辑器），居然也更新了
+ 下载了 2G 多的数据，更新花费了快一个小时
+ Blender 的 Eevee 渲染器还是没有在 2.79b 里出现
🤗但是还是更新了很多欸
+ 一些不常见的软件包，我以为已经停止维护了的（比如 KAlgebra，这次更新了 Breeze 风格的新 UI、Sigil 电子书编辑器），居然也更新了
+ 下载了 2G 多的数据，更新花费了快一个小时
+ Blender 的 Eevee 渲染器还是没有在 2.79b 里出现
🤗但是还是更新了很多欸