У меня проблема, когда Mobile Safari падает при загрузке и обработке DOM с помощью jQuery, когда страницы становятся слишком большими.
Я получаю ту же проблему как на iPhone, так и на iPad.
Каков наилучший способ устранения неполадок на мобильных страницах, чтобы найти ошибку? Существуют ли какие-либо известные проблемы, которые могут привести к сбою Mobile Safari?
Я действительно нашел проблему. Это было не с JS, как я думал, а с CSS. Я добавил класс, чтобы сделать переход CSS для постепенного исчезновения в некоторых элементах. Для анонимных пользователей эти элементы имели display: none; и, вероятно, никогда не выполняли переход непрозрачности.
Странно то, что переходы были на ровно двух элементах. Так почему это только крах на длинных потоках с более 100 комментариями?
Итак, нижняя строка: -webkit-transition разбила страницу на мобильном сафари.
Если бы та же проблема, для меня это было -webkit-transform: translateZ(0);, вызвало сбой Safari.
Я знаю, что этот вопрос успешно ответил, но я просто хотел поставить свои пять центов, так как я несколько раз ударял головой о стену над этим:
Как уже указывалось в большинстве ответов, это обычно сводится к проблемам с памятью. Почти все может быть последним битом, который, наконец, кончается над "кучей памяти" так же, как translateZ или что-то еще.
Однако по моему опыту это не имеет никакого отношения к фактической команде CSS (или JS) в конкретном. Просто случается так, что последний переход был слишком большим.
Что мне очень помогает, так это сохранить то, что не видно в настоящее время в разделе display: none. Это может показаться примитивным, но на самом деле делает трюк. Это простой способ сказать рендереру браузера, что вам не нужен этот элемент в это время, и, следовательно, освобождает память. Это позволяет создавать вертикальные скроллеры длиной в милю с любыми 3D-эффектами, пока вы скрываете элементы, которые вы не используете в настоящее время.
Основная проблема с любым приложением iOS - использование памяти. Таким образом, вероятно, что ваши страницы используют слишком много памяти.
Mobile Safari использует некоторые умные методы, так что не вся страница должна находиться в памяти в любой момент времени, только часть ее. Возможно, вы могли бы проверить, не ли ли что-либо на вашей странице побеждает этот механизм или делает его менее эффективным.
В любом случае, чтобы дать более точные предложения, более подробная информация о вашей странице будет очень большой.
Кстати, у вас могут быть некоторые подсказки из журнала сбоев, которые хранятся в устройстве. Проверьте, можете ли вы найти его в разделе "Настройки":
Если это проблема с памятью, вы должны найти что-то вроде "signal (0)"; не уверен, что это может означать только "убитый из-за использования памяти", но я обычно принимаю это как должное, когда обнаружил сигнал (0).
В противном случае он может сказать вам, что не так...
Надеюсь, что это поможет.
Имеются ограничения на использование памяти и время выполнения Javascript, хотя это немного нечетко относительно того, как вы можете нанести им удар. Общие отчеты заключаются в том, что страница с размером более 10 МБ будет иметь проблемы, а выполнение Javascript ограничено 10 секундами.
Подробнее см. Документация Apple.
Недавно у меня возникла проблема с сбоем сафари в мобильных устройствах на страницах веб-приложений, содержащих много изображений (было достаточно 30+) и несколько преобразований для меню. После большого количества проб и ошибок я решил с решением, аналогичным тому, что LinkedIn, но для бесконечной прокрутки с использованием угловых символов. Я использовал requestAnimFrame и два расширяющихся/сокращающихся divs (с атрибутами стиля js) в верхней и нижней части списка, чтобы удалить все контейнеры изображений (с другими наложениями сверху) за исключением нескольких, которые близки к окну просмотра. Производительность прокрутки (native, no js) прекрасна и потребление памяти проверяется.
У меня была аналогичная проблема, веб-страница работала как шарм на устройствах Android и разбилась на IOS (iphone и симулятор).
После большого исследования (с использованием также ios_webkit_debug_proxy) я обнаружил, что проблема была связана с событием готовности jQuery.
Добавление небольшого тайм-аута решило проблему. Мое приложение также использовало iframes.
$(document).ready(function () {
window.setTimeout(function () { ready(); }, 10);
});