If you want to speed it up you should take plain text-files and no xml-formats for exports respectively exchanging data. A native API to create qvd-files from third party tools didn't exists but maybe you could use: QVX & QVD Converter Java library.
You can use the QlikView OCX to build a QV app -- a QVW on the fly. If you use Qlik Sense, there are more friendly API options available to generate an app from code.
" import this file in QV (an unnecessary complex, not logical and not thread save way)"
leads me to believe that you are just trying to compare QV with something you know, and have not taken any time to understand the QV architecture. "unnecessary complex" to you, but robust and effective to those of us who use it regularly.
QV has a visualization layer and a data layer defined by the load script. The two merged together form an application (qvw file). The "reload" process executes the script to bring fresh data into the application.
I don't imagine that you want to be responsible for generating the visualization layer every time or managing your customer's modifications to visualizations.
Let's take a look at how QV customers work with external data today. The QVW file lives on the Customer's QV server, and the reload process is executed on schedule set by the customer.
If the data is an extract type, some external process runs on schedule at the data provider to generate a flat file in a known location. The reload process picks up this extract file on schedule, typically via FTP. Depending on the level of trust and connectivity between the customer and the data provider, the two processes may be coordinated or the data may be pushed.
For some data, such as Salesforce, customers use a connector in the reload script which eliminates the need for any intermediate extract at all, as the data is provided by an interface in Salesforce. If you don't want to create a connector for your system, there is a generic REST connector that can retrieve data from your system via REST if you can support that.