iOS:使用第三方Cocoapod依赖项(ARCORE)测试自定义框架时运行时错误
我们(主要是Android的基地:))团队正在开发合作伙伴IOS Swift Framework(SDK),其中有一些第三方依赖。
Framework本身具有几个三方依赖关系,它们都嵌入了Cocoapods(编辑:我们也尝试过SPM,但ATM拒绝了一个项目),并且他们在编译时间或段时或段时都像魅力一样工作在设备/模拟器上进行测试,同时将其嵌入一个简单的测试“合作伙伴”应用中。这里没有一般问题。
但是有一个必不可少的第三方lib: arcore 面孔,嵌入引起问题的嵌入。
因此,我们目前坚持使用其中的共同工作区和2个项目(测试应用程序和框架本身),同样在顶级工作空间级别上的可可录基础结构:
” 此处提到的结构的启发,
platform :ios, '11.0'
workspace 'Untitled.xcworkspace'
abstract_target 'CommonPods' do
# ... some other common 3rd-party dependencies here ...
pod 'ARCore/AugmentedFaces', '~> 1.30.0'
target 'TestApp' do
project 'TestApp/TestApp.xcodeproj'
end
target 'Framework' do
project 'Framework/Framework.xcodeproj'
end
end
像这样,受到 ,合作伙伴测试应用构建很好。
我们面临的问题立即在合作伙伴应用程序启动后发生,并且始终得到崩溃的支持:
... 许多类似的重复警告如下 ...
objc [58698]:class garpseudonymids均在两者中实现 /private/var/containers/bundle/application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TESTAPP.App.app.app.app/frameworks/frameworks/frameworks.framework.framework.framework/framework (0x103d9e0d8)和 /private/var/containers/bundle/application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TESTAPP.APP.APP.APP/TESTAPP (0x10131E440)。两者之一将被使用。哪一个是不确定的。 OBJC [58698]:两者都实现了类GarpSeudonymidStore /private/var/containers/bundle/application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TESTAPP.App.app.app.app/frameworks/frameworks/frameworks.framework.framework.framework/framework (0x103D9E128)和 /private/var/containers/bundle/application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TESTAPP.APP.APP.APP/TESTAPP (0x10131E490)。两者之一将被使用。哪一个是不确定的。
F0621 20:33:23.600151 1注册。h:175]功能 CallbackPacketCalculator已经注册了。
***检查失败堆栈跟踪:*** dyld4 config:dyld_library_path =/usr/lib/lib/system/Intropsection dyld_insert_libraries =/开发人员/usr/lib/libbacktraceRecording.dylib:/developer/usr/lib/libmainthreadchecker.dylib:/develops devpricenter/developer/library/library/privateframeworks/dtddisupport.frame.frame.frame.framewib yllib.dylib.dyllcort.dydyllcougport.dydyllcougport.dydyllcougport.dyllcougportsuersuuse Dyld4配置:dyld_library_path =/usr/lib/lib/system/Intropsection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib
我们已经是什么了知道:
- 项目在模拟器上运行良好(就我们尝试的而言),但是 崩溃在真实设备上
- 它发生在运行时,并且仅在通过Cocoapods添加Arcore并设置Pod'时才会发生。用于testApp和框架目标的Arcore/AugmentedFaces。
- 如果我们尝试在合作伙伴应用程序代码中引用框架API(通过
导入框架
和/或调用其API方法),则不会有任何区别,但是: - 设置pod'arcore/ augmentedfaces'对于仅 testapp ,在编译时间中无法在框架中访问框架Swift代码。
- 为 framework设置pod'arcore/augmentedfaces'时,我们获得 ,我们得到
否这样的模块:arcore
通过swift linter通过import> import> import> import>从本质上讲,合作伙伴应用程序可以进入我们的框架,appdelegate中的fe或否则)。
n类N在两个...
对所有依赖性的警告引用中都实现,但是就我们而言,仅促进了ARCORE的使用情况,因此后来造成了崩溃和错误。- Arcore(显然)将其添加到任何简单的iOS应用程序项目中,包括它的自定义模块,都可以正常工作。
- 删除Arcore Pod并完全引用它,让我们手动测试带有问题的框架功能。
我们仍然不能100%确定类/方法重复问题是否导致崩溃问题,但是我们确定在尝试在两个框架目标和应用程序目标内拥有ARCORE POD时会发生这种情况(或在最高级别的抽象目标中)。无论如何,在任何单独的目标中摆脱豆荚会导致上论文中提到的问题(采用当前方法)。
任何想法或解决方法(也许只有得出第三方源代码:)除外)将不胜感激!
编辑:现在,在试图通过可可录(Cocoapods)添加其他一些第三方软件包,并成功地启动以嵌入Arcore(Arcore),我们意识到,崩溃应该与Arcore Pod使用严格相关。
Our (mostly Android-backgrounded:)) team is developing partner iOS Swift Framework (SDK) with some 3rd-party dependencies inside.
Framework itself has several 3rd-party dependencies all embedded with CocoaPods (Edit: we also tried SPM, but ATM rejected it for a project), and they're working like a charm either during compile time or while testing on device/simulator, while being embedded inside a simple test "partner" app. No general problems here.
But there is one essential 3rd-party lib: ARCore Augmented Faces, embedding which causes a problem.
So we're currently stuck with using common workspace and 2 projects (test app and framework itself) within it, also with CocoaPods base structure on top workspace level:
The Podfile here currently looks like this, inspired by the structure mentioned here https://stackoverflow.com/a/42480097/6405022:
platform :ios, '11.0'
workspace 'Untitled.xcworkspace'
abstract_target 'CommonPods' do
# ... some other common 3rd-party dependencies here ...
pod 'ARCore/AugmentedFaces', '~> 1.30.0'
target 'TestApp' do
project 'TestApp/TestApp.xcodeproj'
end
target 'Framework' do
project 'Framework/Framework.xcodeproj'
end
end
With that said, partner test app builds just fine.
The problem which we're facing happens right after partner app launch and is always supported by crash:
...
Lots of similar duplication warnings like below comes here
...objc[58698]: Class GARPseudonymousID is implemented in both
/private/var/containers/Bundle/Application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/Frameworks/Framework.framework/Framework
(0x103d9e0d8) and
/private/var/containers/Bundle/Application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/TestApp
(0x10131e440). One of the two will be used. Which one is undefined.
objc[58698]: Class GARPseudonymousIDStore is implemented in both
/private/var/containers/Bundle/Application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/Frameworks/Framework.framework/Framework
(0x103d9e128) and
/private/var/containers/Bundle/Application/21A274AC-31B1-4AE6-9E3F-1BF720C9B221/TestApp.app/TestApp
(0x10131e490). One of the two will be used. Which one is undefined.F0621 20:33:23.600151 1 registration.h:175] Function with name
CallbackPacketCalculator already registered.*** Check failure stack trace: *** dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib
dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib
What we already know:
- Project runs fine on a simulator (as far as we tried), but crashes on real device
- It happens in runtime and only when adding ARCore via CocoaPods and setting pod 'ARCore/AugmentedFaces' both for TestApp and Framework targets.
- It doesn't make any difference if we're trying to reference Framework API in partner app code (via
import Framework
and/or calling its API methods) or not, but: - When setting pod 'ARCore/AugmentedFaces' for TestApp only, it cannot be accessed inside Framework Swift code in compile time.
- When setting pod 'ARCore/AugmentedFaces' for Framework only, we get
No Such Module: ARCore
error via Swift linter right onimport Framework
line (essentially the place where partner app has an entry to our framework, f.e. in AppDelegate or else). Class N is implemented in both...
warning references to all dependencies, but as far as we go only ARCore usage causes crashes and error in log afterwards.- ARCore (obviously) works perfectly fine when being added as pod to any simple iOS app project w/o custom modules including it.
- Removing ARCore pod and references to it completely let us manually test the rest of Framework functionality w/o problems.
We're not still 100% sure if class/method duplication issues cause the crash problem, but we're mostly sure it happens when trying to have an ARCore pod inside the both Framework target and app target (or in abstract target on top level). Anyways, getting rid of the pod in any separate Target causes problems mentioned in upper thesises (with current approach).
Any thoughts or workaround (maybe only except deriving 3rd party source code:)) will be much appreciated!
Edit: now, after making an attempt to add some other 3rd-party packages via CocoaPods and having a successful launch with them embedded excluding ARCore, we realize that crashes should be strictly related to ARCore pod usage.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
因此,经过一些头痛并使用POD/配置播放后,我以某种方式设法成功地启动了以下结构的整个项目,但仅(!)带有发布配置:
至少自定义框架可以访问所有所需的第三方依赖性,并且如今仍可以进行全面测试。
So, after some headache and playing with pods/configurations, I somehow managed to successfully launch the whole project with following structure, but only(!) with Release configuration:
Seems like a bit poor workaround, but at least custom framework has the access to all desired 3rd-party dependencies and remains fully testable as for now.