Google Map crashes in IOS7

后端 未结 11 2235
予麋鹿
予麋鹿 2020-12-12 14:59

We are developing an Hybrid app and we are using google map API in our application. When we are trying to load 2000 data markers in the map, it got crashed. Map is not get c

相关标签:
11条回答
  • 2020-12-12 15:30

    Having experienced similar problems with Google Maps I tried to isolate a minimal test case. I wanted to see if this was perhaps a more general memory management issue.

    This code that just stores random data in an array crashes Safari on IOS 7 on an iPad mini, 16GB:

    function randomString(length, chars) {
        var result = '';
        for (var i = length; i > 0; --i) result += chars[Math.round(Math.random() * (chars.length - 1))];
        return result;
    }
    
    var arr = []
    for (var i=0;i<5000;i++) {
        // one character is two bytes in JavaScript, so 512 chars is 1Kb:
        o = randomString(512, '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ');
        arr.push(o);
    }
    

    You can try this test with your own browser by going http://vici.org/memtest.html . The script on that page will try to claim 50Mb of memory, in steps of 1Mb. The script shows a running counter so you will see how well your browser performs and when it crashes (if it does). The script stores the results for each ip / user agent combination in a database to be able to draw some conclusions.

    On average, IOS 6 (n=12) allows a script to claim about 12Mb. IOS 7 (n=47) allows a script to claim around 15 Mb. These are not hard limits. For both sets the standard devation was quite high, ~12 Mb. In the Xcode emulator Safari doesn't even crash at all (claiming the full 50Mb, probably because it has access to more RAM).

    So we may conclude that the issue is not caused by IOS 7 leaving less memory for Safari. The problem seems to be, as was suggested by Philipp Kühn, that -in some specific cases? - Safari consumes significantly more memory than it did in IOS 6. One clue about the cause can be found at https://discussions.apple.com/message/23837361#23837361 where a page with 200 divs and the following CSS

    div {
      -webkit-backface-visibility: hidden;
    }
    

    crashes safari.

    It appears that using the Leaflet library circumvents the maps issue (see https://code.google.com/p/gmaps-api-issues/issues/detail?id= and https://github.com/Leaflet/Leaflet/pull/2149) however Leaflet circumvented the low memory crashes not by changes on the css but on the javascript level. Leaflet now circumvents statements like

    context = this
    

    This would suggest Safari doesn't clean up unused objects. As long as Apple doesn't fix Safari, perhaps Google could do changes similar to what the Leaflet guys have done?

    In the mean time Apple has release IOS7.1 which doesn't fully solve the crashes but certainly makes them occur les often.

    0 讨论(0)
  • 2020-12-12 15:30

    We have the same issue with Labels on google map. When map zoom in app get crashed. This started to happen after upgrade in to IOS 7. I am trying different options like remove and add label in events like "drag" and "idle". This code works but still crash occur. but less often. I hope someone might have better fix for this.

        google.maps.event.addListener(Map.gmap, 'drag', function () {
                $('.arrowSite_box').remove(); // remove labels
        });
    
        google.maps.event.addListener(Map.gmap, 'idle', function () {
            loadMarkers(results); // add labels
        });
    
    0 讨论(0)
  • 2020-12-12 15:32

    Our application behaved in the same as the users above; everything worked well prior to iOS 7, yet crashed afterwards. The problem indeed does appear to be a memory issue. You can verify by checking the crash report logs on your device.

    As our application was essential to a client, we couldn't sit and wait for a fix from Apple. In our case, the fix involved three specific strategies:

    1. Javascript code optimization. Our application was developed very quickly and turned from a prototype into a working system without extensive code planning. In our system, we were able to realize significant memory gains by optimizing the code. This meant deleting unused variables; take a look if you happen to store all the markers into a preliminary array as a response from your database. Delete these old arrays and unused variables once everything is loaded successfully. In addition, consider limiting included libraries, and employ common Javascript / jQuery best optimization practices.

    2. Empty info windows. The next memory-saving strategy came from NOT pre-loading each marker's info window screen with data. We stripped each info window bare, except for an empty div with unique ID, which would then be loaded asynchronously on click through Ajax. The savings from many thousands of markers, when you take all of that unnecessary info window data out, were fairly large. We were loading around 10,000 markers. The user experience wasn't greatly impacted either because the difference pre-loading and Ajax load times was negligible.

    3. The greatest difference, and perhaps a clue as to where the iOS 7 memory leak lies, came from simply reducing the number of markers displayed on the screen at once. Each application will be different, but we discovered that lowering the results to 500 markers or less resulted in a stable system without crashing. Our strategy was simply to load and clear the array of visible markers based on user behaviour. For example, if the user's particular filter selection resulted in more than 500 markers, we simply limited the results from the database. Visually, the result set still seems large, and is not much different, from a user experience perspective, from seeing many thousands of markers. In both situations, the user will still need to filter and narrow the results to get down to a manageable result. In our case, the user wouldn't even notice the limit.

    This did the trick! Our application is now crash free. Considering the amount of time (not to mention frustration!) this issue caused me, hopefully these strategies will give you a jumping off point to get your application back up and working. Feel free to get in touch if you wanted something a little more specific. Good luck!

    0 讨论(0)
  • 2020-12-12 15:34

    We have a webapplication, that chrashes too with many markers on iOS7. So we took a closer look at the memory the iPad use.

    iPad mini (and iPad3) with iOS7:

    The memory usage is getting higher and higher and between 300-400MB the browser chrashes.

    iPad 3 with iOS6

    The memory usage is about 200MB and everything is fine.

    iPad 1 with iOS5

    The memory usage is only about 100MB and everything is fine.

    Conclusion

    So this is NOT just a memory limit – it's definitely a huge bug on the iOS safari! And until now (iOS 7.0.3) this is not fixed.

    0 讨论(0)
  • 2020-12-12 15:35

    Seems to be fixed in iOS 7.1

    Yesterday on iOS 7.0.6, my map would crash Mobile Safari with more than 3,000 markers. Today after upgrading my iPad, I can load a map in Mobile Safari with over 15,000 markers.

    0 讨论(0)
  • 2020-12-12 15:41

    If you are dealing with a large number of markers, try using the MarkerClusterer. It will lower the number of concurrent markers significantly, and in our case it prevented the crash.

    0 讨论(0)
提交回复
热议问题