XAutoDaily-v3.0-release 剩余事项:
APP:
1.toast的安卓12不受信触摸事件(摆烂了,只能用adb取消)
2.toast的免打扰
3.配置更新的弹窗
4.app检测更新的弹窗
5.是否启用线程池执行任务
6.日志输出文件&导出
7.配置导入导出
8.任务执行异常次数进行计数,超过3次当日不再执行(避免接口失效导致任务重试一整天)
9.任务调度器部分太极用户无法正常启动(自动执行失效)
配置(延期发布):
1.厘米秀小程序适配
2.情侣空间浇水?
注意:vivo及vivo子用户可能存在进入模块白屏的问题,只能通过切换后台/修改为虚拟按键(这奇怪的玩意实在不知道怎么修)
APP:
3.配置更新的弹窗
4.app检测更新的弹窗
5.是否启用线程池执行任务
6.日志输出文件&导出
7.配置导入导出
8.任务执行异常次数进行计数,超过3次当日不再执行(避免接口失效导致任务重试一整天)
9.任务调度器部分太极用户无法正常启动(自动执行失效)
1.厘米秀小程序适配
2.情侣空间浇水?
注意:vivo及vivo子用户可能存在进入模块白屏的问题,只能通过切换后台/修改为虚拟按键(这奇怪的玩意实在不知道怎么修)
👍5
c++的debug跟release性能差距确实有点大。
之前weishu说过这玩意,但是因为当时实测debug跟release只有几十ms的差距我也没放心上。
今天叼毛Blanke说dexkit搜索微信耗时好像有点不对劲,定位微信一个类耗时1700ms,然后我自己也试了一下,结果也花了1400ms,最后各种日志查到怀疑人生才想起来可能是debug的问题,然后打了个release包,耗时瞬间降到原本的十分之一,总算了结一桩悬案。
以后c++测性能一定要打release!!!
之前weishu说过这玩意,但是因为当时实测debug跟release只有几十ms的差距我也没放心上。
今天叼毛Blanke说dexkit搜索微信耗时好像有点不对劲,定位微信一个类耗时1700ms,然后我自己也试了一下,结果也花了1400ms,最后各种日志查到怀疑人生才想起来可能是debug的问题,然后打了个release包,耗时瞬间降到原本的十分之一,总算了结一桩悬案。
以后c++测性能一定要打release!!!
术哥为了安卓开发更便捷的使用DexKit,所以为DexKit pr了一个使用 prefab 进行NDK预构建的版本,使用prefab后能用 implementation 引入依赖的方式直接链接库,省去了引入子模块的步骤,但是我的本意是DexKit仅作为一个CMAKE的库可以更广泛自由的引入,强行绑定NDK就大大限制了自由度,所以另外开了一个DexKit-Android仓库。由于疏忽,术哥忘记更新ignore文件导致项目编译构建后的所有内容一并push进了仓库,导致仓库总大小直接增长为了20m+,但是此时后续又产生了提交以及版本发布,所以暴力force push已经不可取,那么有没有什么方式能做到保留历史提交记录的同时再删除相关文件呢?
答案是有的,使用git filter-branch命令即可做到,比如要彻底删除某个文件夹的相关记录执行
但是这样操作后gpg签名信息会丢失,所以需要重新签名(签名前后的commit hash都不一样)
为了历史记录干净真的费尽心思,希望这种东西以后再也用不到了
答案是有的,使用git filter-branch命令即可做到,比如要彻底删除某个文件夹的相关记录执行
git filter-branch --force --index-filter 'git rm --cached -r --ignore-unmatch <compile file dir>' --prune-empty --tag-name-filter cat -- --all
执行完后,出现了很诡异的历史记录,出现了两条并行的git历史线,然后仔细查询了一下因为git tag的记录依旧存在(每个git tag会存储当时完整的提交文件变动),所以删除了git tag后再 push -f origin master 就成功完成了我们的目的。但是这样操作后gpg签名信息会丢失,所以需要重新签名(签名前后的commit hash都不一样)
为了历史记录干净真的费尽心思,
❤1
DexKit重构事项:
1. 搜索参数由kt的可选参数变更为Builder构建查询(更自由的参数选择,新增accessFlag过滤,java调用也无需全参数传递)
2. 返回的DexDescriptor对象提供accessFlags(public、final……)、Interface/superClass等列表是否需要返回待考虑
3. 考虑到c++与java传递对象的困难,如何避免jni反射调用java产生过多的性能开销是一个需要注意的问题
4. Odex支持?划掉划掉
1. 搜索参数由kt的可选参数变更为Builder构建查询(更自由的参数选择,新增accessFlag过滤,java调用也无需全参数传递)
2. 返回的DexDescriptor对象提供accessFlags(public、final……)、Interface/superClass等列表是否需要返回待考虑
3. 考虑到c++与java传递对象的困难,如何避免jni反射调用java产生过多的性能开销是一个需要注意的问题
android-build-tools:33.0.0上windows特供bug
Execution failed for task ':app:compileDebugAidl'已经在2022/11/23发布的33.0.1中得到修复(3月份的bug年底才修,真有谷歌的)新版 Android Studio Gradle JDK缓存的版本列表想删除只能动配置文件(强迫症看的脑溢血),都3202年了,学学隔壁 IDEA 的 JDK 列表很难吗
Windows:
Mac:
Linux:
Windows:
%APPDATA%\Google\AndroidStudio<version>\options\jdk.table.xmlMac:
~/Library/Application Support/Google/AndroidStudio<version>/options/jdk.table.xmlLinux:
~/.config/Google/AndroidStudio<version>/options/jdk.table.xmlDexKit 2.0计划:
为了支持更强大的搜索,需要支持可递归嵌套类型传递,例如以下场景:
存在一个被混淆的类A,它继承了被混淆的父类B,父类B实现了一个未被混淆的接口C,同时A存在了这样一个方法,方法返回值是一个被混淆的Bean实体类并且被混淆的一个属性存在注解JsonProperty(name="date"),根据已知条件构造查询对象,一次调用即可定位到确切的函数。
但是这样的复杂对象传递给jni有什么好方法吗?序列化成json再去解析?还是使用Map传递参数?或者java创建一个查询对象就创建一个对应的native对象?
无论是java call native还是native call java都存在一定的开销,简单的方法强行使用 JNI 无疑是降低效率的做法。
所以把目光投向了 protobuf, 但是当我写完初版的 proto 文件后发现了一些问题,对于 protobuf 来说它对 null 与 [] 是不区分的,但是在实际场景中却存在这样的需求。如果想要在 protobuf 中完成这项工作,其一:创建一个 message 对 repeated 字段进行包装,但是使用体验极差;其二:使用oneof关键词变相完成。
在翻 protobuf 相关资料的时候,发现了谷歌的另一个库 flatbuffers, 经过粗略的资料查询 flatbuffers 对比 protobuf 来说有这么几个优势:
1. 不对数据进行压缩,无需转换解包,即可获取原始数据
2. 反序列化时间极短,短到可以忽略不计
3. cpu,内存占用较低
4. 生成代码轻量,c++头文件全都是header only的
5. 对 null、 [] 进行区分!!!
但是也存在不如protobuf的地方:Protobuf 使用“Base 128 Varints”对数据进行压缩,最高压缩的比例能达到50%
然后稍微学习了一下 flatbuffers 的 fbs 文件的语法,编写出了初版的 schema。目前 DexKit 使用 flatbuffers 开发体验良好,并且2.0版本发布大概率会分3个包: 核心库: dexkit-lib,同时为了保证 kotlin 用户拥有完整的 dsl 体验支持,将会对工具包独立成 dexkit-ktx, dexkit 两个子模块
为了支持更强大的搜索,需要支持可递归嵌套类型传递,例如以下场景:
存在一个被混淆的类A,它继承了被混淆的父类B,父类B实现了一个未被混淆的接口C,同时A存在了这样一个方法,方法返回值是一个被混淆的Bean实体类并且被混淆的一个属性存在注解JsonProperty(name="date"),根据已知条件构造查询对象,一次调用即可定位到确切的函数。
但是这样的复杂对象传递给jni有什么好方法吗?序列化成json再去解析?还是使用Map传递参数?或者java创建一个查询对象就创建一个对应的native对象?
无论是java call native还是native call java都存在一定的开销,简单的方法强行使用 JNI 无疑是降低效率的做法。
所以把目光投向了 protobuf, 但是当我写完初版的 proto 文件后发现了一些问题,对于 protobuf 来说它对 null 与 [] 是不区分的,但是在实际场景中却存在这样的需求。如果想要在 protobuf 中完成这项工作,其一:创建一个 message 对 repeated 字段进行包装,但是使用体验极差;其二:使用oneof关键词变相完成。
在翻 protobuf 相关资料的时候,发现了谷歌的另一个库 flatbuffers, 经过粗略的资料查询 flatbuffers 对比 protobuf 来说有这么几个优势:
1. 不对数据进行压缩,无需转换解包,即可获取原始数据
2. 反序列化时间极短,短到可以忽略不计
3. cpu,内存占用较低
4. 生成代码轻量,c++头文件全都是header only的
5. 对 null、 [] 进行区分!!!
但是也存在不如protobuf的地方:Protobuf 使用“Base 128 Varints”对数据进行压缩,最高压缩的比例能达到50%
然后稍微学习了一下 flatbuffers 的 fbs 文件的语法,编写出了初版的 schema。目前 DexKit 使用 flatbuffers 开发体验良好,并且2.0版本发布大概率会分3个包: 核心库: dexkit-lib,同时为了保证 kotlin 用户拥有完整的 dsl 体验支持,将会对工具包独立成 dexkit-ktx, dexkit 两个子模块
🥰2
愚蠢的 clion,在 windows 上居然还默认启用 pty 做output输出,超过120字符截断看着是真脑溢血,取消掉 registry 中的
run.processes.with.pty 即可🌭4😭1
