Windows 10 Bridges for iOS and Android start getting early and inaccurate hate!
I mentioned earlier when I wrote about these new toolkits Microsoft was bringing forward that many devs would just blindly hate on them and ignore them. And they aren't even here yet and it has already started and it is amusingly inaccurate and useless.
One developer asked what you get when you emulate and responded with bad performance... only there are two problems with that. iOS apps aren't emulated... and neither are Android apps. Also, emulation is only inherently slow when there is a terrible correlation between original compiled code and mapping it to a new system. But, lets get on with the details.
The iOS bridge sounds like some brilliant work from the Roslyn team. When this was announced some time ago, I actually speculated it could be used for just such a thing. The iOS Bridge (Project Islandwood) actually compiles your objective-C code to compiled C++. In other words, performance loss is incurred at compile time, not runtime. This IS NOT EMULATION. This is NATIVE CODE. It may not be 100% equivalent, but calling it emulated is flat out wrong. It is compiled in the truest sense.
There is VERY little reason to be concerned about performance here. Also, I think MS really needs to promote this one. While Android may have the larger app selection, the apps produced for the App Store generally have the distinction of being better quality apps. The code for the apps is also likely less complex to accomplish the same thing. Remember, Android is much more heavily fragmented than iOS which means a lot of code to accommodate device quirks which would be wasted cycles here. I think drawing in the Apple devs will bring more value to the platform than the Android devs.
Which lead us to Android. Android apps are based on Java, which isn't compiled code. It is interpreted code. And while Android may not be Java in the strictest sense, guess what? It isn't far off, it uses a JIT compiler. Microsoft happens to know more than a bit about JIT compilers. .Net code is all JIT compiled. The resultant execution isn't an emulation. JIT compiled apps are pseudo-compiled or pseudo-interpreted. This article roughly says this.
All of the technical nonsense is quite important. Basically, the byte code that the Java is compiled too isn't machine code that can be fed to the processor. But it is a set of much more compact instructions than the original code. Code may have been optimized as well in the process. This is then run through a JIT compiler which is a platform specific runtime which consumes byte code and emits machine code.
This means that not only is there no need to emulate Android. It is also technically not possible. Windows 10 would never get the machine code from an Android device and subsequently be forced to try and emulate it. Instead, what MS would have to do is actually nearly identical to what Android does. Take that byte code or IL (intermediate language) and JIT compile it to something that runs natively on that device. Under that light, there is really no reason why the code can't be processed precisely as efficiently as it is run on Android. In fact, since the OS in AOSP means open source... it is highly likely that Microsoft could have built a fully compliant Android Runtime which consumes that IL as efficiently as it does on any other Android device.
One developer asked what you get when you emulate and responded with bad performance... only there are two problems with that. iOS apps aren't emulated... and neither are Android apps. Also, emulation is only inherently slow when there is a terrible correlation between original compiled code and mapping it to a new system. But, lets get on with the details.
The iOS bridge sounds like some brilliant work from the Roslyn team. When this was announced some time ago, I actually speculated it could be used for just such a thing. The iOS Bridge (Project Islandwood) actually compiles your objective-C code to compiled C++. In other words, performance loss is incurred at compile time, not runtime. This IS NOT EMULATION. This is NATIVE CODE. It may not be 100% equivalent, but calling it emulated is flat out wrong. It is compiled in the truest sense.
There is VERY little reason to be concerned about performance here. Also, I think MS really needs to promote this one. While Android may have the larger app selection, the apps produced for the App Store generally have the distinction of being better quality apps. The code for the apps is also likely less complex to accomplish the same thing. Remember, Android is much more heavily fragmented than iOS which means a lot of code to accommodate device quirks which would be wasted cycles here. I think drawing in the Apple devs will bring more value to the platform than the Android devs.
Which lead us to Android. Android apps are based on Java, which isn't compiled code. It is interpreted code. And while Android may not be Java in the strictest sense, guess what? It isn't far off, it uses a JIT compiler. Microsoft happens to know more than a bit about JIT compilers. .Net code is all JIT compiled. The resultant execution isn't an emulation. JIT compiled apps are pseudo-compiled or pseudo-interpreted. This article roughly says this.
All of the technical nonsense is quite important. Basically, the byte code that the Java is compiled too isn't machine code that can be fed to the processor. But it is a set of much more compact instructions than the original code. Code may have been optimized as well in the process. This is then run through a JIT compiler which is a platform specific runtime which consumes byte code and emits machine code.
This means that not only is there no need to emulate Android. It is also technically not possible. Windows 10 would never get the machine code from an Android device and subsequently be forced to try and emulate it. Instead, what MS would have to do is actually nearly identical to what Android does. Take that byte code or IL (intermediate language) and JIT compile it to something that runs natively on that device. Under that light, there is really no reason why the code can't be processed precisely as efficiently as it is run on Android. In fact, since the OS in AOSP means open source... it is highly likely that Microsoft could have built a fully compliant Android Runtime which consumes that IL as efficiently as it does on any other Android device.
Comments
Post a Comment