Scripting 共用 jsvm context 时的脚本 scope 隔离（方案 & 讨论）

Jay

出于性能考虑，开启 shared-jsvm-context 比较好，但现在各 script 是共享的全局 this，并且直接在这个 scope 上运行，命名很容易冲突（不只是脚本之间，单个脚本如果使用了 const、let ，再次执行时也有问题）

建议考虑下这个方案：

让每个 script 在不同的 function 中执行，然后该 function bind 独立的 this 变量，这样就不会污染全局 this 变量
如果要保留 script 间互访的能力（万恶之源，最好用 persistentStore），可以把全局 this 以 global 变量名传给各个 script 的 this 变量

以下是思路：

/* script 初始化，仅执行一次 */
// 增加 async wrapper、exception handler
const userCode1Exec = (async function(){
    try{
        userCode1 源码
    } catch(e){}
}).bind(
    // clone API 对象，增加 global 变量
    this.userCode1Scope = Object.assign({global: this}, APIs)
);

const userCode2Exec = (async function(){
    try{
        userCode2 源码
    } catch(e){}
}).bind(
    this.userCode2Scope = Object.assign({global: this}, APIs)
);

/* 执行部分，可以反复执行 */
userCode1Exec();

userCode2Exec();

/* scope 互访，源码中用其它 script 的 scope 名即可获取 */
global.userCode1Scope;

global.userCode2Scope;

@SurgeTeam

SurgeTeam

不用考虑性能，实测是否开启 shared-jsvm-context 对性能几乎无影响，由于已加入 persistentStore 目前考虑直接移除 shared-jsvm-context

xenme

SurgeTeam 不知道内存使用率是否有影响？毕竟创建一个新的context还是需要额外的开销，而且特别是现在大量请求的情况下并发的问题特别明显。有涉及到修改body相关的，打开app后log里面会看到app收到warning，然后自动purge各种连接。

今天把所有脚本放到closure里面，开了share js context就为了一个脚本来统计所有数据然后发送到splunk来分析。而且persistentStore换成了global variable，感觉是内存使用比之前好多了。之前是直接内存从开启的11M直接到22M，会重启。现在会从11M到18或者19M，surge可以自己清理连接并恢复而不会导致重启。

所以就目前来看，share js context还是有用的。虽然目前数据不严谨，但还是可以反应一部分结果的。建议保留。