You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Christofer Dutz <ch...@c-ware.de> on 2015/07/20 10:39:45 UTC
[Falcon] Wild proposal for Falcon and mobile packaging
Hi,
as you might know, I'm currently working on mobile packaging for Flexmojos. While working on this, I had to dig quite deep into some of Adobe AIRs concepts on mobile packaging. While packaging for android seems to be quite straight forward, iOS packaging is a little more complex. 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.
Chris
AW: [Falcon] Wild proposal for Falcon and mobile packaging
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <ah...@adobe.com>
Gesendet: Montag, 20. Juli 2015 15:33
An: dev@flex.apache.org
Betreff: Re: [Falcon] Wild proposal for Falcon and mobile packaging
On 7/20/15, 1:39 AM, "Christofer Dutz" <ch...@c-ware.de> 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
Re: [Falcon] Wild proposal for Falcon and mobile packaging
Posted by Alex Harui <ah...@adobe.com>.
On 7/20/15, 1:39 AM, "Christofer Dutz" <ch...@c-ware.de> 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