MapBox - 应用程序在更新到最新SDK时冻结

时间:2018-03-07 15:33:25

标签: android mapbox mapbox-android

我正在为一个客户的项目工作,我必须将现有的Android MapBox SDK(5.1.3)更新到最新的MapBox SDK(5.5.0)。该应用程序在较旧的SDK上运行得非常好,但是一旦我更新了SDK,我的应用程序冻结,显示白屏和/或阻止我的整个UI线程,在延迟后导致ANR。

//Mapbox
implementation('com.mapbox.mapboxsdk:mapbox-android-sdk:5.5.0@aar') {
    transitive = true
}
implementation('com.mapbox.mapboxsdk:mapbox-android-services:2.2.10@aar') {
    transitive = true
}

我的logcat仅在应用程序显示ANR时显示以下错误:

  

线程[3,tid = 28995,WaitingInMainSignalCatcherLoop,Thread * = 0xaa430300,peer = 0x12c638b0," Signal Catcher"]:对信号3作出反应   03-07 16:20:53.831 28989-28995 / package.name I / art:将堆栈跟踪写入' /data/anr/traces.txt'

这是堆栈跟踪:



----- pid 28989 at 2018-03-07 16:20:53 -----
Build fingerprint: 'lge/g3_global_com/g3:6.0/MRA58K/15351124649f4:user/release-keys'
ABI: 'arm'
Build type: optimized
Zygote loaded classes=4378 post zygote classes=1932
Intern table: 42456 strong; 201 weak
JNI: CheckJNI is on; globals=636 (plus 174 weak)
Libraries: /data/app/package/lib/arm/libmapbox-gl.so /system/lib/libandroid.so /system/lib/libcompiler_rt.so /system/lib/libjavacrypto.so /system/lib/libjnigraphics.so /system/lib/libmedia_jni.so /system/lib/libwebviewchromium_loader.so libjavacore.so libopenjdk.so (9)
Heap: 40% free, 5MB/8MB; 46716 objects
Dumping cumulative Gc timings
Start Dumping histograms for 2 iterations for partial concurrent mark sweep
ProcessMarkStack:       Sum: 27.538ms 99% C.I. 0.021ms-23.012ms Avg: 4.589ms Max: 23.259ms
SweepMallocSpace:       Sum: 10.491ms 99% C.I. 0.027ms-6.440ms Avg: 2.622ms Max: 6.444ms
UpdateAndMarkImageModUnionTable:        Sum: 9.937ms 99% C.I. 3.536ms-6.401ms Avg: 4.968ms Max: 6.401ms
MarkConcurrentRoots:    Sum: 6.869ms 99% C.I. 0.006ms-5.420ms Avg: 1.717ms Max: 5.443ms
MarkAllocStackAsLive:   Sum: 4.808ms 99% C.I. 1.282ms-3.526ms Avg: 2.404ms Max: 3.526ms
MarkRootsCheckpoint:    Sum: 3.898ms 99% C.I. 312us-1672us Avg: 974.500us Max: 1672us
ScanGrayAllocSpaceObjects:      Sum: 2.394ms 99% C.I. 1us-1776us Avg: 598.500us Max: 1793us
UpdateAndMarkZygoteModUnionTable:       Sum: 2.344ms 99% C.I. 0.209ms-2.131ms Avg: 1.172ms Max: 2.135ms
SweepLargeObjects:      Sum: 1.729ms 99% C.I. 294us-1435us Avg: 864.500us Max: 1435us
ScanGrayImageSpaceObjects:      Sum: 1.191ms 99% C.I. 285us-906us Avg: 595.500us Max: 906us
ReMarkRoots:    Sum: 1.064ms 99% C.I. 283us-781us Avg: 532us Max: 781us
EnqueueFinalizerReferences:     Sum: 732us 99% C.I. 30us-702us Avg: 366us Max: 702us
SweepSystemWeaks:       Sum: 710us 99% C.I. 205us-505us Avg: 355us Max: 505us
FinishPhase:    Sum: 231us 99% C.I. 80us-151us Avg: 115.500us Max: 151us
ImageModUnionClearCards:        Sum: 220us 99% C.I. 28us-99us Avg: 55us Max: 99us
(Paused)ScanGrayAllocSpaceObjects:      Sum: 206us 99% C.I. 0.333us-190us Avg: 51.500us Max: 190us
MarkNonThreadRoots:     Sum: 183us 99% C.I. 19us-79us Avg: 45.750us Max: 79us




可能导致应用程序崩溃的确切变化是什么?有没有其他人遇到过这个问题?

1 个答案:

答案 0 :(得分:1)

确保在MapView.onStop之前未调用MapView.onDestroy,因为这会导致5.1.5之后的mapbox版本冻结。早些时候你逃脱了合同错误。

例如:有一个包含mapbox.MapView的Fragment。如果Activity在附加/替换新片段之前没有调用Fragment.detach,那么MapView将不会在onDestroy之前获得onPause和onStop调用。

无论如何,对我来说就是这种情况,从应用程序的NavigationDrawer菜单重新加载地图后,应用程序在MapView.onDestroy中冻结了。添加对detach的调用解决了它:

    if (mMapboxFragment != null) {
        // results in calls to fragment's: onPause(), onStop() and onDestroyView():
        FragmentManager fragMgr = getSupportFragmentManager();
        fragMgr.beginTransaction().detach(mMapboxFragment).commit();
    }