前言

因为前段时间开源了一个用 C++ 实现的高性能 dex 运行时解析库DexKit.

然后里面借鉴了哔哩漫游里面的解压代码，然后在中途也因为有部分APK的格式解析不了，又去学习了zip文件的格式并且修了修bug，不过这都是后话了。

为什么要提起这个东西呢，因为前几天有人反馈说MIUI14的手机管家APK解析不出东西了，然后我第一反应是是不是路径填错了？但是反复确认后发现确实是解压不出来APK里面的dex文件，就开始了漫长的调试之旅。

背景

项目维护的久了，业务逻辑就会因为需求导致越来越多的分支，也可能在开发过程中cv的时候疏忽，忘记修改了一个参数，直到上线的时候bug才体现出来。这就陷入了一个没有测试导致开发过程中的bug带入了线上环境的尴尬境地。

前言

之前startUML还在3.1.0的时候其实已经破解过一次了，网上的破解教程其实也有很多。讲道理现在startUML的颜值还是很高的。startUML目前的版本都是通过electron打包生成的软件，纯前端开发的东西，并且代码清晰，该有注释有注释，业务逻辑一点混淆都没做，搞得我破解的怪不好意思的。我没有搞事情！但是因为最近StartUML 3.1.1版本发布，发现退出时会强制弹出更新，怪难受的，上次没注意选了是，结果瞬间给我装完了。更加增加了我去除更新的决心。

0x0. LocalDateTime在SpringBoot中的窘境

问题由来：在前不久，我们后台就已经抛弃了Date这个类，而改用了java8提供的LocalDateTime，但是正常情况下LocalDateTime的构造函数是私有的，无法像Date那样直接被spring mvc直接处理，所以带给了我很多困扰，甚至有一次项目急迫致使我直接使用String去对时间进行接收，然后再通过DateTimeFormatter在Controller层对参数进行了一层处理，才能将LocalDateTime传给了Service进行处理，直接导致的结果就是方法变得有点丑陋了（逃~