Considering we have already done the following actions:
Flex Framework as RSL
Compiling with debug=false
Loading most images at runtime
Drawing other simple images with flash draw features
Reducing complex images with pngquant
Creating modules for secondary features
Applying ranges to fonts
Running FlexPMD to find dead code and bad copy-paste
Running FlashOptimizer and secureSWF (with poor results)
Today our application is 1358k:
Code: 978k - 72%
Images: 270k - 20%
Fonts: 110k - 8%
We believe we spent a lot of time into asset optimization and most of the work is remaining on the code.
By analyzing our link-report, our guess is that the heavy part of the code is comming from Flex .mxml nested components. We don't think there is much to do on our pure AS classes.
Is there any analysis or coding best practice in order to reduce the impact of the code on the swf filesize ?
Thanks.
Here is the application : http://www.pearltrees.com/nicolas/137698/
In my practice I usually don't have big final swf files, so I want to mention only one thing. Using mxmlc directly we should not forget to add (for the final build of course) parameter/attribute
debug = "false"
in other way final swf will be almost 2 times bigger.
do you have an objects in the .mxml that are similar to each other that you could turn into a generic class and customize programatically?
Consider looking into preloaders and modules.
Without knowing your application, it's hard to be specific, but a custom preloader can sometimes help a lot with perceived download time. Let's face it, asking the user to idly stare at a progress bar is sad, and you can do better.
The usual example here is that your need your application users to login, or select some basic details before jumping into the main application. By implementation that first form as a preloader, your application will keep downloading in the background while your user interacts with that form.
The downside: Your preloader code doesn't have access to all the Flex goodness. You'll have to draw your UI and implement your interaction in plain old AS3. Still, the extra work can be worth it in some situations.
Flex Modules are the other thing that'd be worth looking into. In a complex Flex app, not everything is commonly used. If you cut the lesser-used bits from the main application and move them into a module you load on-demand, you may be able to save a fair amount of bytes from the initial download size.
Related
One of the most annoying things when working with Flash/Flex projects is that it takes soo long to build the project. In a Flash game I am doing, it takes more than one minute to build it...
So, the question is simple: Is that normal? Am I doing something wrong? Is there a way to minimize this?
A common way of avoiding the long build-times is to divide your project up into multiple projects and reference them in as SWC's in a Main project.
Actually the shorter build times are mostly considered a positive side effect, as any larger project really ought to be divided into multiple project. Typically you will have more than one library project, handling the service layer/ controller ect.
This way you could for move the controller/ game logic to one project. This would have longer intervals between changes, and therefore you could close this project, building only the one you are currently working in.
If you are using a lot of assets from Flash ect. move those to a SWC as well.
A simple tip that makes compile time from the Flash IDE a bit shorter: Go to 'publish settings' > actionscript 3.0 > settings > disable 'Warnings Mode'
This mode checks if you are using actionscript 2.0 functions. If you know what you are doing (not copy/paste as2.0 code into as3.0 projects), you'll never need these 'warnings'.
Another tip is to use lots of SWC's: if you are using a tweenengine or a framework; most of them are available as SWC files. Use them.
Yes, it is normal. it can take more if your projects get bigger and bigger.
I have a flex project that a full build (using ANT not flex builder) takes 4 minutes.
The best advice I can give you on the subject and is an SSD drive, an SSD drive installed on my Mac cut the times by more then 50%.
I've found embedding assets tends to delay build times considerably. It's hardly noticeable at first but after a while they start stacking up and build time increases.
Maybe try delaying embedding assets a long as you can.
I am working on a flex application.The application occupies 100% of the browser screen, but it is slow to load.How should i improve the performance, what are the best techniques one should follow for improving the performance of a flex App.
I did try some stuff though, i am not using relative layout instead i am using absolute layout and putting the buttons/images etc at exact places in a Canvas, still i feel it is slow.Can i profile the App or flex code to see where exactly the app is taking the maximum time to execute.
Adobe offers a great article about this topic: Flex Application Performance: Tips and Techniques for Improving Client Application Performance
Here are some great resources on improving performance of not only your Flex app, but of Actionscript in general:
Quick as a Flash Presentation by Grant Skinner - Optimizing Actionscript
Round up of Actionscript and Flex Optimizations
Flex Application Startup Performance
Actionscript Performance Tuning
Overall, some key things to always do:
Keep nesting thin: Don't nest too many VBoxes and Canvases, that will make your app dramatically lag/freeze
Don't Embed: Only embed things that are very small and need to show up immediately (icons in skins for example)
Deferred Instantiation: Only add what the user needs to see. Everything else will wait until the user goes there.
Explicitly size all item renderers. If DataGrid item renderers aren't explicitly sized, your app might freeze for an instance when constructing it.
Optimize Assets for the Web (icons ~< 20k, large images ~< 200k as a rule of thumb).
Refactor to remove excessing curly-bracket Binding (width="{something.other.width/4}"). Causes a bunch of events to be dispatched that you likely don't need. Too many events == too many temporary objects == lag.
People recommend using Modules to decrease swf size and only load what you need, but if your application isn't as large as a CMS, you generally don't need them.
Flex Builder Professional has a built-in profiler that works pretty well for profiling your own code. If the problem is drawing performance and layout, it's not as helpful (it profiles the code just fine, but it's harder to understand the results and apply them in a useful way to changes in your code).
I've recently started making a game in FlexBuilder. The game is currently a Flex project.
Is there any downside to using Flex as opposed to just Actionscript?
A friend of a friend told me that Flex is slower than an Actionscript project. I've been unable to validate this on the internet; is there any truth to that claim?
Thanks!
If you're developing a game, you should be using an ActionScript project. Flex is to be used only for data driven applications and user interfaces.
The flex compiler generates a lot of intermediate code to convert mxml files into actionscript (you can view those files if you compile with -keep compiler option). This code, the flex framework incorporated to your SWF, adds significantly to the size.
Create an actionscript project with a textfield ("hello world") and a flex project with a label with the same text. Build them, go to their bin-debug folders and compare the file sizes. While actionscript one is only a couple of kilobytes, flex swf would be at least a 100 kB.
As far as speed is concerned, since the flex framework is sitting on top of actionscript, it obviously would have a performance downside.
The beauty of flex lies in the easiness to create UI components and developing data driven applications that frequently communicates with the server.
Don't use it unless you truly need it.
If you know flex and it helps you developing faster - do it in flex.
Download size doesn't matter for game with a lot of assets. Most popular flash games have size of 5 MB and more. (for example on kongregate)
Crucial part of game you can make in pure actionscript. Placing hundreds UIComponents to Canvas could doesn't slow in Flex, but Flex rending technology prevent smooth animation of objects.
Conclusion:
Flex is for rapid development. You can use it's easy skinnable components for menu. Even without Flex UI components binding is matter and makes life easier.
Download size = speed on the Internet. The smaller you can make your game, the faster it will load. Size also equals speed in an interpreted language like ActionScript, where the less code you have to execute, the faster it will run. Hand-coding an ActionScript routine might let you make it faster than the generalist approach of Flex.
That said, maybe you'd be willing to pay that overhead to avoid having to write a lot of utility classes in pure ActionScript. Your high-score screen would be easier to do in Flex, for example, and that might be worth the overhead to you. It won't matter if your high-score screen is a little slower, since it isn't a real-time thing like the actual game.
Also consider the cost of your time. By using Flex, you'll be done with those parts of your app faster than if you hand-code them in ActionScript. Unless your time is free, you should be thinking about how this trades off against the bandwidth cost of the Flex overhead. It might be that it's cheaper to pay the bandwidth than your time making a more efficient program.
A Flex Application won't necessarily run slower than a Pure AS3 application once it's fully loaded - everything gets compiled down to bytecode in the end, and a Flex App is like an AS3 app that uses a LOT of other classes.
Think of the Flex Framework as a set of shortcuts that allow you to do things much more quickly, but the real cost is that your project gets filled up with a LOT more code - even if you're actually writing less code, and you never have to see the additional code.
I would disagree with the assertion that Flex should only ever be used for complex data-driven applications, though it's certainly very useful for such projects. You can use it for anything, as long as you understand that the final product (the .swf you export) is going to be a lot larger than it might otherwise be.
If having a large .swf is not that big a deal to you (and it might not be, depending on what you're doing with it) then I'd say give Flex a try because ArrayCollection, RemoteObject and Data-Binding will save you hours of frustration and hundreds of lines of code.
However, if you want to make sure your final app is as small and efficient as possible, do it in pure AS3 and simply opt-in to more advanced libraries as you need them.
Flex provides a framework for building Rich Internet Applications. If your game requires a complicated GUI (such as an RPG), it might be useful. Otherwise, it adds layers that will complicate things if all you want to do is build a game.
As said above in the first point the only beverage is memory consume. But if u write in pure AS script you need to be in deadline combat. As flex provide lots of customizable comps. U can use Class files instead of MX Comps that save the Memory. Do not Create any components unless it is being used. Modules and RSLs are avail to acheive the peretainity
I'm creating a project in flex builder but it's not using the flex framework, it's just pure actionscript.
At the moment I have some bitmap resources embedded for drawing things, but I'd like a little animation and thought I could create swf animations for them in flash and use the [Embed()] thing to embed them in the actionscript project.
This works perfectly well for me, however I'm a little concerned about efficiency and how well this approach will scale when my project gets larger.
Does anyone know if there are any efficiency implications to embedding maybe 20 or 30 swf files, or do they get efficiently integrated into the main swf file? Most of the animations are really simple and I could probably redo them in actionscript if needed but it's a lot easier just to draw them in flash and embed them.
Not too sure exactly what you mean by efficiency, but embedding a large number of files is generally not considered best practice. You generally only want to embed things that need to show up immediately when the application loads, or that are so small it would be overkill to load them via URLLoader and the like.
Say you only view 5 of your animated swfs at startup, and the as the user clicks around and goes to different screens/views, they are revealed the rest. Then you could just load the swfs at runtime via URLLoader or the Flex Module architecture.
The benefit of having your swfs and assets not embeddded in your main swf is that:
it dramatically decreases swf size
it makes it easier to swap out graphics at runtime (or without needing to compile)
If I were you I would remove as many [Embed] tags as possible, and replace them with either loading via modules or urlloader.
Best,
Lance
I do a lot of work with GWT but don't have experience of Flex. I was talking to a guy today who was looking at moving some large Flex based applications to GWT due to the Flex application getting too big and using too much memory in the browser. This is a problem I have had before with GWT - browser apps using lots of memory as all the code gets loaded when it starts.
However, in GWT 2.0 there is now a code splitting feature to overcome the problem of the client code getting too big. This allows all the code (javascript) not to be loaded as one big file on start up but instead code split into different files that can be loaded when required.
I was thinking as to if there is anything similar in Flex. I assume the Flex application code all lives in one single SWF file which loads at start-up so this approach is not possible but thought there might be other solutions.
You might want to look into Modules. Otherwise the code is in one SWF. You can also move the Flex framework code out of yur SWF. And you can always dynamically load your resources such as images.