目前開發(fā)者可登陸Github(https://github.com/didi/VirtualAPK)查看該項目的詳細介紹和源代碼，也可在滴滴的開源平臺上（https://didi.github.io/）獲取更多信息。
在傳統(tǒng)APP發(fā)布過程中，大多數開發(fā)者采用固定時段發(fā)版節(jié)奏，比如兩周或一個月更新一次，但如果一個新版本發(fā)布運行后發(fā)現存在大量crash，此時大多數公司會選擇立刻發(fā)一個緊急版本，但緊急版本雖然可解決燃眉之急，但在用戶體驗方面將造成不可挽回的損失。
除此之外，還有一種常見情況，比如早期創(chuàng)業(yè)公司，需要通過迅速“試錯”來嘗試找準市場方向，要進行頻繁發(fā)版，甚至一天一發(fā)，但在正常發(fā)版流程中，顯然不現實。
VirtualAPK有效解決了上述問題，通過VirtualAPK將業(yè)務模塊插件化，就可以隨時通過更新插件的方式來發(fā)布新功能，無論是修復crash還是業(yè)務“試錯”都可以高效進行。
實際上，市場上已經有很多優(yōu)秀的開源插件化框架，滴滴之所以選擇自行研發(fā)VirtualAPK，相關負責人稱，首先，大部分開源框架支持的功能還不夠全面。 除了DroidPlugin，大部分都只支持Activity。
其次，兼容性問題嚴重，大部分開源方案不夠健全。 由于國內Rom嘗試深度定制Android系統(tǒng)，這導致了諸多的插件框架的兼容性問題，而目前已有的開源方案中，除了個別開源方案外，其他方案對兼容性問題的適配度嚴重不足。
第三，已有的開源方案不適合滴滴的業(yè)務場景，雖然DroidPlugin從功能的完整性和兼容性上來看，是一款非常完善的插件框架，然而它的使用場景和滴滴的業(yè)務不符，DroidPlugin側重于加載第三方獨立插件，比如微信，并且插件不能訪問宿主的代碼和資源。而在滴滴打車中，其他業(yè)務模塊均需要宿主提供的訂單、定位、賬號等數據，因此插件不可能和宿主沒有交互。
基于上述，滴滴自行研發(fā)了這款插件化框架，它功能全面、兼容性好，還能夠適用于有耦合的業(yè)務插件，這就是VirtualAPK存在的意義。業(yè)內認為，在加載耦合插件方面，VirtualAPK可以說是開源方案的首選。
