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 >> > >> >
