|
I implemented code in onAppear that resizes the image by the height value via the GeometryReader closure parameter size before the image is shown. However, when I build the app, a blank image appears. If I resize the height value using the code UIScreen.main.bounds.height * 0.5, the image works fine. Could it be that onAppear is executed before the view appears, so it can't get the proxy.size.height value of the GeometryReader? Is there any way to work around this? (I would like to implement the resizing code in onAppear to avoid wasting resources, since the image is redrawn every time it is scrolled).
|
|
|
|
Using the original image as is will use a lot of memory, so I want to show the image after resizing before showing it on the screen. |
|
Are you loading a list using a ForEach? If yes, then you could load the visible items and unload the non visible items. |
|
Yes, the first screen, the main view, used List(ForEach). Doesn't List do lazy processing automatically? The code in my question used a Scroll View rather than a List because the second screen, the one that appears when you tap on a particular item in the first screen, only shows a picture of that item and some information about it. I want to resize the image only once, when it is onAppear, because the view is constantly redrawn due to the shadow handling that dynamically changes with the scroll offset. |
|
As far as I know Lists, LazyVGrid they load in a "lazy" manner but they do not unload.. In my App I have a View that loads ALL the saved images in the App, the more I was scrolling the more the Ram consumption was going off the roof..eventually I applied the rule I mentioned above. What I did is to control/record the ids of the images that were visible on the screen, once they appear they were entering a temporary images array once dissappeared they were being removed, keeping the ram under control ;) |
|
So how do we know if we've gotten rid of the images stored in the temporary array? Did you nil the visible images in onDisappear? I'm having the same problem. The memory is building up...🫨🫠 |
|
|
|
This helped me free up a little more memory, thank you. My app is also storing images along with the information of the clothes (I store them directly in coredata as a binary data type). That's why scrolling through the list is taking 20-40% CPU. After running the app for a few minutes, I can feel the heat. I don't know what part of the app is causing the heat. The item edit screen, detail screen, shows the image downscaled via Image I/O. Additionally, what do you prefer between List and ScrollView + LazyVstack? As items are added, the amount of scrolling increases, and I'm torn between List and ScrollView + LazyVStack. |
|
Why do you store your images as Data? I store them in the FileManager and just call them using their location string. Personally I use ScrollView+LazyVStack since I like to use custom cells. |
|
Because of CoreData + CloudKit support, I saved the image directly to CoreData. If I store only URLs in Core Data and images in Documents, won't the images stored in Documents be deleted when the user deletes the app? |
|
If I build my app when I have 100 items, it will use the ScrollView + LazyVStack
List
Each row has an image view, three text views. The problem is that removing the image from each row consumes similar CPU.😂 How to upload an image here... |
|
If you delete the App yes the images will be deleted from your phone. If you use CloudKit you should be able to save locally the images on the device and call them using their URLs and push a copy also to the cloud. Once you delete the app the images leave from the phone but if you are syncing with cloudkit you should be able once you download / install the app back to get your data + images back. I haven't use CloudKit so maybe I am not the best to answer this. If you want share the code that loads each Item view, maybe the culprit is there. |
|
"call them using their URLs and push a copy also to the cloud" This part... I think you need to study more. "If you want share the code that loads each Item view, maybe the culprit is there." I'm not sure what you mean by this sentence, do you mean the @ObservedObject property wrapper in each child view? |
|
Like I said, I never used CloudKit but from a quick search I did, plus chatGPT confirmed it can be done. Most probably I explained very poorly what I meant. "If you want share the code that loads each Item view, maybe the culprit is there." Somewhere you have a ForEach that draws the Item view for each item, maybe there you have something that is more CPU intensive. |
|
I've been searching for days and going through the code from scratch to find the cause, but I don't know.🥲 |
GO FURTHER, FASTER Unleash your full potential as a Swift developer with the all-new Swift Career Accelerator: the most comprehensive, career-transforming learning resource ever created for iOS development. Whether you’re just starting out, looking to land your first job, or aiming to become a lead developer, this program offers everything you need to level up – from mastering Swift’s latest features to conquering interview questions and building robust portfolios.
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.