首先，我不清楚引用其他代码的链接是否合适，如果合适，我很抱歉，并想了解在我引用库的情况下，什么是更合适的机制（这些链接主要作为对相关方的引用提供）。
我们有一个适用于android的webrtc原生应用程序，它在调用dispose of the peereconnectionfactory时遇到了困难。当用户选择结束活动会话时，我们有一个清理例程，它会关闭对等连接，然后对其进行处置（尽管关闭并不是真正必要的，因为对处置的调用也会在释放其他资源之前关闭连接，例如流和本机观察者，请参见libjingle-talk/app/webrtc/java/src.org/webrtc/PeerConnection.java）。在我们的例子中，对等连接工厂的创建是由通过可运行程序创建的线程执行的，而工厂的处置是从主UI线程执行的。
这就是我们遇到问题的地方——即，当试图处理对等连接工厂时，应用程序崩溃。
关于审查与webRTC演示代码相关的帖子（请参阅https://chromium.googlesource.com/external/webrtc/+/master/webrtc/examples/androidapp/src.org/appspot/apprtc）他们似乎没有这个问题。
此外，在审查对等连接工厂实现的本机代码时（请参阅https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/api/peerconnectionfactory.cc）我们看到对等连接工厂析构函数的工作线程的展开和删除。
此外，在审查chromium webrtc问题列表时，我们看到了几个问题（例如。，https://bugs.chromium.org/p/webrtc/issues/detail?id=3100或4196），这使得人们相信在使用对等连接工厂时需要特别注意要使用的线程/循环模型。
因此，我的基本问题是，从与处理线程不同的线程创建对等连接工厂时是否存在问题，以及管理对等连接工厂是否存在一组特定的线程/循环要求。
谢谢，
因此，事实证明线程不是问题所在，尽我所能，通过代码等进行跟踪。问题是我们有一个单独的私有类，它实现了SDPObserver、PCObserver和DataObserver以及其他一些逻辑。
这样做的结果是，当对等连接被初始化时，实现所有观察者（和一些其他逻辑）的类被传递为观察者，而被记录为libjingle中的本地观察者，因此，调用dispose peereconnection导致释放本机观察器，这不仅导致PCObserver被释放（在libjingle peereconnection.dispose（）中），而且因为对我们来说，它是同一个类，所有东西都被释放了-当其他类被认为仍然存在时，导致崩溃。
因此，为每个观察者重新设计了单独的私有类，并正确地将适当的观察者传递给对等连接创建（以及适用于不同调用的sdp/data观察者），然后一切都正常了-dispose只释放了PCObserver，一切都很好。