Dropbox had recently announced a SDK for android to facilitate app developers to use its cloud functionality. Facebook too had a similar SDK. Considering the existing database and reach of facebook, it only makes sense for application developers to use facebook SDK to share relevant information like scores in a game etc. Users might end up using multiple applications built on top of same 3rd Party SDK, but what exactly is the memory implication in the device?
The SDKs, especially when it doesn't involve any native libraries, gets linked into respective application process, each having their own version of the jar. In case of Android, once the process gets started it doesn't get killed until low memory killer kicks in. Any attempt by the user to launch a new application using the same SDK doesn't leverage the already loaded code segment of the SDK and with more application launches, the memory overhead just increases. Application built just on Android SDK doesn't have this issue as its stubbed out to ensure proper compilation and at runtime, zygote which forks the application process pre-loads most often used classes and relies on linux's copy-on-write mechanism.
All said and done, what could 3rd party SDK developers do to address this in short run? They could probably work with Android OEM's to release SDK add-ons. This would reduce the memory overhead and would be easy for application developers to use. They wouldn't have to deal with the different installation procedure for the respective 3rd party SDK. However, it might not be practical for the SDK developers to deal with independent and ever growing number of OEMs. The best possible solution would probably be for the dalvik virtual machine to facilitate class sharing across process space. This is not new and few virtual machines like the one from IBM have already solved this. However, considering the increasing memory in modern smart phones, dalvik virtual machine might never need to address this, until a popular and massive 3rd party SDK for Android gets enough attention of end users (frequent app process kills).
The SDKs, especially when it doesn't involve any native libraries, gets linked into respective application process, each having their own version of the jar. In case of Android, once the process gets started it doesn't get killed until low memory killer kicks in. Any attempt by the user to launch a new application using the same SDK doesn't leverage the already loaded code segment of the SDK and with more application launches, the memory overhead just increases. Application built just on Android SDK doesn't have this issue as its stubbed out to ensure proper compilation and at runtime, zygote which forks the application process pre-loads most often used classes and relies on linux's copy-on-write mechanism.
All said and done, what could 3rd party SDK developers do to address this in short run? They could probably work with Android OEM's to release SDK add-ons. This would reduce the memory overhead and would be easy for application developers to use. They wouldn't have to deal with the different installation procedure for the respective 3rd party SDK. However, it might not be practical for the SDK developers to deal with independent and ever growing number of OEMs. The best possible solution would probably be for the dalvik virtual machine to facilitate class sharing across process space. This is not new and few virtual machines like the one from IBM have already solved this. However, considering the increasing memory in modern smart phones, dalvik virtual machine might never need to address this, until a popular and massive 3rd party SDK for Android gets enough attention of end users (frequent app process kills).
No comments:
Post a Comment