После того, как я изменил некоторый код и запустил приложение в режиме отладки 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
Вещи, которые я уже пробовал без всякого успеха:
Я использую .NET 8.0
ANR происходит, когда основной поток приложения блокируется слишком долго, обычно более 5 секунд. Кто-то может помочь вам в дальнейшем, если будет предоставлен общий доступ к определенной части кода.
@BobSmith, это помогло. Поэтому я попытался удалить некоторую ресурсоемкую строку из App.OnStart
, а именно await MainViewModel.LoadXMLFiles()
. После этого ошибка исчезла, так что я думаю, проблема здесь в await
... сделаю, как вы предложили. Спасибо!
Должен ли я опубликовать это как ответ для вас с подробным объяснением?
@BobSmith, тебе определенно стоит
@FreakyAli опубликовал ответ, посмотрите, и если есть какие-либо возможности улучшения, пожалуйста, предложите.
@mikl взгляните на мой ответ. Если вы все еще сталкиваетесь с проблемой, вам следует поделиться конкретной частью кода. Чтобы я мог ответить точнее.
Часть файла logcat:
[libc] Requested dump for pid 31373 (mycompany.myapp)
[Looper] dumpMergedQueue
[OplusLooperMsgDispatcher] dumpMsgWhenAnr
dumpMsgWhenAnr
указывает, что приложение нужно сбрасывать в случае его сбоя с ANR (ошибка «Приложение не отвечает»), поскольку ваше приложение может выполнять тяжелые операции в основном потоке или использовать слишком много ресурсов устройства. Есть эксплойты, которые выносят длительные операции из основного потока, другие ориентированы на оптимизацию рендеринга и памяти, а последние несколько решают несколько проблем управления потоками. Существует множество инструментов и способов профилирования, которые вы можете использовать в Android Studio
, чтобы найти конкретные проблемы и правильно оптимизировать свое приложение и его производительность.
ANR — это состояние, которое возникает, когда основной поток application
заблокирован на время более пяти секунд или если приложение занято более 10 секунд при использовании BroadcastReceiver. Он получает и обрабатывает широковещательные намерения.
По выводам программы проверьте, что ваши фоновые потоки не вредят системе.
Вот подробности запущенных тем:
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
Следите за фоновыми потоками, чтобы не перегружать систему. Журнал показывает, что несколько потоков в пуле потоков начинаются, о чем свидетельствует следующий формат записи: Убедитесь, что вы не создаете слишком много потоков и, следовательно, не испытываете утечку конфликтов потоков и производительности.
Если у вас возникли трудности с решением какой-то части вашего кода, кто-нибудь может помочь вам больше, если вы представите этот раздел кода.
Реферальные ссылки:
Это идеально, спасибо, Боб
Определенно, это была проблема. Получил await MainViewModel.LoadXMLFiles()
в App.OnStart
, что очень ресурсозатратно. Я последовал вашему совету, поэтому в LoadXMLFiles
я завернул ресурсоемкие части в await Task.Run(async () => { ... })
и проблема решена. В таких случаях я рекомендую добавить немного многопоточности для оптимизации и предотвращения несогласованности, поскольку эти фрагменты кода в Task.Run
будут выполняться асинхронно и параллельно.
Рад узнать, что мои советы помогли вам в правильном направлении и решили вашу проблему.
Большое спасибо @BobSmith, я только начал понимать многие из этих строк вывода и оптимизаций, очень полезно это знать. Также я собираюсь внимательно изучить детали тех строк, которые раньше почти игнорировал.
dumpMsgWhenAnr
Ваше приложение обнаруживает ошибку ANR (приложение не отвечает), вероятно, из-за блокировки операций в основном потоке или чрезмерного использования ресурсов. Эту проблему можно решить, переместив длительные операции из основного потока, оптимизировав рендеринг и использование памяти, а также эффективно управляя потоками. Используйте инструменты профилирования, доступные в студии Android, чтобы выявить конкретные узкие места и соответствующим образом оптимизировать производительность вашего приложения.