静态分析代码质量开发工具【免费下载链接】inferA static analyzer for Java, C, C, and Objective-C项目地址https://gitcode.com/gh_mirrors/infer/infer点击查看免费下载导读CHECKERS_CALLS_EXPENSIVE_METHOD是 Facebook 开源静态分析器 Infer 中 Annotation Reachability注解可达性检查器内置的一类性能回归问题。当代码中被标记为PerformanceCritical的方法直接或间接调用了被标记为Expensive的方法时Infer 会以该问题类型向开发者报告从而在 CI 阶段提前拦截「高性能关键路径上误调昂贵操作」的回归。读完本文你将掌握该问题的完整语义、触发规则、注解用法、相关命令行开关以及如何通过仓库内的真实测试用例验证分析行为。问题定义一条不可触碰的性能红线依据 CHECKERS_CALLS_EXPENSIVE_METHOD.md 中的定义A method annotated withPerformanceCriticaltransitively calls a method annotatedExpensive.即被PerformanceCritical注解的方法以传递transitive方式调用了被Expensive注解的方法。这里的「传递」是关键——调用链中间可以隔着多层普通方法只要最终能到达一个Expensive方法就会被报告。原文档给出的最小触发示例class C { PerformanceCritical void perfCritical() { expensive(); } Expensive void expensive() {} }在该示例中perfCritical()被标记为性能关键路径它直接调用了expensive()因此 Infer 产生一条CHECKERS_CALLS_EXPENSIVE_METHOD报告并在问题轨迹trace中标明「source 为 PerformanceCriticalsink 为 Expensive」。该问题类型的注册位置该问题类型在 Infer 源码中注册于 IssueType.mlregister ~category:PerfRegression ~id:CHECKERS_CALLS_EXPENSIVE_METHOD ... ~user_documentation:[%blob ./documentation/issues/CHECKERS_CALLS_EXPENSIVE_METHOD.md]从源码可以确认两点其一它属于PerfRegression性能回归类别其二本文所讲解的这份文档正是 Infer 在生成问题报告时直接嵌入的用户文档user_documentation也就是说你在命令行或 IDE 中看到的问题说明正文就来源于仓库中的这份 Markdown。两个核心注解PerformanceCritical 与 ExpensivePerformanceCritical声明「这条路径不容有失」源码位于 annotations/src/main/java/com/facebook/infer/annotation/PerformanceCritical.javapackage com.facebook.infer.annotation; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; Retention(RetentionPolicy.CLASS) Target(value {ElementType.METHOD, ElementType.TYPE}) public interface PerformanceCritical {}关键信息可标注在方法与类型类/接口两个粒度上。标注在类型上意味着该类以及按规则继承该注解的子类的所有方法都被视为性能关键路径保留策略为CLASS即注解会写入 class 文件但不要求在运行时可见仅供静态分析读取。Expensive声明「这个方法代价高昂」源码位于 annotations/src/main/java/com/facebook/infer/annotation/Expensive.javapackage com.facebook.infer.annotation; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; Retention(RetentionPolicy.CLASS) Target({ElementType.METHOD, ElementType.TYPE}) public interface Expensive {}同样的Expensive也支持方法级与类型级标注。将Expensive标注在类上即声明「该类的所有方法都是昂贵的」例如测试用例中的ExpensiveClass。承载检查器Annotation ReachabilityCHECKERS_CALLS_EXPENSIVE_METHOD并非独立运行的检查器而是由Annotation Reachability注解可达性检查器内置的一对「source/sink」规则产出。在 Checker.ml 中检查器的官方说明为Given pairs of source and sink annotations, e.g.AandB, this checker will warn whenever some method annotated withAcalls, directly or indirectly, another method annotated withB. Besides the custom pairs, it is also possible to enable some built-in checks, such asPerformanceCriticalreachingExpensiveorNoAllocationreachingnew.即检查器的设计初衷是处理任意「源注解 → 汇注解」配对PerformanceCritical → Expensive只是其中一个内置检查项。该检查器支持的编程语言包括 Java、C/CClang、Erlang以及实验性的 Swift。注意该检查器默认不启用enabled_by_default false需要在命令行显式开启。如何启用由于该问题由 Annotation Reachability 检查器产出你需要同时启用检查器与内置的 expensive 检查项。从 Config.ml 可以看到--annotation-reachability-expensive check if methods annotated with PerformanceCritical can call expensive methods (annotated Expensive or modeled, with annotation reachability checker)典型运行方式infer run --annotation-reachability-only --annotation-reachability-expensive -- javac Example.java实际命令行前缀以infer analyze --help中--annotation-reachability开头的开关为准开启检查器本身可使用-a annotation-reachability或--annotation-reachability-only。真实触发场景从测试用例看分析行为仓库的测试目录 infer/tests/codetoanalyze/java/annotreach/basic/ 保存了该检查器的大量 Java 测试用例其中 ExpensiveCallExample.java 专门覆盖了CHECKERS_CALLS_EXPENSIVE_METHOD的各种变体期望输出记录在 issues.exp 中。下面按场景逐一解读。场景一直接调用必报PerformanceCritical void directlyCallingExpensiveMethod() { expensiveMethod(); // expensiveMethod 被 Expensive 标注 }期望输出ExpensiveCallExample.directlyCallingExpensiveMethod():void, 1, CHECKERS_CALLS_EXPENSIVE_METHOD, ERROR, [Method ...directlyCallingExpensiveMethod, marked as source PerformanceCritical, calls ...expensiveMethod, ... marked as sink Expensive]场景二间接调用传递可达必报void methodWrapper() { expensiveMethod(); } PerformanceCritical void indirectlyCallingExpensiveMethod() { methodWrapper(); // 中间隔了一层普通方法 }期望输出显示 trace 依次为indirectlyCallingExpensiveMethod → methodWrapper → expensiveMethod印证了「transitively」的语义中间方法不需要任何注解只要调用链最终触达Expensive方法即报。场景三长调用链跨类传递必报PerformanceCritical void longerCallStackToExpensive() { callsExpensive2(); // 本类方法 } void callsExpensive2() { mOther.callsExpensive1(); // Other 类的方法 } // Other 类中 void callsExpensive1() { expensive(); // Expensive }期望输出完整展开为longerCallStackToExpensive → callsExpensive2 → callsExpensive1 → expensive的四层调用轨迹每一层方法都出现在报告 trace 中便于开发者定位插桩点。场景四类型级注解继承必报Expensive class ExpensiveClass { void anExpensiveMethod() {} } PerformanceCritical class PerformanceCriticalClass { void performanceCriticalMethod1(ExpensiveClass c) { c.anExpensiveMethod(); // 类级 Expensive 生效 } }同时子类继承PerformanceCritical类注解后同样受检class PerformanceCriticalSubclass extends PerformanceCriticalClass { void subclassPerformanceCriticalMethod1(ExpensiveClass c) { c.anExpensiveMethod(); // 应报告 } }issues.exp 第 29-31 行确认了这些子类场景均产出该问题。场景五条件分支内的调用按到达次数报告PerformanceCritical void callsExpensiveInConditionalBranch() { if (test()) { expensiveMethod(); } }issues.exp 第 40 行显示该用例报告数量为2即该错误位置出现两次与分支路径展开相关说明检查器按控制流路径展开分析分支内的调用不会被遗漏。场景六内置模型——findViewByIdPerformanceCritical View callsFindViewByIdFromView(ImageView view, int id) { return view.findViewById(id); }issues.exp 第 36-37 行显示android.view.View.findViewById与android.app.Activity.findViewById无需任何注解即被视为Expensive汇点。这正是 Checker.ml 中提到的「modeled建模」机制Infer 为部分已知的高开销系统 API 内置了模型等价于给它们贴上了Expensive。不应报告的反例测试用例同时给出了不应触发的对照PerformanceCritical void notCallingExpensiveMethod() { nonExpensiveMethod(); // 普通方法不报告 } void performanceCriticalMethod4(Other o) { o.inexpensiveMethod(); // 不报告 }这些反例在 issues.exp 中没有对应条目用于防止误报。相关配套开关除--annotation-reachability-expensive外Config.ml 中还提供了多个影响分析行为的开关命令行开关默认值作用--annotation-reachability-apply-superclass-annotationstrue将父类与接口上的注解应用到未被其覆写的方法上--annotation-reachability-check-loopsfalse在 trace 中标高嵌套在循环中的调用点callsite--annotation-reachability-custom-models空用正则表达式将任意方法「视为」带有某注解例如{Annotation: [com\\.Myclass\\.foo.*]}支持allow/block列表--annotation-reachability-custom-pairs空自定义 source/sink以及可选的 sanitizer配对并可通过minimize_sinks默认true与minimize_sources默认false控制路径最小化--annotation-reachability-expensivefalse启用PerformanceCritical → Expensive内置检查--annotation-reachability-no-allocationfalse启用NoAllocation方法不得分配对象的检查--annotation-reachability-report-source-and-sinkfalse报告同时被标记为 source 与 sink 的方法其中与本文最相关的是--annotation-reachability-custom-models当你无法或不想改动第三方库源码时可以用正则把库中的昂贵方法建模为Expensive从而在不添加注解的情况下获得同样的检查能力——这正是 Checker.ml 所述「在没有注解的语言里也能工作」的实现途径。--annotation-reachability-apply-superclass-annotations则解释了测试用例中接口AnnotatedInterface的PerformanceCritical能作用于实现类的行为见 issues.exp 第 39 行annotatedPerformanceCriticalInInterface。与相关问题类型的区分在同一个测试目录中还能看到与之相邻的问题类型CHECKERS_EXPENSIVE_OVERRIDES_UNANNOTATED当Expensive方法覆写了未标注的父类方法时报告见 ExpensiveSubtypingExample.java 与 issues.exp 第 45 行关注的是「继承关系下的注解缺失」CHECKERS_CALLS_EXPENSIVE_METHOD关注的是「性能关键方法调用昂贵方法」即本文主题。两者一静一动前者检查类层级结构的标注一致性后者检查调用图的性能红线均属于 Annotation Reachability 检查器内置规则。落地实践建议结合上述源码与测试行为在生产项目中落地该检查可以参考以下路径标注关键路径对 UI 渲染、热路径、锁内代码等耗时敏感的方法标注PerformanceCritical方法级或类级标注昂贵操作对网络请求、磁盘 IO、反射、大对象分配等操作标注Expensive若涉及第三方库用--annotation-reachability-custom-models以正则建模接入 CI在构建命令中加入--annotation-reachability-only --annotation-reachability-expensive使任何新引入的「关键路径调用昂贵方法」在合并前即被拦截按需开启 trace 增强需要排查循环内调用时可开启--annotation-reachability-check-loops让问题轨迹中标出位于循环中的调用点。小结CHECKERS_CALLS_EXPENSIVE_METHOD是 Infer Annotation Reachability 检查器的内置性能回归规则语义为「PerformanceCritical方法传递可达Expensive方法」。通过类型级注解、跨类传递调用链、接口继承以及内置 API 模型它在不改动调用方代码的前提下实现跨层级的性能红线守卫。仓库中的 issues.exp 记录了全部期望行为是验证分析器语义的第一手资料结合 Config.ml 中的开关与 Checker.ml 中的检查器说明即可在真实项目中快速落地。赞分享静态分析代码质量开发工具【免费下载链接】inferA static analyzer for Java, C, C, and Objective-C项目地址https://gitcode.com/gh_mirrors/infer/infer点击查看免费下载相关推荐Infer 注解可达性分析Annotation Reachability检测器从 PerformanceCritical 到 Expensive 的调用链追踪Infer 注解可达性分析Annotation Reachability检测器从 PerformanceCritical 到 Expensive 的调静态分析代码质量开发工具Infer 静态分析CHECKERS_EXPENSIVE_OVERRIDES_UNANNOTATED 错误详解与 Expensive 子类型规则Infer 静态分析CHECKERS_EXPENSIVE_OVERRIDES_UNANNOTATED 错误详解与 Expensive 子类型规则 导读 本篇静态分析代码质量开发工具CI/CD集成Infer在持续集成中的最佳实践CI/CD集成Infer在持续集成中的最佳实践 本文详细介绍了Facebook开发的静态分析工具Infer在CI/CD环境中的集成方案包括Jenkins和G静态分析代码质量开发工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考