Asynchronous operations

Favor using asynchronous versions of operations rather than synchronous ones, where available.

Synchronous operations run as soon as your code tells them to, and your code waits for them to complete before moving on. Consequently, they run in the application code phase of the frame loop. If a synchronous operation takes too long, it stretches the size of the frame loop, potentially causing the display to appear to freeze or stutter.

When your code executes an asynchronous operation, it doesn’t necessarily run immediately. Your code and other application code in the current execution thread continues executing. The runtime then performs the operation as soon as possible, while attempting to prevent rendering issues. In some cases, the execution happens in the background and doesn’t run as part of the runtime frame loop at all. Finally, when the operation completes the runtime dispatches an event, and your code can listen for that event to perform further work.

Asynchronous operations are scheduled and divided to avoid rendering issues. Consequently, it is much easier to have a responsive application using asynchronous versions of operations. See Perceived performance versus actual performance for more information.

However, there is some overhead involved in running operations asynchronously. The actual execution time can be longer for asynchronous operations, especially for operations that take a short time to complete.

In the runtime, many operations are inherently synchronous or asynchronous and you can’t choose how to execute them. However, in Adobe AIR, there are three types of operations that you can choose to perform synchronously or asynchronously:

  • File and FileStream class operations

    Many operations of the File class can be performed synchronously or asynchronously. For example, the methods for copying or deleting a file or directory and listing the contents of a directory all have asynchronous versions. These methods have the suffix “Async” added to the name of the asynchronous version. For example, to delete a file asynchronously, call the File.deleteFileAsync() method instead of the File.deleteFile() method.

    When using a FileStream object to read from or write to a file, the way you open the FileStream object determines whether the operations execute asynchronously. Use the FileStream.openAsync() method for asynchronous operations. Data writing is performed asynchronously. Data reading is done in chunks, so the data is available one portion at a time. In contrast, in synchronous mode the FileStream object reads the entire file before continuing with code execution.

  • Local SQL database operations

    When working with a local SQL database, all the operations executed through a SQLConnection object execute in either synchronous or asynchronous mode. To specify that operations execute asynchronously, open the connection to the database using the SQLConnection.openAsync() method instead of the method. When database operations run asynchronously, they execute in the background. The database engine does not run in the runtime frame loop at all, so the database operations are much less likely to cause rendering issues.

    For additional strategies for improving performance with the local SQL database, see SQL database performance .

  • Pixel Bender standalone shaders

    The ShaderJob class allows you to run an image or set of data through a Pixel Bender shader and access the raw result data. By default, when you call the ShaderJob.start() method the shader executes asynchronously. The execution happens in the background, not using the runtime frame loop. To force the ShaderJob object to execute synchronously (which is not recommended), pass the value true to the first parameter of the start() method.

In addition to these built-in mechanisms for running code asynchronously, you can also structure your own code to run asynchronously instead of synchronously. If you are writing code to perform a potentially long-running task, you can structure your code so that it executes in parts. Breaking your code into parts allows the runtime to perform its rendering operations in between your code execution blocks, making rendering problems less likely.

Several techniques for dividing up your code are listed next. The main idea behind all these techniques is that your code is written to only perform part of its work at any one time. You track what the code does and where it stops working. You use a mechanism such as a Timer object to repeatedly check whether work remains and perform additional work in chunks until the work is complete.

There are a few established patterns for structuring code to divide up work in this way. The following articles and code libraries describe these patterns and provide code to help you implement them in your applications:

// Ethnio survey code removed