Is there a reason you would not set -static-link-runtime-shared-libraries to true when compiling an Actionscript project using mxmlc?
If you have several applications for one project making the framework available as an RSL enables the other applications to load it from cache (it has been loaded there by the first app) and save bandwidth and time. If you set static linking to true, every application will contain the framework classes increasing your file sizes.
If you have only one application .swf, linking framework as an RSL can save bandwidth on updates - if only the main .swf changes, you can load it again bypassing the cache but load all the cached .swcs.
Related
I have main application target. And I'm moving some code into frameworks to reduce compile time of the huge project.
Default framework type is Dynamic (BuildSettings -> Mach-O Type). I understand benefits of using Apple's dynamic frameworks as several apps will use the same framework and each application size will be lower (because the app size doesn't include this dynamic frameworks).
But if I'm using my own frameworks and only in my application, why should I choose dynamic frameworks.
It looks like the app size will be bigger with dynamic frameworks Source and application start time will be longer (because it needs to connect all these dynamic libraries, but with static they are already a part of app executable).
App store size probably will be bigger as well with dynamic frameworks as well.
Would be helpful if somebody can fill me in what benefits can we get using dynamic frameworks 🤝
Your assessment is mostly correct.
It is possible to not directly link against frameworks, but instead load them on demand with dlopen.
This can be used both for a plugin system where only one of many available libraries will be needed, or to defer the loading of particularly heavy frameworks, which would actually reduce the launch time of your app.
Further reasons I can think of for using dynamically linked frameworks are:
Licensing reasons.
If you're developing a closed-source library for other developers to use, then a static library normally has a lot more information still embedded than a dynamic library and with a static library you can easily conceal the fact that you're using it, both of which you might not want.
If you have symbol clashes (e.g. due to linking against a static library multiple times, as might be the case with the Rust standard library), then you can split the different codebases into frameworks in order to separate the namespaces.
Does iOS lost most of the advantage of using dynamic frameworks?
Since iOS will copy all the dynamic frameworks needed into the app bundle, it doesn't share dynamic frameworks between apps and save memory. Except for sharing memory with the main app and its extensions.
App using dlOpen can not ship to App Store. Which means Apple disallow dynamic framework from being used officially.
The old Apple document says dynamic frameworks save app launch time, but the new document says they don't. Is the old document outdated?
Here is the comparision:
make the app launch faster and use less memory once it’s launched
Load fewer dynamic libraries. This can be one of the longest parts of an app’s total launch time. Apple recommends using only up to six non-system frameworks
See if you can remove any of the dynamic libraries you’re using by replacing them with static versions or compiling their sources directly.
Does it mean if we use dynamic frameworks with dlOpen to load them later, it will be faster than static frameworks? Because the dynamic frameworks take some time to link in the begining, but they save more time in loading into memory. And loading time of static frameworks is greater then the linking time in dynamic frameworks. Is that true?
So it looks like there is none adavantage of using dynamic frameworks on iOS, right?
And how about on macOS and Linux? Do dynamic frameworks have any advantage? If so, how do they work?
You're correct in all of this. Non-system (i.e. not provided by Apple) dynamic libraries going to be less efficient in pretty much every way on iOS. They give you no space or memory savings, and they cost you at launch time.
The old Apple document you reference was almost entirely written before the iPhone. It's referring to late-loading libraries in Mac apps, which can help launch time.
On systems with shared libraries (or when using system libraries, which are shared on iOS), dynamic libraries save disk space, and can be shared between processes which saves memory and load time (because it's already loaded by some other process). But if you don't share the library, you can't really get any of those benefits. On systems that allow runtime loading of libraries (not iOS), dynamic libraries can delay the cost of loading seldom-used code, possibly indefinitely (if the code is never used). Furthermore, it opens up the opportunities for plugins and other extensions.
As in the Appole doc
it states that:
If you are building your own static library and using shell scripts to
package it in a .framework directory, you need to migrate to building
a framework with a dynamic library instead, as this is the correct way
to build a framework. Static frameworks are not a supported way of
sharing static libraries.
Why Apple disallows static library in a framework?
And is it a contraction of this post ?
Or maybe that post confuses static library and static framework?
All frameworks in iOS are dynamic, right?
Apple said:
A framework is a hierarchical directory that encapsulates a dynamic library, header
files, and resources, such as storyboards, image files, and localized
strings, into a single package. Apps using frameworks need to embed
the framework in the app's bundle.
A static library has to be loaded when app launches, without considering wether if its required right away or not. At the other hand a dynamic library is loaded only when it is required, hence improving the launch timings of the app and decreasing the memory pressure of the phone.
As an example consider I am using an e-commerce app which also allows to scan barcode and give details about the products. Now when I launch the app, I won't need the barcode functionality rightaway. I need to land inside the app first and start shopping. When I need to scan some barcode, I am happy to wait and let the framework loaded then but not at the start of the app.
Here is how Apple says this in its documentation:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Documentation link: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
We are building a large-scale app with AIR for iOS.
One constraint of an AIR app with the iOS packager is that there are no modules. It is possible to load SWF files, but any embedded actionscript code is ignored.
We are wondering what happens to an AIR app for iPad when the code size gets very large. Are you aware of any technique for dividing code up into logical load groups, or do app developers just rely on virtual memory to swap in only a subset (hopefully) of the entire binary image?
No, AIR does not allow package more than one primary SWF.
We have a quite large project and wanted to use modules as well.
Solution we ended up with was removing all embedded sources. That includes graphics and sounds libraries created by Flash IDE or [Embed] classes.
All resources are loaded at runtime using
Sound.load() for mp3/sounds
Loader.load() with asynchronous image decoding policy for png/jpeg/images
FileStream.openAsync() for other/binary data.
We had 36 MB SWF file, now it is only 1.4 MB plus all the external assets.
I have build an app and its in app store aswell. But the app size is more than 20 mb so it can not be downloaded with out wifi or connecting to computer. How can I reduce the app size? I have unziped the ipa file and checked but there is nothing big which can be reduced. So is there a way to compress it more or do some trick to reduce the size of app.
Under i added some of the ways that used in Flash Builder to optimize and reduce Build Size.
If you use custom components make them Model and load through Model Loader.
If you are using Flex Builder or the mxmlc command-line compiler, you can set the
optimize compiler option to true
mxmlc -optimize=true MyApp.mxml
3.When you set the strict compiler option to true, the compiler verifies that definitions
and package names in import statements are used in the application.
4.Implement RSL in your Project - Runtime Shared Libraries
5.Create SWC file of your common code