I don't understand the part about embedded assets. Can you provide more details? The -externs option should let you keep any class out of any SWF.
You can create a shared code module or pack other classes needed by modules onto extra frames of the main SWF. -Alex On 12/3/13 4:05 PM, "David Coleman" <david_coleman_...@hotmail.com> wrote: >I do agree with your numbers, (how could I not - they are spot on). The >primary issue is that WE host the rsl or the static link difference. and >the static link difference affects the size of our modules too. So it's >100% more for modules, and since we have 7.8 MB of modules (18 different >popups each with animations/hd graphics etc), then we are talking about >static linking costing a lot more. > >If i can customize an RSL to service all 18 modules and the main app and >only have to distribute one file, that is even better for a new user than >the Adobe RSL's... ok we have to pay for the CDN costs... but it's less >than an extra 7.8 MB of static links for all our modules. > >Harbs pointed out the exact reason RSL is so critical to our use case. >Modules are doubled. > >Now, if the modules could only statically link what is lacking in the >static links of the main application, with out optimizing them and >pushing all the embedded assets to the main application... kinda like a >"half-optimized" module, then static link could really work for us. but >as long as an optimized module will push all the assets into the main >app, i can't optimize them to share the static links. so they need their >own static links... > >Maybe this is something that can work! > >how can i optimize a module to share the static links of the main app >without pushing all the embedded assets in the module to the main app? >does mxmlc include a metatag to exclude a class (embedded asset) from >module optimization? so it would stay in the module while i optimize it >for the main app, and then only have to statically link the few bits and >pieces that are lacking in each. > >> From: aha...@adobe.com >> To: dev@flex.apache.org >> Date: Tue, 3 Dec 2013 15:51:44 -0800 >> Subject: Re: SharedLibrary not works with SDK 4.11 >> >> OK, so let me make sure I understand: >> >> For first time users, they have to download 3MB of Assets and the 600K >>SWF >> and hopefully not the 1.4MB's of framework RSLs. >> For returning users, 3MB Assets and 600K SWF is hopefully in the browser >> cache. >> >> If you switch to Apache Flex: >> First-time users will have to download either >> 1) 3MB of Assets, 600K of SWF and 1.4MB of RSLs from your CDN. >> 2) 3MB of Assets and 1.2MB of SWF if you statically link. >> >> So, Apache Flex statically linked is another 600K and represents an >> additional 12% in download time. >> >> I don't know what the RSL penetration is of Flex 4.5.1, but every day >> folks are buying new computers and there are fewer and fewer Flex 4.5.1 >> apps out there in the world so the probability your first-time customers >> will have those RSLs is diminishing. Over time, more and more of your >> customers will be downloading the 1.4MB of framework RSLs as well, and >>the >> statically linked solution will be the smaller download. >> >> Have you used ItDepends or a similar link-report analyzer to see how >>much >> of that 600K is Greensock, Tweener and other stuff? >> >> -Alex >> >> On 12/3/13 3:11 PM, "David Coleman" <david_coleman_...@hotmail.com> >>wrote: >> >> >Upon re-reading this I realize that I didn't understand your question. >> > >> >What it will save us is that in the majority of instances, we will >> >benefit from the cached RSL. >> > >> >And we will be able to still push smaller files so that NEW users do >>not >> >see a jump in the time that it takes to open the app. >> > >> >Competition is high in this genre of games, and being the fastest to >>load >> >is important. We won "Best social Casino Product of 2013" this year. >> >Maybe if we were not the fastest to load we might have still won. >>Maybe >> >not. But we are. And I would hazard the guess that it played a role. >> >Many ppl already HAVE the RSL's cached on their machines. I have to >> >offset that benefit by minimizing as much as possible the hit that any >> >Apache based solution would incur. >> > >> >As with any social game the first impression is the most important one. >> >Especially with those who are disposed to spend real money. I know >>that >> >TECHNICALLY there are many reasons to just link it statically and >>forget >> >about it. But from a business perspective, every shred of speed that >>we >> >can statistically extract from the app is worth it. >> > >> >I can't justify moving all the framework RSL's to our CDN and storing >> >them in browser only cache instead of perpetual flash player storage. >> >That's why I asked about local storage hacks. I CAN justify putting a >> >SINGLE file on our CDN, if it means greater stability (ie: new SDK) and >> >downloading a smaller amount of bytes than the 4.5.1 RSL's. a few >>bytes >> >are big money when you are distributing them to a million ppl. >> > >> >Unfortunately, that's the reality of the business side of a social >>app. :( >> > >> > >> >> From: david_coleman_...@hotmail.com >> >> To: dev@flex.apache.org >> >> Subject: RE: SharedLibrary not works with SDK 4.11 >> >> Date: Tue, 3 Dec 2013 19:56:13 -0300 >> >> >> >> It saves us a great deal of time and resources when we have to >>release >> >>new art. >> >> >> >> We can break cache on the art asset module and not have to run a full >> >>QA regression on the main app. This gives us the flexibility as a >> >>company to deliver constantly changing content to our users w/o >>forcing >> >>them to download every file again, or dedicating our time and >>resources >> >>to QA of the application when we only want to change a single image in >> >>the game list. >> >> >> >> It is a logistical and political need as much as it is a technical >> >>decision to approach it this way. >> >> >> >> > From: aha...@adobe.com >> >> > To: dev@flex.apache.org >> >> > Date: Tue, 3 Dec 2013 14:43:33 -0800 >> >> > Subject: Re: SharedLibrary not works with SDK 4.11 >> >> > >> >> > >> >> > >> >> > On 12/3/13 2:38 PM, "David Coleman" <david_coleman_...@hotmail.com> >> >>wrote: >> >> > >> >> > >Actually Alex, what is the biggest culprit in our file is >>Greensock, >> >>and >> >> > >after that, a whole mess of engine logic needed to handle the >> >>interface >> >> > >with the games. Also some of our legacy animations use Tweener, >>so >> >>for >> >> > >now I'm cursed with having to include BOTH libs in the main app. >> >> > > >> >> > >I also think that 500K is too much and like I said, each version I >> >> > >whittle it down a little more. >> >> > > >> >> > >I've often thought of loading the engine container as a module to >> >>remove >> >> > >another 100K or so from the main app. >> >> > > >> >> > >How would i create a custom RSL? Can I automate it via ant to >> >>generate >> >> > >it via the link-reports? I'd like to keep one RSL for ALL files, >> >>app, >> >> > >and modules to increase cache hits, and not hit a different file >>each >> >> > >time. >> >> > > >> >> > >I'm really curious to experiment with this. It's ok if the >>browser >> >>cache >> >> > >expires, that's beyond my control, but 99% of the time it will be >>a >> >> > >benefit - I'm ok with those numbers. >> >> > I asked this in the other reply, but how will that save you over a >> >>single >> >> > monolithic SWF? If you're not in the cache, then instead of >>loading >> >>two >> >> > things, one of which may contain classes you don't need until >>later, >> >>you >> >> > only load what you need when you need it. >> >> > >> >> > -Alex >> >> > >> >> >> > >> >
