我创建了一个只在一个地方调用的方法——onBindViewHolder()在 RecyclerView 中。它是代码的逻辑单元，我认为将代码块提取到方法中可以提高可读性。但是，在代码审查期间，我被告知方法调用很昂贵，因此会对性能产生负面影响，并且我应该内联代码而不是将其放在单独的方法中。
我认为 JVM 或编译器会通过内联该方法来优化此代码，但我不确定 Android 上是否是这种情况。我还没有真正找到任何关于新的 ART JVM 做了什么样的优化的具体信息。
在 Android 上调用一个方法是否如此昂贵，以至于我应该在可能多次调用该方法的地方以可读性为代价避免它？此外，由于 DEX 方法的限制，创建这样的一次性方法是否令人不快？（这个应用程序已经在使用 multidex）。
这个问题与其他类似的 java 问题没有重复，因为我专门询问 Android 上的性能，它有自己的特质。
我完全不同意。理论上，方法调用确实会增加一些开销。必须将事物压入堆栈，然后跳转到方法。但是开销是微不足道的。
过早的优化从来都不是一个好主意。对您的应用程序进行基准测试并找出真正的性能问题在哪里。我很肯定这不会是因为单个方法调用，即使是经常调用的方法。如何实现该方法可能是一个问题，但不是调用本身。
但是，在代码审查期间，我被告知方法调用很昂贵，因此会对性能产生负面影响，并且我应该内联代码而不是将其放在单独的方法中。
在代码审查期间任何这种性质的建议都可能是没有根据的。
方法调用的成本仅在该方法被频繁调用时才重要。
方法调用的成本取决于编译器/优化器的好坏。随着 Android 编译器的发展，这些会随着时间而改变。事实上，方法调用很可能变得不那么昂贵......直到它们达到编译器在优化直接代码方面与普通程序员一样好（或优于）的程度。
我对你和你的代码审查者的建议是避免过早的优化。让您的应用程序运行起来，看看它是否表现得足够好。如果不是，则对其进行分析以确定真正的性能瓶颈在哪里，并（仅）优化它们。
在 Android 上调用一个方法是否如此昂贵，以至于我应该在可能多次调用该方法的地方以可读性为代价避免它？
呃……不。大多数方法调用不会导致性能瓶颈。事实上，许多性能瓶颈并没有对感知性能做出贡献。对于典型的交互式应用程序，真正重要的是影响用户体验的缓慢/滞后。
任何一刀切的避免方法调用的建议都没有抓住重点。
编码、测试、测量、分析……然后进行优化。