Работа с отсутствующими файлами dSYM в ситуации черного ящика - PullRequest
0 голосов
/ 16 января 2019

Мы пытаемся устранить критический сбой в приложении для iOS, которое использует Fabric / Crashlytics. У нас нет контактных данных человека, который последний раз работал над приложением и загрузил последнюю версию в App Store.

В инструментальной панели проекта я заметил сообщение "Обнаружено XXX несимвольных сбоев из-за отсутствующих dSYM в 1 версии за последние 24 часа". Снимок экрана: https://i.imgur.com/YT9gggJ.jpg

Я сделал единственную разумную вещь, о которой только мог подумать: я пошел на панель инструментов App Store Connect. Я скачал dSYM zip для рассматриваемой сборки согласно официальной инструкции от Fabric: https://docs.fabric.io/apple/_images/download-dsym.png

Затем я пошел к инструменту dSYM и загрузил zip-файл напрямую. Оказывается, только два из четырех необходимых файлов были в zip-архиве (я тоже сам проверял): https://i.imgur.com/JqxZcaD.jpg

Итак ... Я нахожусь в ситуации с черным ящиком здесь ...

  • Я не разработчик iOS
  • У меня нет доступа к компьютеру, на котором создавался проект, или к человеку, который создал сборку
  • Я помогаю разработчику iOS, который только что присоединился к команде
  • У меня есть доступ к репозиторию проекта
  • У меня есть доступ к профилю App Store Connect
  • У меня есть доступ администратора в Fabric

Мои вопросы:

  1. Почему два других файла dSYM не были в zip-файле, который я скачал из App Store?
  2. Почему некоторые сбои связаны с одним dSYM, а остальные - с другим? Есть ли какая-либо классификация аварий, к которым у нас есть доступ?
  3. Можем ли мы что-то сделать, чтобы получить доступ ко всем отчетам о сбоях в работе без публикации новой версии приложения в App Store? Мы пытаемся избежать этого сценария банкомата.

РЕДАКТИРОВАТЬ # 1 :

Так что этот человек, который опубликовал сборку, не совсем следовал передовым методам. Я хотел изучить возможность того, чтобы файлы dSYM были переданы в репозиторий сервера.

Это их гитиньор:

.DS_Store 
xcuserdata 
<PROJECT NAME>.xcodeproj/project.xcworkspace/xcshareddata/ 
build/ 
Build/

Я предполагаю, что папка сборки в значительной степени исключает эту возможность. Я также искал файловую структуру для файлов, содержащих текст "com_apple_xcode_dsym_uuids ==", но безуспешно ...

РЕДАКТИРОВАНИЕ № 2:

Я добавляю выдержку из ответа, которую мне дала поддержка Fabric:

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

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

1 Ответ

0 голосов
/ 16 января 2019

Мне кажется, что вам может понадобиться загрузить новую сборку, что не так уж и плохо, если она включает какие-либо исправления ошибок. По вашим вопросам:

Почему два других файла dSYM не были в zip-файле, который я скачал из App Store?

Возможность загрузки dSYM из подключения App Store доступна только в том случае, если приложение распространялось с использованием биткода. Битовый код - это промежуточное представление источника, который App Store использует для создания окончательного оптимизированного машинного кода, предназначенного для конкретной архитектуры / устройства. Когда битовый код выбран, все связанные фреймворки / библиотеки также должны быть доставлены с использованием битового кода, поэтому выглядит странным иметь только некоторые dSYM. Хотя маловероятно, возможно ли, что отсутствующие dSYM из другой сборки?

Почему некоторые сбои связаны с одним dSYM, а остальные - с другим? Есть ли какая-либо классификация сбоев, к которым у нас есть доступ?

Каждая цель / framework / lib генерирует свои собственные dSYM, поэтому ваше приложение, вероятно, зависит от одной или нескольких платформ, и некоторые сбои происходят из этих платформ.

Можем ли мы что-то сделать, чтобы получить доступ ко всем отчетам о сбоях в работе без публикации новой версии приложения в App Store?

Пока не могу придумать другого решения.

...