Отладка MAUI USB Android завершается с ошибкой после изменений в коде

После того, как я изменил некоторый код и запустил приложение в режиме отладки USB на физическом телефоне Android, отладка прекращается через несколько секунд после запуска приложения, в то же время приложение переходит в фоновый режим и «очищается». Когда я возвращаю приложение на передний план, оно перезапускается и работает правильно на телефоне, однако в любом случае оно уже отключено от Visual Studio. Чтобы предотвратить возникновение сбоя, мне нужно удалить приложение с устройства, но если я снова изменю код, оно снова начнет давать сбой.

Не сообщается ни об исключении, ни о обратной трассировке, и когда это происходит, выходных данных очень мало.

Вот последние строки вывода об этом сбое:

[OpenGLRenderer] Davey! duration=1053ms; Flags=0, FrameTimelineVsyncId=750240, IntendedVsync=11939588219664, Vsync=11940621552956, InputEventId=0, HandleInputStart=11940627184818, AnimationStart=11940627189245, PerformTraversalsStart=11940627835078, DrawStart=11940628308047, FrameDeadline=11940638251820, FrameInterval=11940626035339, FrameStartTime=16666666, SyncQueued=11940630990078, SyncStart=11940631119089, IssueDrawCommandsStart=11940631489245, SwapBuffers=11940636915703, FrameCompleted=11940642056224, DequeueBufferDuration=36198, QueueBufferDuration=440990, GpuCompleted=11940642056224, SwapBuffersCompleted=11940638637161, DisplayPresentTime=0, CommandSubmissionCompleted=11940636915703,
Thread started: .NET Timer #8
[Quality] Skipped: false 3 cost 53.28309 refreshRate 16669135 bit true processName com.mycompany.myapp
[VRI[MainActivity]] Received frameCommittedCallback lastAttemptedDrawFrameNum=3 didProduceBuffer=true syncBuffer=false
[VRI[MainActivity]] draw finished.
[VRI[MainActivity]] reportDrawFinished
[Quality] Skipped: false 6 cost 110.21765 refreshRate 16667980 bit true processName com.mycompany.myapp
[Quality] Skipped: false 1 cost 18.913912 refreshRate 16667282 bit true processName com.mycompany.myapp
[OplusScrollToTopManager] com.mycompany.myapp/crc6476ca92efe8ec1437.MainActivity,This DecorView@88d844b[MainActivity] change focus to true
[mycompany.myapp] Explicit concurrent copying GC freed 13427(558KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 6259KB/12MB, paused 26us,14us total 12.446ms
[monodroid-assembly] open_from_bundles: failed to load assembly System.Xml.XmlSerializer.dll
Loaded assembly: /data/data/com.mycompany.myapp/files/.__override__/System.Xml.XmlSerializer.dll [External]
Thread started: <Thread Pool> #9
Thread started: <Thread Pool> #10
Thread started: <Thread Pool> #11
Thread started: <Thread Pool> #12
Thread started: <Thread Pool> #13
Thread started: <Thread Pool> #14
Thread started: <Thread Pool> #15
[ProfileInstaller] Installing profile for com.mycompany.myapp

*** At this point everything looks normal, the app is running and usable,
but then it gets "cleared" and the only output I get are the following lines: ***

[libc] Requested dump for pid 31373 (mycompany.myapp)
[Looper] dumpMergedQueue
[OplusLooperMsgDispatcher] dumpMsgWhenAnr

Вещи, которые я уже пробовал без всякого успеха:

  • Очистка и восстановление решения
  • Очистка, удаление папок obj и bin и восстановление решения.
  • Перезапуск телефона Android
  • Перезагрузка компьютера
  • Обновление Visual Studio
  • Удаление приложения (работает снова до следующего изменения кода)

Я использую .NET 8.0

dumpMsgWhenAnr Ваше приложение обнаруживает ошибку ANR (приложение не отвечает), вероятно, из-за блокировки операций в основном потоке или чрезмерного использования ресурсов. Эту проблему можно решить, переместив длительные операции из основного потока, оптимизировав рендеринг и использование памяти, а также эффективно управляя потоками. Используйте инструменты профилирования, доступные в студии Android, чтобы выявить конкретные узкие места и соответствующим образом оптимизировать производительность вашего приложения.
Bob 05.06.2024 23:03

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

Bob 05.06.2024 23:05

@BobSmith, это помогло. Поэтому я попытался удалить некоторую ресурсоемкую строку из App.OnStart, а именно await MainViewModel.LoadXMLFiles(). После этого ошибка исчезла, так что я думаю, проблема здесь в await... сделаю, как вы предложили. Спасибо!

mikl 05.06.2024 23:22

Должен ли я опубликовать это как ответ для вас с подробным объяснением?

Bob 06.06.2024 06:07

@BobSmith, тебе определенно стоит

FreakyAli 06.06.2024 10:37

@FreakyAli опубликовал ответ, посмотрите, и если есть какие-либо возможности улучшения, пожалуйста, предложите.

Bob 06.06.2024 12:58

@mikl взгляните на мой ответ. Если вы все еще сталкиваетесь с проблемой, вам следует поделиться конкретной частью кода. Чтобы я мог ответить точнее.

Bob 06.06.2024 13:00
2
7
89
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Часть файла logcat:

[libc] Requested dump for pid 31373 (mycompany.myapp)
[Looper] dumpMergedQueue
[OplusLooperMsgDispatcher] dumpMsgWhenAnr

dumpMsgWhenAnr указывает, что приложение нужно сбрасывать в случае его сбоя с ANR (ошибка «Приложение не отвечает»), поскольку ваше приложение может выполнять тяжелые операции в основном потоке или использовать слишком много ресурсов устройства. Есть эксплойты, которые выносят длительные операции из основного потока, другие ориентированы на оптимизацию рендеринга и памяти, а последние несколько решают несколько проблем управления потоками. Существует множество инструментов и способов профилирования, которые вы можете использовать в Android Studio, чтобы найти конкретные проблемы и правильно оптимизировать свое приложение и его производительность.

ANR — это состояние, которое возникает, когда основной поток application заблокирован на время более пяти секунд или если приложение занято более 10 секунд при использовании BroadcastReceiver. Он получает и обрабатывает широковещательные намерения.


Диагностика проблемы:

1. Длительные операции в основном потоке

2. Тяжелый рендеринг или операции пользовательского интерфейса

3. Неэффективное использование памяти.

4. Управление потоками

По выводам программы проверьте, что ваши фоновые потоки не вредят системе.

Вот подробности запущенных тем:

Loaded assembly: /data/data/com.mycompany.myapp/files/.__override__/System.Xml.XmlSerializer.dll [External]
Thread started: <Thread Pool> #9
Thread started: <Thread Pool> #10
Thread started: <Thread Pool> #11
Thread started: <Thread Pool> #12
Thread started: <Thread Pool> #13
Thread started: <Thread Pool> #14
Thread started: <Thread Pool> #15

Следите за фоновыми потоками, чтобы не перегружать систему. Журнал показывает, что несколько потоков в пуле потоков начинаются, о чем свидетельствует следующий формат записи: Убедитесь, что вы не создаете слишком много потоков и, следовательно, не испытываете утечку конфликтов потоков и производительности.


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

Реферальные ссылки:

Это идеально, спасибо, Боб

FreakyAli 06.06.2024 13:00

Определенно, это была проблема. Получил await MainViewModel.LoadXMLFiles() в App.OnStart, что очень ресурсозатратно. Я последовал вашему совету, поэтому в LoadXMLFiles я завернул ресурсоемкие части в await Task.Run(async () => { ... }) и проблема решена. В таких случаях я рекомендую добавить немного многопоточности для оптимизации и предотвращения несогласованности, поскольку эти фрагменты кода в Task.Run будут выполняться асинхронно и параллельно.

mikl 06.06.2024 16:19

Рад узнать, что мои советы помогли вам в правильном направлении и решили вашу проблему.

Bob 06.06.2024 16:21

Большое спасибо @BobSmith, я только начал понимать многие из этих строк вывода и оптимизаций, очень полезно это знать. Также я собираюсь внимательно изучить детали тех строк, которые раньше почти игнорировал.

mikl 06.06.2024 16:31

Другие вопросы по теме

Похожие вопросы