Our compressed data wouldn’t be very valuable if we couldn’t later restore it to its original form. This means that you do not need to (and should not) manually deallocate the buffer memory at this stage. It’s worth noting that using this approach causes our Data to take ownership of the allocated bytes of the buffer, and puts that memory under the standard Swift memory management rules we’re familiar with for Foundation objects. Let encodedData: Data = NSData(bytesNoCopy: destinationBuffer, length: compressedSize) as Data Guard let inputData = jsonString.data(using. We’ll also grab the input data size while we’re at it, as we’ll want to reference it later.
Swift mac os framework code#
Note: the JSON itself is omitted below, but you can use any example JSON string to quickly test this code out. To start, we’ll get an actual Data object from our JSON string. JSON typically contains a considerable amount of repetition, so we can expect significant size savings by compressing the data before we save it to disk. And although we’re focusing on local storage here, compression is also an important consideration for network requests and bandwidth usage. Let’s imagine we’re working on an iOS or macOS app that needs to save a large JSON payload to disk. Now let’s take a closer look at how you can easily and quickly reduce the size of stored data. Apple provides brief descriptions of the available algorithms and when to use them in the Compression.Algorithm enumeration docs. If you’re not as concerned with platform compatibility you may consider a different algorithm. In this post we’ll be using ZLIB (which internally is built around DEFLATE), as it is a commonly-used algorithm for general data compression and has widespread cross-platform support. (All of the compression algorithms offered by Apple’s Compression framework are lossless.) Choosing an Algorithm
Swift mac os framework full#
JPEG compression is a classic example of a lossy algorithm, and if you’ve ever seen an internet image that was full of artifacts, you’ve witnessed the result of this data loss.įor most computing applications, lossless algorithms are necessary to ensure data integrity, so that is what we’ll be using here. In general, they reduce the size of data by identifying repetition and creating a new intermediary data representation which eliminates this ‘waste of space.’ There are two broad categories of algorithms: lossy and lossless-the key difference being that lossy algorithms actually result in a loss of the input data, meaning the exact input data can’t necessarily be restored in full after decompression. There are a wide variety of compression algorithms available.
Apple’s Compression FrameworkĪvailable in iOS 9.0+ and macOS 10.11+, Compression simplifies the process of leveraging a number of common compression algorithms such as ZLIB, LZMA, LZFSE, and LZ4. Although many compression algorithms can be complex to implement from scratch, thankfully Apple has made it easy with their Compression framework. In some cases it may make sense for you to compress this data yourself to reduce the required storage space. If you’re developing an app for iOS or macOS you may find yourself storing a variety of custom data on the user’s device including: application support files, temporary data, cached images, etc. iPhone and iPad users can quickly find their relatively large solid-state drives filling up with media or apps. With today’s modern iOS and macOS devices, disk space is relatively abundant, but developers still need to be careful about how they manage their application data. In the early days of Apple, disk space was a precious and limited resource. Using Apple’s Compression Framework on iOS & macOS Size Matters
0 kommentar(er)
