Подтвердить что ты не робот

Сбой карты Google в IOS7

Мы разрабатываем гибридное приложение, и мы используем API карты google в нашем приложении. Когда мы пытаемся загрузить 2000 маркеров данных на карте, он разбился. Карта не попадает в IOS6, IOS5. Это происходит только в IOS7. Есть ли какое-либо изменение, связанное с памятью, для приложения ios7.

4b9b3361

Ответ 1

Как уже говорилось, iOS7 более строг с использованием памяти. Такое поведение наблюдается в других браузерах, таких как Chrome, поэтому, когда приложение достигает верхнего предела в использовании памяти, появляется авария.

Я выделил два тестовых примера, используя только API-интерфейс Gmaps javascript и jQuery:

Тестирование с помощью 100 маркеров: все в порядке

http://jsfiddle.net/edfFq/6/embedded/result

Тестирование с помощью 3000 маркеров: происходит сбой

http://jsfiddle.net/edfFq/7/embedded/result/

$(document).ready(function () {
    var map;
    var centerPosition = new google.maps.LatLng(40.747688, -74.004142);


    var options = {
        zoom: 2,
        center: centerPosition,
        mapTypeId: google.maps.MapTypeId.ROADMAP
    };
    map = new google.maps.Map($('#map')[0], options);


    for (var i=0;i<2800;i++){        
      var position = new google.maps.LatLng(40*Math.random(),-74*Math.random());
      var marker = new google.maps.Marker({
            position: position,
            map: map           
        });
    }
});

Вы можете получить сбой с меньшим количеством маркеров, если ваша карта использует: метки, пользовательские значки и кластеры.

Ответ 2

Испытывая аналогичные проблемы с Картами Google, я попытался изолировать минимальный тестовый пример. Я хотел посмотреть, было ли это, пожалуй, более общая проблема управления памятью.

Этот код, который просто хранит случайные данные в массиве, разбивает Safari на IOS 7 на 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);
}

Вы можете попробовать этот тест со своим собственным браузером, перейдя http://vici.org/memtest.html. script на этой странице попытается запросить 50 Мб памяти с шагом 1 Мб. script показывает счетчик работы, поэтому вы увидите, насколько хорошо работает ваш браузер и когда он сработает (если это произойдет). script хранит результаты для каждой комбинации ip/user agent в базе данных, чтобы иметь возможность сделать некоторые выводы.

В среднем IOS 6 (n = 12) позволяет script требовать около 12 Мб. IOS 7 (n = 47) позволяет script требовать около 15 Мб. Это не трудно. Для обоих наборов стандартное отклонение было довольно высоким, ~ 12 Мб. В эмуляторе Xcode Safari даже не сбой вообще (заявка на полный 50Mb, вероятно, потому, что у него есть доступ к большему количеству оперативной памяти).

Итак, мы можем заключить, что проблема не вызвана тем, что IOS 7 оставляет меньше памяти для Safari. Кажется, проблема, как предложил Филипп Кюн, - в некоторых конкретных случаях? - Safari потребляет значительно больше памяти, чем в IOS 6. Один ключ к этой причине можно найти в https://discussions.apple.com/message/23837361#23837361, где страница с 200 divs и следующий CSS

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

сбрасывает сафари.

Похоже, что использование библиотеки Leaflet обходит проблему с картами (см. https://code.google.com/p/gmaps-api-issues/issues/detail?id= и https://github.com/Leaflet/Leaflet/pull/2149), однако Leaflet обошел низкие потери памяти, а не изменения на css, а на уровне javascript. Листовка теперь обходит положения, подобные

context = this

Это означает, что Safari не очищает неиспользуемые объекты. Пока Apple не исправляет Safari, возможно, Google может делать изменения, аналогичные тем, что сделали ребята из Leaflet?

В то же время Apple выпустила версию IOS7.1, которая не полностью разрешает сбои, но, конечно же, делает их часто встречающимися.

Ответ 3

У нас есть веб-приложение, которое также содержит много маркеров на iOS7. Поэтому мы внимательно рассмотрели память iPad.

iPad mini (и iPad3) с iOS7:

Использование памяти становится все выше и выше и между 300-400 МБ браузерами.

iPad 3 с iOS6

Использование памяти составляет около 200 МБ, и все в порядке.

iPad 1 с iOS5

Использование памяти составляет всего около 100 МБ, и все в порядке.

Заключение

Итак, это НЕ только ограничение памяти - это определенно огромная ошибка на сафари iOS! И до сих пор (iOS 7.0.3) это не исправлено.

Ответ 4

Хорошие новости! мы переключили нашу инфраструктуру приложений с google на листовку, и она работает красиво, без сбоев, мы проверили отладочную версию, и она работает с чрезвычайно высокой памятью, но никогда не сбой. Если вы еще не вошли в Листовку, она полностью работает на iOS 7,

Ответ 5

Наша заявка вела себя так же, как и пользователи выше; все прошло хорошо до iOS 7, но потом рухнуло. Проблема действительно является проблемой памяти. Вы можете проверить, проверив журналы отчетов о сбоях на вашем устройстве.

Поскольку наше приложение было важно для клиента, мы не могли сидеть и ждать исправления от Apple. В нашем случае исправление включало три конкретные стратегии:

  • Оптимизация кода JavaScript. Наше приложение разработано очень быстро и превратился из прототипа в рабочую систему без расширенное планирование кода. В нашей системе мы смогли реализовать значительная прибыль от памяти за счет оптимизации кода. Это означало удаление неиспользуемые переменные; обратите внимание, если вам удастся сохранить все маркеры в предварительный массив в качестве ответа из вашей базы данных. Удалить эти старые массивы и неиспользуемые переменные, когда все загружено успешно. Кроме того, рассмотрим ограничение включенных библиотек и используйте общие методы оптимизации Javascript/jQuery.

  • Пустые информационные окна. Следующая стратегия сохранения памяти исходила от НЕ предварительная загрузка каждого окна информационного окна маркера с данными. Мы разделили каждое информационное окно   голый, за исключением пустого div с уникальным идентификатором, который затем будет   загружается асинхронно при нажатии Ajax. Экономия от многих   тысячи маркеров, когда вы берете всю эту ненужную информацию   оконные данные были довольно большими. Мы загрузили около 10 000   маркеры. На пользователя не оказало большого влияния либо потому, что   разность предварительной загрузки и время загрузки Ajax были незначительными.

  • Наибольшая разница и, возможно, подсказка о том, где iOS 7   утечка памяти - это просто уменьшение количества маркеров   отображается на экране одновременно. Каждое приложение будет отличаться,   но мы обнаружили, что снижение результатов до 500 маркеров или менее   привели к созданию стабильной системы без сбоев. Наша стратегия была   просто загрузить и очистить массив видимых маркеров на основе пользователя   поведение. Например, если пользовательский выбор фильтра   привело к более чем 500 маркерам, мы просто ограничили результаты   из базы данных. Визуально набор результатов по-прежнему кажется большим, и   не сильно отличается от перспективы использования пользователей,   видя много тысяч маркеров. В обеих ситуациях пользователь будет   по-прежнему необходимо фильтровать и сузить результаты, чтобы   управляемый результат. В нашем случае пользователь даже не заметил бы   предел.

Это трюк! Наше приложение теперь без сбоев. Учитывая количество времени (не говоря уже об разочаровании!), Этот вопрос вызвал у меня, надеюсь, эти стратегии дадут вам возможность спрыгнуть с места, чтобы вернуть ваше приложение и работать. Не стесняйтесь связываться, если хотите что-то более конкретное. Удачи!

Ответ 6

Я считаю, что у IOS7 есть память объемом 5 Мб (более продолжительное время работы от батареи), она была 50 Мб или что-то в этом роде. Поскольку кепка ограничена ОС, поэтому не имеет значения, используете ли вы Chrome, Safari или другие браузеры, она будет сбой, если она будет превышена.

i проверил мой предел получаемых данных на 20 из SQL, и он работает во всех браузерах на моем iphone (pad).

Ответ 7

У меня была такая же проблема, и я попробовал несколько вещей. Я отключил анимацию, когда установлены маркеры (у меня было около 30 добавленных одновременно), и похоже, что она больше не разбивается. Надеюсь, это поможет.

Ответ 8

У нас та же проблема с ярлыками на карте google. Когда масштабирование карты в приложении будет разбито. Это произошло после обновления до IOS 7. Я пытаюсь использовать различные параметры, такие как удаление и добавление метки в событиях, таких как "перетаскивание" и "простоя". Этот код работает, но все же происходит сбой. но реже. Надеюсь, кто-то может лучше исправить это.

    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
    });

Ответ 9

Если вы имеете дело с большим количеством маркеров, попробуйте использовать MarkerClusterer. Это значительно уменьшит количество параллельных маркеров, и в нашем случае это предотвратит крах.

Ответ 10

Хей... Я тоже столкнулся с подобной проблемой. Итак, я пробовал это:

Я очистил кэши приложений в методе "didReceiveMemoryWarning" моего контроллера и пользовательских плагинов и установил свойства и переменные в NIL в методе "onMemoryWarning" класса CDVPlugin. И этот подход сделал для меня работу. На данный момент я не получаю краха. Надеюсь, это поможет.

Ответ 11

Кажется, исправлено в iOS 7.1

Вчера на iOS 7.0.6 моя карта разбила Mobile Safari с более чем 3000 маркерами. Сегодня после обновления моего iPad я могу загрузить карту в Mobile Safari с более чем 15 000 маркеров.