API讨论

[srdr0p]

查找方法和类比较割裂，findClass的结果和findMethod不能一起用。我理想中的API是这样

bridge.findMethod(FindMethodArgs.builder()
    .addMethodDeclareClassConstraints(
        FindClassArgs.builder().superClass("xxx.xxx.mysuperclass")
    )
)

或者考虑

bridge.findClassForFilter(FindClassArgs.builder())
.findMethod(FindMethodArgs.builder())

[teble]

之前确实有想过提供多种过滤器进行查询以及返回类/方法的元数据等信息，但是碍于jni传递参数的困难以及没有想到一个合适的API设计（简单易用与查询复杂的的平衡点比较难把握），再加上前段时间比较忙，所以这个事情一直搁置了。目前确实是属于凑合用的情况。 另外一个是目前native实现的查找的lambda并没有对各种逻辑进行拆封和封装导致目前没办法支持过于灵活的查找。后续提供新的API的话应该是会对native部分完全重写。

您的API建议也很合理，会纳入后续的考虑中，感谢提议。

[srdr0p]

或者考虑使用自定义的DSL描述查询语言。

其他问题：

• DexFieldDescriptor.getFieldInstance 返回的是Member，不是Field，是我使用上有问题？
• 没有findConstructor类似的方法，是包含在findMethod中？
• 考虑到查找始终是个耗时操作，是否可以提供缓存，在APK不变的情况下使用缓存结果。可以简单检查APK中所有文件的CRC异或结果保证缓存与APK匹配。

[teble]

DexFieldDescriptor.getFieldInstance 返回的是Member，不是Field，是我使用上有问题？

DexFieldDescriptor.getFieldInstance的返回值确实搞错了，因为平时几乎用不上，所以一直没发现这个问题，但是Field是Member的实现类，你目前可以强转一下(逃

没有findConstructor类似的方法，是包含在findMethod中？

Method、Constructor 皆是 Member的子类， DexMethodDescriptor 有提供 getConstructorInstance、getMethodInstance 以及 getMemberInstance。

考虑到查找始终是个耗时操作，是否可以提供缓存

对于结果的缓存应该由调用方来实现而不是由DexKit提供，这对于一个第三方库并不是一个合理的行为，而且DexKit并不会对任何数据进行持久化

[teble]

然后至于构造函数的调用查找，在smali中构造函数的函数名为<init>，静态块也有对应的函数名<clinit>，其它部分与正常Method保持一致

[srdr0p]

similar_regex_match(search = "abc$", target = "bc") == true 这里是否有误，应返回false

[teble]

similar_regex_match(search = "abc$", target = "bc") == true 这里是否有误，应返回false

是的，因为很多注释都是在copilot帮助下写的，这里疏忽了

[teble]

DexFieldDescriptor.getFieldInstance 返回的是Member，不是Field

1.1.5 已修复

[teble]

2.0版本已经重写完成，支持链式调用以及复杂查询，这几天会发布2.0测试版进行测试欢迎到时进行测试，此issue关闭

[teble]

2.0.0-alpha 已发布，欢迎测试，如有疑问请开新 issue