AS中继承RecyclerView.Adapter类后，实现了getItemCount抽象方法，却在运行时报错此抽象方法JVM签名重复问题

如图：我的类继承了RecyclerView.Adapter

 

这个RecyclerView类是系统自带类，且带有抽象方法，如下↓

 这里也是为什么我的类要求必须实现此方法的原因，继承了这个类就必须实现这个类的抽象方法

所以我实现了此类↓注意这里签名的解释，和报错有关

此时可以看到已经实现了我所继承的类的抽象方法，且代码层面也无爆红（这里也是特别奇怪的地方，代码没有问题，到了编译却报错），运行项目时出现报错说这个重写的getItemCount方法JVM签名重复产生冲突。

这里因为我此时已经解决此报错，没有办法截图，有相同问题的可以看一下报错，大体意思就是方法JVM签名重复

解决方法如下：

首先把我们自己的类设为抽象类（就是发生问题的类，在前缀加上abstract即可）

然后新建一个空类，名字随意，这里我是加了后缀111。

之后主要操作是要继承我们刚才出问题的类，图如下

接下来是重要一步：继承了出问题的类后，并重写这个报错元凶：getItemCount方法，返回值大家根据业务逻辑自己写，也可以随便返回一个Int值，我这里的list.size大家不用深究

最后就是收尾工作：把之前用到jzSingleItemAdapter类（即出现问题的类）的地方，全部替换成我们新建的这个继承自问题类的jzSingleItemAdapter111类，此时BUG已修复完成，项目可以正常运行了~

总结修复流程

简单来说思路就是，放弃在问题类（我这里是jzSingleItemAdapter）重写该抽象方法（getItemCount方法），把问题类设为抽象类，然后新建一个类继承这个问题类，并在新建类里重写该抽象方法，最后把引用问题类的地方全部替换成我们的新类即可。

最后个人对于BUG思考

在观察源码后，发现有两个同名方法，类型也一致，感觉有可能是由于这两个同名方法而导致的JVM签名异常

如上图，除了一个是普通方法，一个是抽象方法外，两个方法名字相同，返回类型也相同，参数类型也相同，这也是JVM方法签名的构成，所以我们重写后异常也有可能是因为这里。

这个BUG也是非常的恶心，继承了类就要实现抽象方法，而实现了抽象方法又会导致报错JVM签名重复，逻辑死循环了。我个人能力有限也是为了它解决了一晚上，如果你碰到一样问题，希望可以帮你提供一点解决思路。