When I learn NSURLCache documentation I can't find many important notes.
I found that many topics in web complain that NSURLConnection that use NSURLCache had memory leaks. When I tried to write some application for iOS 4.3 I found that MSURLCache have some strange behavior.
In application:didFinishLaunchingWithOptions: I set instance of NSURLCache with memory capacity 10MB, init NSURLRequest with NSURLRequestUseProtocolCachePolicy but I can't recieve connection:willCacheResponse: message in my NSURLConnection delegate. When I checked memory capacity in different points of my application, it was 0MB. Why? May be Apple fix some memory leaks by setting NSURLCache memory capacity to 0? I created custom NSURLCache and overrided setMemoryCapacity: method by this:
-(void)setMemoryCapacity:(NSUInteger)memoryCapacity {
if (memoryCapacity > 0) {
[super setMemoryCapacity:memoryCapacity];
}
else {
NSLog(#"zero here");
}
}
Then I started to debug. There is some input text in my app, where user put some url. New setMemoryCapacity: method has been called twice: in my app delegate, when I set capacity to 10MB and (it is very interesting) when user set focus to text input (parameter of memoryCapacity was 0 and I recieve "zero here" string in log). After that I recieved connection:willCacheResponse: messages to NSURLConnection delegate.
It was very strange. I can't understand why. I can't find things in manual about this. Do you have some thoughts?
Related
My watchOS app uses core data for local storage. Saving the managed context is done in background:
var backgroundContext = persistentContainer.newBackgroundContext()
//…
backgroundContext.perform {
//…
let saveError = self.saveManagedContext(managedContext: self.backgroundContext)
completion(saveError)
}
//…
func saveManagedContext(managedContext: NSManagedObjectContext) -> Error? {
if !managedContext.hasChanges { return nil }
do {
try managedContext.save()
return nil
} catch let error as NSError {
return error
}
}
Very rarely, my context is not saved. One reason I can think of is the following:
After my data are changed, I initiate a background core data context save operation.
But before the background task starts, the watch extension is put by the user into background, and is then terminated by watchOS.
This probably also prevents the core data background save to execute.
My questions are:
- Is this scenario possible?
- If so, what would be the correct handling of a core data background context save?
PS: On the iOS side, I do the same, but here it is possible to request additional background processing time using
var bgTask: UIBackgroundTaskIdentifier = application.beginBackgroundTask(expirationHandler: {
//…
application.endBackgroundTask(bgTask)
}
By now, I think I can answer my question:
If the watch extension is put by the user into background, the extension delegate calls applicationDidEnterBackground(). The docs say:
The system typically suspends your app shortly after this method
returns; therefore, you should not call any asynchronous methods from
your applicationDidEnterBackground() implementation. Asynchronous
methods may not be able to complete before the app is suspended.
I think this also applies to background tasks that have been initiated before, so it is actually possible that a core data background save does not complete.
Thus, the core data save should be done on the main thread. My current solution is the following:
My background context is no longer set up using persistentContainer.newBackgroundContext(), since such a context is connected directly to the persistentContainer, and when this context is saved, changes are written to the persistent store, which may take relatively long. Instead, I now set up the background context by
var backgroundContext = NSManagedObjectContext.init(concurrencyType: .privateQueueConcurrencyType)
and set its parent property as
backgroundContext.parent = container.viewContext
where container is the persistent container. Now, when the background context is saved, it is not written to the persistent store, but to its parent, the view content that is handled by the main thread. Since this saving is only done in memory, it is pretty fast.
Additionally, in applicationDidEnterBackground() of the extension delegate, I save the view context. Since this is done on the main thread, The docs say:
The applicationDidEnterBackground() method is your last chance to
perform any cleanup before the app is terminated.
In normal circumstances, enough time should be provided by watchOS. If not, other docs say:
If needed, you can request additional background execution time by
calling the ProcessInfo class’s
performExpiringActivity(withReason:using:) method.
This is probably equivalent to setting up a background task in iOS as shown in my question.
Hope this helps somebody!
I'm developing an Angular/ Typescript application that makes use of the Autodesk Forge viewer to display building models on smartphones and tablets. The application itself runs smoothly, but the problem occurs when I close the application. After closing the application, I notice that hardly any memory gets released, as can be seen in the image below (I close the application around the 8 seconds mark) and after opening the viewer for two or three more times it will run out of memory and crash.
When I close the application, I call both the tearDown() and the finish() method as described in the Forge docs and set all possible references to the Forge viewer to null, but they memory leak still persists. This is the main chunk of my viewer code:
this.initOptions = {
path: 'url to model',
env: 'Local',
useADP: false,
extensions: [],
};
Autodesk.Viewing.Initializer(this.initOptions, () => {
this.onEnvInitialized();
});
private onEnvInitialized() {
this.viewer = new Autodesk.Viewing.Private.GuiViewer3D(this.viewerContainer.nativeElement, {});
this.viewer.initialize();
this.viewer.loadModel(this.initOptions.path, {}, (doc) => {
// further forge viewer execution here
}, (errorMsg) => {
console.log(errorMsg);
});
}
public ngOnDestroy() {
// remove all eventlisteners
this.initOptions = null;
this.viewer.tearDown();
this.viewer.finish();
this.viewer = null;
}
Is this a known issue and/ or is there some way I can manually release the memory used by the Forge viewer after closure? (It is part of the use case that I have to be able to open more than three viewers after each other in one session.)
Update [19-09-17]
I tried opening my viewer in a fresh, empty angular2 project, and although less memory is being used in general, the same behavoir of not clearing the memory still applies, as can be seen here. I do notice that the event listeners are drastically reduced now. I also updated the Forge Viewer to version 2.17, and the same issue still applies here as well.
The problem remains with version 3.3.5 of the forge viewer. The issue however seems a bit deeper. It looks like when calling viewer.finish() it doesn't release any GPU memory used for the textures.
We call this function everytime you navigate away from the page with the viewer as angular destroys the canvas in the DOM. I would expect .finish to also remove the textures from the memory. Is there any other function that can be called to completely unload any model and textures?
Here are some screenshots where you can see the memory buildup.
Initial initialisation of the page
after returning to this page after closing it
after returning to this page after closing it a third time
What version of the Viewer are you currently using? Here you can see a list of the recent changes on the viewer version, v2.17 has a Memory Limit ON by default.
https://developer.autodesk.com/en/docs/viewer/v2/overview/changelog/
Also the version of the viewer can be checked if it is not been defined from the console by typing LMV_VIEWER_VERSION
I'm reading a CoreData database in a WatchKit extension, and changing the store from the parent iPhone application. I'd like to use NSFetchedResultsController to drive changes to the watch UI, but NSFetchedResultsController in the extension doesn't respond to changes made to the store in the parent application. Is there any way to get the secondary process to respond to changes made in the first process?
Some things to try/consider:
Do you have App Groups enabled?
If so, is your data store in a location shared between your host app and the extension?
If so does deleting the cached data, as referenced here help?
Read this answer to very similar question: https://stackoverflow.com/a/29566287/1757229
Also make sure you set stalenessInterval to 0.
I faced the same problem. My solution applies if you want to update the watch app on main app updates, but it could be easily extended to go both ways.
Note that I'm using a simple extension on NSNotificationCenter in order to be able to post and observe Darwin notification more easily.
1. Post the Darwin notification
In my CoreData store manager, whenever I save the main managed object context, I post a Darwin notification:
notificationCenter.addObserverForName(NSManagedObjectContextDidSaveNotification, object: self.managedObjectContext, queue: NSOperationQueue.mainQueue(), usingBlock: { [weak s = self] notification in
if let moc = notification.object as? NSManagedObjectContext where moc == s?.managedObjectContext {
notificationCenter.postDarwinNotificationWithName(IPCNotifications.DidUpdateStoreNotification)
}
})
2. Listen for the Darwin notification (but only on Watch)
I listen for the same Darwin notification in the same class, but making sure I am on the actual watch extension (in order to avoid to refresh the context that just got updated). I'm not using a framework (must target also iOS 7) so I just added the same CoreDataManager on both main app and watch extension. In order to determine where I am, I use a compile time flag.
#if WATCHAPP
notificationCenter.addObserverForDarwinNotification(self, selector: "resetContext", name: IPCNotifications.DidUpdateStoreNotification)
#endif
3. Reset context
When the watch extension receives the notification, it resets the MOC context, and sends an internal notification to tell FRCs to update themselves. I'm not sure why, but it wasn't working fine without using a little delay (suggestions are welcome)
func resetContext() {
self.managedObjectContext?.reset()
delay(1) {
NSNotificationCenter.defaultCenter().postNotificationName(Notifications.ForceDataReload, object: self.managedObjectContext?.persistentStoreCoordinator)
}
}
4. Finally, update the FRCs
In my case, I was embedding a plain FRC in a data structure so I added the observer outside of the FRC scope. Anyway you could easily subclass NSFetchedResultsController and add the following line in its init method (remember to stop observing on dealloc)
NSNotificationCenter.defaultCenter().addObserver(fetchedResultController, selector: "forceDataReload:", name: CoreDataStore.Notifications.ForceDataReload, object: fetchedResultController.managedObjectContext.persistentStoreCoordinator)
and
extension NSFetchedResultsController {
func forceDataReload(notification: NSNotification) {
var error : NSError?
if !self.performFetch(&error) {
Log.error("Error performing fetch update after forced data reload request: \(error)")
}
if let delegate = self.delegate {
self.delegate?.controllerDidChangeContent?(self)
}
}
At WWDC ‘17, Apple introduced a number of new Core Data features, one of which is Persistent History Tracking or NSPersistentHistory. But as of the time of writing, its API is still undocumented. Thus, the only real reference is the What’s New in Core Data WWDC session.
More info and an example here
We are currently rendering 50-100 canvas on browser window. Browsers both IE and chrome crashes.
On further investigation, looks like memory is creeping up steadily. Causing browser to crash.
We are building a solution to print charts To achieve this,
We are displaying all the charts in a simple page (iframe) charts are not visible to user
Using chart id to getting image data.
Since charts are not visible we can ‘destroy’ or remove them from memory once they are rendered.
But ‘destroy’ does not reduce charts memory footprint
Tried setting object to null. this did not work either
Attached snippet for your reference,
var runner = 0
zingchart.complete = function (dataObj) {
for (i = 0; i < ZingChartCollection.length; i++) {
if (dataObj["id"] == ZingChartCollection[i].ChartId) {
var data = zingchart.exec(dataObj["id"], "getimagedata", '{"filetype": "png"}');
zingchart.exec(dataObj["id"], 'destroy');
zingchart.exec();
if (runner < 200) {
document.getElementById("displayCount").value = runner;
render();
}
else {
//zingchart = null;
}
runner++;
}
}
}
Any suggestions would be great.
Here's a note regarding the issue from the ZinChart dev team:
The issue here is that the render() -> complete event -> image generation -> destroy() is a closed loop.
The way the ZingChart lib works, in order to fire the complete as soon as possible, the code was binding the context menu events AFTER the complete was fired.
So, since destroy was being called immediately, the context menu events were left out in the open, and with 50-100 charts it starts to add, leading to memory leaks.
This will be changed & fixed in the next versions in order to fire the complete event after the context menu setup, however, with the current setup, there are two options:
use mode:static on render() since the idea is to get the static image out of the chart. This skips event binding so memory leak will no longer be an issue.
Also, since less canvas objects will be used, this will dramatically decrease the memory needed per chart.
if you need the complete functionality of the charts (although not needed in this particular case), call the destroy() in a delayed function via setTimeout. This will allow
for the context menu events to be set, so destroy() will also unbind them.
Titanium SDK version: 1.7.0
iPhone SDK version: 4.2
I am developing an iOS app and I monitor the memory usage for each window And it keeps decreasing for every screen.
What is consuming memory in general? I use views, tables and XHR data.
How can I release memory / decrease usage on each window?
Thankful for all input!
Considering you are dealing with JavaScript being translated to Objective-C and can't necessarily write a native solution without using modules you could start by setting window variables to null (myJsWindowVar = null;), or delete those variables using delete (delete myJsWindowVar;). Personally I think setting variables to null will better translate to the suggested Objective-C best practice which is to set a pointer reference to null and prevent orphaned objects from hanging around.
Make sure you close unused windows and clear our any references to native objects you no longer need in the app.
// create a window object
var aWindow = Ti.UI.createWindow();
var aLabel = Ti.UI.createLabel({ text : "Hey" });
aWindow.add(aLabel);
aWindow.open();
// done with window
aWindow.close();
aWindow = null;
aLabel.null;
Check out this presentation from the Appcelerator Codestrong conference for more details.