Здесь нужно учесть несколько моментов:
а) включение отладки в ваших сборках:
- говорит компиляторам выдавать символы отладки (например, файлы .mdb), которые включают много информации (имена переменных, области действия, номера строк ...);
- добавить дополнительный код отладки в ваше приложение (например, для подключения приложения на устройстве к отладчику на вашем Mac);
- говорит компилятору (например, AOT) отключить некоторые оптимизации (что усложнит отладку);
Это приводит к большим, более медленным приложениям, которые содержат много данных, к которым вы не хотите, чтобы люди обращались (например, если вы боитесь реверс-инжиниринга). Для релизов это нет выигрышной ситуации для всех.
b) использование компилятора LLVM не будет работать в режиме debug . Как правило, это не проблема, так как при отладке вы, вероятно, захотите, чтобы процесс сборки был максимально быстрым (а LLVM собирается медленнее). Проблемным случаем является , если , ваша ошибка обнаруживается только в сборках LLVM.
c) Для доступности трассировки управляемого стека не требуется отладка символов. Они построены из метаданных, доступных в ваших .dll и .exe файлах. Но когда доступны символы отладки, трассировка стека будет включать номера строк и имена файлов для каждого кадра стека.
d) Я никогда не использовал упомянутые вами инструменты, но я верю, что они полезны :-) Возможно, вы захотите задать о них конкретные вопросы (относительно MonoTouch). В противном случае, я думаю, стоит проверить, отличается ли уровень детализации (и могут ли дополнительные подробности помочь вам). ИМО Я сомневаюсь, что это принесет вам больше, чем фактическая «стоимость» доставки «отладочных» сборок.
- сначала создайте в вашем приложении функцию "вышибить меня";
- затем сравните результаты отчетов сборок "release" и "debug", не относящихся к LLVM;
- затем сравните сборки "release" не-LLVM и "release" LLVM;
Было бы приятно опубликовать свой опыт выше: здесь, список рассылки monotouch и / или запись в блоге: -)