CameraX相机启停、生命周期管理及预览相关技术问题咨询

Alright, let's tackle each of your CameraX questions one by one—these are all common pitfalls I’ve run into too, so I’ll share what I know:

1. Lifecycle Binding & Manual Unbinding #

When you use CameraX.bindToLifecycle(this, preview) with a valid LifecycleOwner (like your Fragment), you don’t need to manually unbind—CameraX automatically manages the use case’s lifecycle in sync with your Fragment’s state. It’ll start the preview when the Fragment moves to STARTED and stop it when it goes to STOPPED, and clean up resources when the Fragment reaches DESTROYED.

That said, binding in onCreate() isn’t ideal for preview use cases. The preview relies on a SurfaceTexture (from your TextureView) to render output, and your Fragment’s view hierarchy doesn’t exist yet in onCreate(). Even though CameraX will hold onto the use case, it won’t be able to render anything until you attach a valid surface. The sample app binds in onViewCreated() because that’s when the TextureView is available to link to the preview output.

If you do bind in onCreate(), you’ll still need to set the OnPreviewOutputUpdateListener later (in onViewCreated()) to connect the TextureView, but you might run into edge cases with state synchronization (like the errors you’re seeing when the Fragment is recreated). Stick to binding preview use cases in onViewCreated() for consistency.

2. TextureView Remove/Reattach Step #

The sample app’s step of removing and re-adding the TextureView before replacing the SurfaceTexture is a compatibility workaround for certain devices and layout scenarios. Here’s why it matters:

• TextureView relies on its parent layout to determine its size and rendering context. If the SurfaceTexture from CameraX has a different aspect ratio or size than the TextureView’s current layout, reattaching it forces the view to re-measure and lay out correctly, preventing stretched or cropped preview output.
• Some older devices have issues with SurfaceTexture reuse when the TextureView’s parent hierarchy changes (like when a Fragment is recreated). Removing and re-adding the view resets the TextureView’s internal state, ensuring the new SurfaceTexture from CameraX is properly attached without leftover state from previous sessions.

Is it strictly required? No—you might get away with just replacing the SurfaceTexture on newer devices. But including the step ensures your app works reliably across more Android versions and hardware, which is why the sample includes it.

3. CamX Error Logs After Fragment Reconstruction #

The errors you’re seeing (AEC calibration failures, invalid metadata slots, etc.) are almost certainly due to state mismatches between your Fragment’s lifecycle and the CameraX preview use case. Let’s look at your code:
You bind the preview in onCreate(), which means the use case is tied to your Fragment’s lifecycle even when the Fragment’s view is destroyed (when you switch to GalleryFragment). When you navigate back, the Fragment’s view is recreated, but the original preview use case is still holding onto stale references (like the old SurfaceTexture from the destroyed TextureView). CameraX tries to resume the preview with invalid state, leading to those low-level CamX HAL errors.

Fixes to Try: #

1. Move binding to onViewCreated() (and use view.post {}):

   override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
       super.onViewCreated(view, savedInstanceState)
       view.post {
           CameraX.bindToLifecycle(this, preview)
           preview.setOnPreviewOutputUpdateListener {
               // Optional: Remove and re-add TextureView here for compatibility
               val parent = texture_view.parent as ViewGroup
               parent.removeView(texture_view)
               parent.addView(texture_view, 0)
               texture_view.surfaceTexture = it.surfaceTexture
           }
       }
   }
   

   The view.post {} ensures the TextureView is fully measured and laid out before binding, which avoids size mismatches that can trigger AEC errors.
2. Manually unbind in onDestroyView():
   Even though CameraX should handle this automatically, explicitly unbinding when the view is destroyed clears any stale references:

   override fun onDestroyView() {
       super.onDestroyView()
       CameraX.unbind(preview)
   }
   

3. Reinitialize the preview use case when the view is recreated:
   Instead of using a lazy delegate that keeps the same preview instance across Fragment recreations, create a new Preview instance in onViewCreated():

   override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
       super.onViewCreated(view, savedInstanceState)
       val preview = Preview(PreviewConfig.Builder().build())
       // Bind and set listener as above
   }
   

   This ensures you’re always using a fresh use case with no leftover state from previous sessions.

4. Using OnPreviewOutputUpdateListener Without Binding Use Cases #

No—you can’t use OnPreviewOutputUpdateListener without binding the preview use case to a LifecycleOwner. The listener only triggers when CameraX has an active preview session, which requires the use case to be bound and started (via the LifecycleOwner’s state). Without binding, CameraX never initializes the preview pipeline, so there’s no SurfaceTexture to send to the listener.

The listener is just a way to receive updates when the preview’s output surface changes (e.g., when the device rotates), but it depends entirely on the preview use case being active and bound to a lifecycle.

内容的提问来源于stack exchange，提问作者Nominalista