Когда «Потребительская сторона» TextureView закрыта?

Question

One of the official Google samples for the Camera2 API страдает от the same BufferQueue has been abandoned problem как видно на:

• What can I do when the BufferQueue has been abandoned?
• Android LogCat shows BufferQueueProcedure

В частности, пример приложения называет closeCamera() метод из onPause() фрагмента, где closeCamera() вызовы close() на CameraCaptureSession , затем close() на CameraDevice, затем close() на ImageReader (используется для фактической съемки). После close() на CameraDevice, когда в LogCat появляется несколько вхождений вышеупомянутого сообщения BufferQueue has been abandoned, хотя я получаю сообщение только на некоторых устройствах Android 5.1 (Nexus 4 и Nexus 7 2013), а не на других (Nexus 5 и Nexus 6). Комментарий

Фадден на это:

Если сторона потребитель закрыли перед входом OnPause(), сообщения можно было бы ожидать.

Когда TextureView «потребительская сторона» будет закрыта, и почему тогда?

Образец кода Google не проактивно ничего не делает, чтобы закрыть TextureView, что я вижу. И, поскольку TextureView все еще может быть видимым при паузе, я бы ожидал, что «потребительская сторона» не будет затронута во время onPause(), но, возможно, позже в onStop().

Хотя я понимаю, что это сообщение (несмотря на то, что оно является ошибкой) является доброкачественным, я пытаюсь выяснить, как избавиться от него, если не по какой-либо другой причине, кроме как предотвратить мое время от времени и снова, почему код моя регистрирует эту ошибку. Я надеюсь, что, понимая больше об этой «стороне потребителя», я могу понять, как лучше убирать вещи, когда пользователь выходит из действия или фрагмента, использующего Camera2, и избегает этой ошибки.

Answer 1

Вы ожидаете вызова метода обратного вызова onClosed для камеры, прежде чем выйти из функции Pause?

До тех пор, пока этот обратный вызов не загорится, камера все еще может выполнять незавершенную работу, а определение close() - завершить все ожидающие запросы на захват перед выключением устройства. Это можно ускорить, вызвав abortCapture() перед вызовом функции close().

Некоторые устройства (например, N5 и N6) в настоящее время блокируют вызов close(), поэтому, когда он возвращается, выполняется все незавершенные работы, но это детализация реализации, которые, как я думаю, наш пример неосторожно полагается на сегодняшний день.

Однако мы обычно хотим разрешить приложениям называть close() и немедленно оставить onPause(), чтобы избежать зависания потока пользовательского интерфейса при ожидании закрытия аппаратного обеспечения камеры. Но сегодня это еще не реальность.

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

Другой причиной, по которой вызов close() и выхода на onPause() не рекомендуется сегодня, заключается в том, что он не позволит другим приложениям открыть камеру в своих вызовах onResume(), что вызовет ложные ошибки при переключении между камерой Программы.

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

Сейчас: Подождите CameraDevice.StateCallback#onClosed будет вызываться до выхода из OnPause() после вызова CameraDevice # близко().

В какой-то будущий момент: будет безопасно просто вызвать close() и выйти onPause; структура будет правильно разрешать подключению следующего приложения, а не спаму вашего журнала. Извините, сегодня это не состояние!

Answer 2

Что касается актуального вопроса - «когда« Потребительская сторона TextureView »закрыта, я не знаю точного времени, но, безусловно, после возвращения onPause.

Грубо, TextureView содержит поверхность GL, и после того, как пользовательский интерфейс для активности больше не виден, эти ресурсы срываются. Как только это произойдет, SurfaceTexture, выданный TextureView, уже недействителен, и все существующие пользователи этой SurfaceTexture (или Surfaces, сделанные из него) начнут получать эти ошибки. Метод TextureView.SurfaceTextureListener.onSurfaceTextureDestroyed должен быть вызван TextureView прямо перед этим.

Так как вы можете возвратить false из onSurfaceTextureDestroyed, чтобы избежать его освобождения во время разрыва пользовательского интерфейса, а вместо этого ждать onClosed для запуска, а затем в onClosed освободить SurfaceTexture TextureView самостоятельно. Тем не менее, я недостаточно хорошо знаком с интерфейсом UI/View, чтобы точно знать, что это сработает, и поскольку некоторые из лежащих в основе нативных поверхностей выпущены в любом случае, вы все равно можете увидеть заброшенные ошибки с этим подходом.

Если вам интересно, верхние уровни соответствующего кода находятся в TextureView, особенно метод destroySurface, хотя вам нужно будет понять все, что касается всей системы Android UI, чтобы разобраться, когда именно метод destroySurface вызывается и каковы его эффекты.