I'm trying to profile the performance of a legacy project which uses Google's Camera2 API to implement the feature of preview and still image capture.
I found that the preview process occupies too many resources (maybe send too much CaptureRequest?). The preview feature was implemented with SurfaceView. Capture a still image with a preview being set, the still capture's callbacks are invoked can be as slow as 500 to 700 ms delay between session.capture and the callback onCaptureStarted.
With the tool systrace I found that waitForNextRequestBatch takes a very long time actually. Which means the previous preview requests send from setRepeatingRequest are still being processed. So that the Camera data pipeline was blocked. Another evidence is if I disable the preview by comment CameraCaptureSession's function setRepeatingRequest, then the delay time of still capture's callbacks would be reduced significantly.
My question is that is the preview performance issue caused by some special configuration of its request or it was the API/hardware's problem? My device for debugging is Mi9 and I'm sure it fully supports Camera2 API.
One possible solution is to call captureSession.abortCaptures before still session.capture each time. However, the official documentation does not recommend remove pending requests via this method even though they did the same thing in their official Demo.
What's more, I can see a Runtime Exception as follows when using abortCaptures:
Caught a RuntimeException from the binder stub implementation.
java.lang.NullPointerException: Attempt to invoke virtual method 'android.hardware.camera2.CaptureRequest android.hardware.camera2.impl.CameraDeviceImpl$CaptureCallbackHolder.getRequest(int)' on a null object reference
at android.hardware.camera2.impl.CameraDeviceImpl$CameraDeviceCallbacks.onCaptureErrorLocked(CameraDeviceImpl.java:2404)
at android.hardware.camera2.impl.CameraDeviceImpl$CameraDeviceCallbacks.onDeviceError(CameraDeviceImpl.java:2046)
at android.hardware.camera2.ICameraDeviceCallbacks$Stub.onTransact(ICameraDeviceCallbacks.java:137)
at android.os.Binder.execTransactInternal(Binder.java:1021)
at android.os.Binder.execTransact(Binder.java:994)
Do I really need to call abortCaptures to cancel the request from the preview? Or maybe there is some other way I can do to avoid the performance issue? Any help would be grateful. Since the structure of the original is very heavy and messy and I did not have any Android Dev experience before, the information I provided above may be insufficient or inaccurate. By the way, from my perspective without too much Android dev experience, Google's Camera2 API is really poorly designed with little benefit.