Hi Alex, thanks for that very detailed explanation :-)
I wasn't expecting us to do that and especially not do that now, I was just curious what you others might think of this in general. I agree ... some details are different between Java, Actionscript and ObjectiveC (or Swift). But having a look at the internals of the AOT compiler sort of got me thinking. As Flexmojos is starting to support mobile packaging and FlexJS I think it would be best if I would add Cordova packaging as a packaging option to Flexmojos ... I think this shouldn't be that much of an effort (I hope) ... but I'll continue down that path as soon as the AOT IPK packages are running smoothly. Chris ________________________________________ Von: Alex Harui <[email protected]> Gesendet: Montag, 20. Juli 2015 15:33 An: [email protected] Betreff: Re: [Falcon] Wild proposal for Falcon and mobile packaging On 7/20/15, 1:39 AM, "Christofer Dutz" <[email protected]> wrote: >Hi, > > >as you might know, I'm currently working on mobile packaging for >Flexmojos. They seem to anaylse the ABC code to see what the application >is doing and outputting pre-compiled chunks of iOS code. So if I was to >compile a Flex application to iOS, I would be parsing the ActionScript >code, ouput SWF, then parse that and output iOS code ... so I tought, >shouldn't Falcon allow directly outputting iOS using the same templates >the AOT compiler in the Air SDK has? > > >And thinking even further ... shouldn't it be possible to so something >similar for android? This way we wouldn't have to package the full-blown >AIR runtime with every application. > Well, I believe it is possible. And I believe it has been discussed briefly and postponed for now. Here is a long description of why I think we aren’t doing that now and what we are doing instead for FlexJS. My understanding of what is going on is this: When any Flex app is run on Windows or Mac, the AIR/Flash runtime interprets the ABC code in the SWF. The execution of any ABC code is handled by C code in the runtime. So, if you SWFDump a SWF and see, for example, the ABC code for: OP_pushstring “Chris” which really is something like: OP_pushstring 0x1f where 0x1F is a compressed integer encoding of an index into the string constant pool in the SWF, some C code picks up the 0x1F, decodes into into an index, and grabs the memory offset of the string and pushes it onto the stack. So, the C code might look like: if (opcode == OP_pushstring) { abcoffset++; int index = decodeBytes(&abcoffset); pushToASStack(stringpooloffset + index); } Note that it doesn’t actually push the value on the runtime’s stack because the runtime’s stack is being used to make these function calls in the ABC interpreter. It turns out that you can run this ABC code faster if you compile it into this sequence of C code because you avoid going through the giant if/else or switch statement for every ABC code and can do other optimizations along the way. So, most of the time, when the interpreter is first trying to execute an ABC code, it actually fills another memory buffer with these calls to decodeBytes and pushToStack (probably in-lining decodeBytes) and then runs that C code. Since IOS has strict rules against interpreting byte code, Adobe decided that to run an AIR SWF on IOS, you could write a tool that would go through every ABC code in the SWF, do this same conversion to C code and make that the executable. And do the same for Android. Now here’s what I think is the hard part: I am told that ActionScript and C, Objective-C and Java are different languages which tricky but important differences around scoping rules and closures and things like that. To create an AS to C, Objective-C and/or Java cross-compiler is considered “hard”. You might end up creating an virtual runtime to handle variable lookups that maintain AS scoping rules. And you still have to handle the Flash/AIR APIs as well. And that might incorporate mimicking the runtime APIs. There is probably licensing restrictions around using the byte-code patterns in the Adobe tools. Falcon could call those Adobe tools directly if that helps you out on the Maven end. For FlexJS, however, the first-generation Android/IOS plan is to utilize Apache Cordova. The AS is compiled to JS and packaged into a Cordova app. We have that working already but there is a manual step where you take your JS and run a script to do the Cordova packaging. I can imagine that Falcon could someday integrate directly with Cordova tools to avoid the manual step. This approach works and seems like it will take less energy from this project to put into production. Maybe Cordova, which has more money and people, will generate an optimizer that does what the AIR native packager does. And this gets us not only Android and IOS, but all of the other platforms that Cordova supports that AIR does not. But yeah, if there is enough energy in the community to want to take on cross-compiling to Objective C and/or Java, that’s the Apache Way. It is technically possible and the results would probably be awesome. I’m just promoting the Cordova approach for now because I think we can get a mobile story out faster and attract more folks to Flex sooner to make it more possible to do what you described. HTH, -Alex
