Скорость загрузки приложений iOS - уровень фонового шума?

Мы только что выпустили приложение, использующее структуру Crittercism. Через некоторое время у нас было около 125 тыс. Загрузок приложений, а 95 сбоев - менее 0,08%.

Одна авария произошла 19 раз, еще 10, но остальные 41 произошли 3 или менее. Если бы были какие-то серьезные проблемы с приложением, я ожидал бы увидеть значительно больше сбоев в определенных областях, поэтому я доволен уровнем цифр, которые я вижу.

Быстрый просмотр показывает, что многие из них являются ошибками низкого уровня, что явно не вызвано, а ошибкой программиста.

<сильные > Примеры

  • Самая большая группа связана с CFNetworking в фоновом потоке, в то время как статический HTML визуализируется в веб-представлении основного потока.
  • Есть некоторые отказы KVO в free_list_checksum_botch

Но мой вопрос, в достаточно сложной ОС (в данном случае iOS), с достаточно сложным приложением (как мне кажется), должен ли я, как разработчик, ожидать увидеть этот уровень "фонового шума"?

Должен ли я ожидать столкновения с одним приложением на 1-2000 загрузок, просто потому, что ОС не идеальна? Кто-нибудь еще имел подобный опыт?

(Я не ищу решения самих ошибок.. спасибо!)

ОТВЕТЫ

Ответ 1

Критерий провел анализ сбоев приложений. Их отчет был основан на сбоях Android vs iOS.

Они пришли к выводу, что самые популярные приложения на iOS crash 0.51% приложений запускаются. Итак, @Ashley Mills, если вы получаете 0,08%... у вас все хорошо. (я думаю, что у меня есть правильные цифры).

Не знаю, где находится исходный отчет, но я прочитал его здесь:

Показатели сбоев в приложениях Forbes, проводимые Crittercism

Ответ 2

Я разработчик iOS, профессионально занятый. Я воспринимаю это лично, когда мои приложения вылетают из строя, потому что это не тот пользовательский опыт, к которому я стремился. Крушение - плохой пользовательский интерфейс. Одного сбоя, на пользователя, слишком много. Авария - ошибка.

Как я уже сказал, я определенно видел журналы сбоев, которые кажутся неразрешимыми, потому что они, похоже, указывают на проблему, которая находится глубоко в SDK. Однако я узнал, что, скорее всего, в моем коде есть что-то, что в конечном итоге является причиной.

Есть несколько необычных сбоев, которые могут быть вызваны проблемами синхронизации между потоками или блоками или просто потому, что я сделал что-то неправильно. Совсем недавно я обнаружил, что делаю что-то совершенно неправильное в отношении сложной таблицы, которую я обновлял. Журналы сбоев для этой проблемы не дали почти никаких указаний, кроме общей области кода, на которую я мог бы обратить внимание. Когда я ворвался в код и начал экспериментировать, я осознал свою ошибку, которая, в конечном счете, была проблемой времени, вызванной тем, что я считал умным разделением основного потока и не-основного потока. В этом случае я был слишком умен для себя.: -)

Итак, подведем итог:

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

Наконец, я предлагаю этот вопрос:

  • Вы готовы мочиться или отклонять некоторых своих пользователей просто потому, что они попадают в 0,08% пользователей, испытывающих сбои?

Пища для размышлений.: -)

Ответ 3

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

Если ваше приложение просто для удовольствия и обучения, то я мог видеть, как копаться в этой проблеме в качестве веселого приключения. С точки зрения бизнеса, каково ваше время и выясняет, что эта проблема составляет 0,08%, чтобы продать достаточно (более) копии, чтобы ваши усилия стоили того.

Аналогичным было бы, какие требования необходимы, а какие требования - желания? Просто пища для размышлений. Я знаю, что многие из компаний, над которыми я работал, не видят значения, подчеркивая этот низкий урожай.

Ответ 4

Я профессиональный разработчик iPhone, и то, что я видел, это частота сбоев, а не то, что расстраивает пользователей, это воронка для того, как происходят сбои.

Если они прерывисты, вы, как правило, в порядке, проблема возникает, когда один пользователь испытывает определенный крах несколько раз. Это неприемлемо.

Стремление удалить каждый крах всегда хорошо, но во многих случаях это просто нереально, вам нужно решить, где лучше всего потратить время. Если у вас есть возможность переработать часть потока UX или исправить прерывистый сбой, вам нужно решить, какой из них больше выгоден для пользователей.

Важно помнить, что если вы решите не исправлять сбой, который происходит 0.08% времени, вы не записываете пользователей, испытывающих это, если они не испытывают его несколько раз.

Ответ 5

Хотя это не технический ответ, на моем iPhone я лично ожидаю, что у меня будет приложение. Я использую многократный сбой хотя бы один или два раза в год. Я бы сказал, что уровень вполне приемлем, и, как правило, я нахожу, что они в первый раз вылетают в первый раз, когда вы начинаете. Я считаю, что это что-то ожидаемое.