我的观点是:

确保类路径包含完整路径(/home/user/lib/some_lib.jar而不是~/lib/some_lib.jar)，否则仍然会面临NoClassDefFoundError错误。

当运行时类装入器装入的类不能访问已由Java rootloader装入的类时，我得到NoClassFoundError。因为不同的类装入器在不同的安全域中(根据Java)， JVM不允许在运行时装入器地址空间中解析已经由rootloader装入的类。

使用'java -javaagent:trace .jar [your 'java' ARGUMENTS]'运行程序

它产生显示已加载类的输出，以及加载该类的加载器环境。追踪类为什么不能解析是非常有用的。

// ClassLoaderTracer.java
// From: https://blogs.oracle.com/sundararajan/entry/tracing_class_loading_1_5

import java.lang.instrument.*;
import java.security.*;

// manifest.mf
// Premain-Class: ClassLoadTracer

// jar -cvfm tracer.jar manifest.mf ClassLoaderTracer.class

// java -javaagent:tracer.jar  [...]

public class ClassLoadTracer
{
    public static void premain(String agentArgs, Instrumentation inst)
    {
        final java.io.PrintStream out = System.out;
        inst.addTransformer(new ClassFileTransformer() {
            public byte[] transform(ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {

                String pd = (null == protectionDomain) ? "null" : protectionDomain.getCodeSource().toString();
                out.println(className + " loaded by " + loader + " at " + new java.util.Date() + " in " + pd);

                // dump stack trace of the thread loading class
                Thread.dumpStack();

                // we just want the original .class bytes to be loaded!
                // we are not instrumenting it...
                return null;
            }
        });
    }
}

检查类中是否有静态处理程序。如果是这样，请小心，因为静态处理器只能在有循环程序的线程中启动，崩溃可能会以这种方式触发:

首先，在一个简单的线程中创建类的实例并捕获崩溃。 然后在主线程中调用Class的field方法，你会得到NoClassDefFoundError。

下面是测试代码:

public class MyClass{
       private static  Handler mHandler = new Handler();
       public static int num = 0;
}

在Main活动的onCreate方法中，添加测试代码部分:

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
    //test code start
    new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                MyClass myClass = new MyClass();
            } catch (Throwable e) {
                e.printStackTrace();
            }
        }
    }).start();

    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    MyClass.num = 3;
    // end of test code
}

有一个简单的方法来修复它使用一个handlerThread到init处理程序:

private static Handler mHandler;
private static HandlerThread handlerThread = new HandlerThread("newthread");
static {
    handlerThread.start();
    mHandler = new Handler(handlerThread.getLooper(), mHandlerCB);
}

不要在模块之外使用测试类

我没有解决方案，只是另一种“编译时存在，运行时不存在”的情况。

我试图使用来自JUnit测试类的一个非常方便的方法，来自另一个位于不同模块中的测试类。这是一个禁忌，因为测试代码不是打包的jar的一部分，但我没有意识到这一点，因为它对于Eclipse中的用户类来说是可见的。

我的解决方案是将该方法放在作为生产代码一部分的现有实用程序类中。

如果您正在使用一个以上的模块，您应该有

dexOptions {
    preDexLibraries = false
}

在构建文件中。

我正在开发一个基于Eclipse的应用程序，也称为RCP(富客户端平台)。 在重构(将一个类从一个plugIn移动到一个新的plugIn)之后，我一直面临着这个问题。

清理项目和Maven更新没有帮助。

这个问题是由Bundle-Activator没有自动更新引起的。手动更新MANIFEST下的捆绑激活器。MF在新的插件已经解决了我的问题。