Comments (6)
I'm not sure what you mean by "the old lifecycleOwner". The current sample is using the fragment's lifecycle, which usually is the same as the view's lifecycle except CameraFragment
sets the retainInstance flag.
By attaching CameraX to the fragment lifecycle, we avoid CameraX being fully torn down (and thus closing the camera) upon config changes like rotation. The intent is to allow for CameraX to maintain some of its state by doing: CameraX.unbindAll()
→ CameraX.bindToLifecycle()
, which happens during onViewCreated
.
By using the view's lifecycle, the order of events is: CameraX *teardown*
→ CameraX *initialize*
→ CameraX.bindToLifecycle()
. However, I just tested this and it seems that this results in snappier transitions during device rotations on a Pixel 3 device. I'm guessing it's due to the teardown starting as the view gets destroyed, rather than doing everything during onViewCreated
.
I will investigate the potential implications of switching to the view's lifecycle. It's likely that devices with slow camera open/close will have degraded performance using this path. We have to take into consideration other things such as navigation, multi-window environments, etc.
from camera-samples.
Could you please explicitly specify where in the sample CameraX *initialize*
happens?
from camera-samples.
CameraX initialization is not triggered by app code. Some of it happens upon app startup, some of it when the first use case is bound. It's up to the CameraX library and subject to change in the future.
from camera-samples.
Then, returning to original question, it seems that if you would bind to fragment's lifecycle the call stack is
CameraX *initialize*
→ CameraX.unbindAll()
→ CameraX.bindToLifecycle()
→ (rotate) → CameraX.unbindAll()
→ CameraX.bindToLifecycle()
While with viewLifecycleOwner
it is
CameraX *initialize*
→ CameraX.bindToLifecycle()
→ (rotate) → CameraX.bindToLifecycle()
The main concern is when you doing CameraX.unbindAll()
the concept of lifecycle awareness is lost since you bind and unbind it each time manually.
from camera-samples.
While with viewLifecycleOwner it is
CameraX initialize → CameraX.bindToLifecycle() → (rotate) → CameraX.bindToLifecycle()
I don't think this is entirely true. I'm counting camera open as CameraX *initialize*
although maybe I'm not making things very clear. Essentially, by binding to the view's lifecycle, we will be closing and reopening the camera every time we rotate. Whereas binding to the fragment's lifecycle we can even keep some use cases bound across config changes (which we aren't doing yet).
The main concern is when you doing
CameraX.unbindAll()
the concept of lifecycle awareness is lost since you bind and unbind it each time manually.
That's fair feedback, although only partly true. We are just making sure that no other use cases are bound, which is not necessarily a bad practice but, as you say, it kinda defeats the point of making everything lifecycle-aware.
As I said earlier, we will investigate switching to using the view's lifecycle as the owner. Personally, assuming there are no major drawbacks, I think it would be the right choice. It simplifies the code and sets a good example for developers to follow. Otherwise, we are chasing diminishing returns for a slight performance gain, whereas some of the optimizations could be done by CameraX itself. For example, CameraX could wait a bit to close the camera during a config change, since it's likely that an app will bind the same use cases and open the same camera again.
from camera-samples.
Thank you for your response. I close the issue but pls ping me if there would be any updates on this
from camera-samples.
Related Issues (20)
- Where are the "Dual concurrent camera" CameraX Examples? HOT 5
- How to use camerax 1.3.0-alpha04 to open two cameras HOT 7
- Image Analysis results are not the same as Preview
- Camera 2 Pixel Device E/CameraDevice-JV-0( 3086): Receive capture error on unknown request ID 14
- Cannot build Camera2Basic HOT 1
- Camera2.Basic crashes when press button HOT 1
- Text overlay on top of Texture view and render to save it along with video. Camera2 or X api HOT 11
- camera2video hdr hlg->pq
- Concurrent camera error
- OverlayEffect sample code HOT 2
- Update CameraX example? HOT 3
- Incorrect colors - greenish image HOT 1
- Yuv To Rgb Converter
- Camera2Extensions build issue
- CameraX unable save image to internal storage
- androidx.camera.core.ImageCapture$CaptureFailedException: Capture request failed with reason ERROR
- Executors.newSingleThreadExecutor() is never used
- BarcodeScanner implements LifecycleObserver, but close is called manually
- VideoRecordEvent.Finalize.ERROR_INSUFFICIENT_STORAGE is never called
- Unresolved reference: cameraId
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from camera-samples.