So for example, the android runtime operates at the same level as any other process. You will run android applications at the same "performance" level as native qnx apps. The benefits of the microkernel means crashes of an android runtime or the adobe AIR runtime have zero chance of bringing down other platform services, etc. You have to remember it was once planned to also offer a "legacy" runtime environment so that j2me/bb apps would continue to run alongside android apps. That obviously was lost (good riddance!) in the development cycle. The CPU scheduler is also quite different.
The playbook represented a very "rush a beta product to market too fast" case study, so I wouldn't prejudge the smartphone builds of BB10 to the playbook experience. How does this translate into a "better" user experience is not clear to me either apart from being able to run repackaged android apps from day one. Design and flow is more important.
That said, the multimedia latency that can be important in gaming on low-powered devices is significantly improved compared to the performance of the linux kernel. Finally, if an app ecosystem builds up around "sharing" information capabilities between running apps, the QNX IPC messaging is significantly better optimized than the IPC mechanism "borrowed" from BeOS that android uses.
In theory, the advantages of the QNX microkernel to Blackberry isn't so much in that it will dramatically improve the smartphone experience per se, it is that QNX can be deployed/configured with less headache across more divergent platforms with different capabilities and hardware than the j2me platform, such as auto infotainment systems, factory floors, medical devices, etc. It would be quite possible to boot the device and "download" most of the necessary modules to run the hardware dynamically.
Finally, I think the one aspect of QNX that hasn't really been exploited or discussed yet is its use as a distributed computing platform. It is rather easy to tie QNX "nodes" together and do IPC across the network by using TDP on qnet. [0] I could imagine for example using the processing power of the "nearby" qnx systems to power the apps running on my phone to save its battery. You could see swarms of phones contributing to enterprise problems in a distributed fashion. Want to access the camera on a phone in China, the code is the same as accessing the camera on your local phone, kind of like the Plan9 filesystem/protocol. Obviously BB10 has to be successful for anything grander and someone at BB has to share my product vision for it to take root.
The playbook represented a very "rush a beta product to market too fast" case study, so I wouldn't prejudge the smartphone builds of BB10 to the playbook experience. How does this translate into a "better" user experience is not clear to me either apart from being able to run repackaged android apps from day one. Design and flow is more important.
That said, the multimedia latency that can be important in gaming on low-powered devices is significantly improved compared to the performance of the linux kernel. Finally, if an app ecosystem builds up around "sharing" information capabilities between running apps, the QNX IPC messaging is significantly better optimized than the IPC mechanism "borrowed" from BeOS that android uses.
In theory, the advantages of the QNX microkernel to Blackberry isn't so much in that it will dramatically improve the smartphone experience per se, it is that QNX can be deployed/configured with less headache across more divergent platforms with different capabilities and hardware than the j2me platform, such as auto infotainment systems, factory floors, medical devices, etc. It would be quite possible to boot the device and "download" most of the necessary modules to run the hardware dynamically.
Finally, I think the one aspect of QNX that hasn't really been exploited or discussed yet is its use as a distributed computing platform. It is rather easy to tie QNX "nodes" together and do IPC across the network by using TDP on qnet. [0] I could imagine for example using the processing power of the "nearby" qnx systems to power the apps running on my phone to save its battery. You could see swarms of phones contributing to enterprise problems in a distributed fashion. Want to access the camera on a phone in China, the code is the same as accessing the camera on your local phone, kind of like the Plan9 filesystem/protocol. Obviously BB10 has to be successful for anything grander and someone at BB has to share my product vision for it to take root.
Sorry just rambling here, I'll stop.
[0] http://www.qnx.com/developers/docs/6.3.2/neutrino/prog/qnet....