adams中rsp文件是什么

具体如下：

.RSP 文件包含一个或多个命令行参数，由包含在.NET 编译器平台（也称为Roslyn）中的C#编译器（CSC）使用。它可以存储一个或多个编译器选项以及要编译的一个或多个源代码文件的名称。.RSP 文件以纯文本格式保存，并由CSC在每次编译时处理。

RSLogix PLC Program File 文件是最常用的文件类型，带有 RSP 文件扩展名，最初由 Microsoft Corporation开发Microsoft Visual Studio。 根据我们的内部数据，RSLogix PLC Program File 文件最受China用户的欢迎，其中大多数运行 Windows 10。 这些用户中的绝大多数选择使用Google Chrome作为首选internet浏览器。

使用adams软件。解决方案如下：

1、首先到adams软件找到一个名为mdi.bat的文件，该文件的位置为“D盘”，然后双击该文件，使用管理员身份运行，然后会d出一个cmd窗口。

2、其次用键盘输入你想要使用的模块，比如要使用载荷rsp文件用adams打开。

3、最后接下来输入rsp,然后选择使用交互方式即可。

以下功能简介的几段文字引用自github上VasSonic官方wiki。地址为： https://github.com/Tencent/VasSonic/wiki

通过中间层启动子线程并发拉取页面主资源和流式拦截的方式，支持内核边加载边渲染，弱化终端初始化过程耗时的影响，同时对页面进行动态缓存和增量更新，减少页面对网络数据传输的依赖，极速提升H5页面的加载速度。

支持动态缓存页面内容，通过客户端和服务端遵守一定的格式规范，每次请求仅需要返回变动的数据块数据，大大减少响应数据传输。

通过预推送以及动态缓存页面，先加载本地缓存页面，用户可以快速看到内容，即使在无网络场景下，依然能看到首屏内容，让H5页面的体验更加接近原生。

框架来自腾讯VAS团队超过一年的优化提速总结，它是一整套解决方案，可以快速在Android和iOS平台上接入使用，无须繁琐配置流程。

VasSonic在加载web之前，先根据url创建一个会话。独立起一个线程去请求url定位的资源并缓存。当UIWebView加载url时，通过NSURLProtocol拦截请求，并根据不同的策略进行加载和刷新。因此这是两个并行的线程，如果手动执行Sonic线程，就是预加载。

为了方便数据的缓存和刷新，提高效率，Sonic将一个完整的html页面做了数据和模板的拆分。打开一个页面之后，可以看到沙盒里面多了下面四个文件，如下图所示。分别是以.html、.data、.rsp、.temp为后缀，分别表示完整的网页、动态数据、配置、和模板数据。

那么这几个文件里面的数据到底是怎样的呢？文件之间的关系是什么？

通过源码的分析，可以看到，几个文件之间的关系如上图所示。其中.html文件是完全的网页文件，然后把.html文件进行拆分，就得到了.temp和.data文件。而.rsp文件是直接把请求返回头中的一些配置取出来缓存在文件中。

打开这些文件看里面的内容，也可以看出这种关系。如下图所示，为完整的.html文件内容。

特意圈了一下，里面绿色的注释。这个<!--sonicdiff-data1--><!--sonicdiff-data1-end-->就是数据和模板区分的边界。再看.temp文件，其实也是一个html文件，如下图所示：

从图中可以看出，和.html文件相比，没有了<!--sonicdiff-data1--><!--sonicdiff-data1-end-->内部的内容，被替换成了{data1}。然后再看下.data文件，如下图所示：

可以看出，.data文件其实是一个.plist文件，其中用Key {data1}储存了<!--sonicdiff-data1--><!--sonicdiff-data1-end-->内部的内容。这样就很明了了，.temp和.data数据拼起来就是.html文件内容。再来看最后一个文件，.rsp文件，如下图所示：

.rsp文件其实也是一个.plist文件，里面存储的都是各种配置、策略的键值对。

Sonic很重要的一个功能点就是缓存，那么它的缓存策略有哪些？

从请求的返回头里，可以看到一个Key——SonicHeaderKeyCacheOffline，这个Key里面存的就是关于如何缓存、刷新的几个值。这几个值表示的意思分别是，SonicHeaderValueCacheOfflineStore表示仅仅缓存，不刷新页面；SonicHeaderValueCacheOfflineStoreRefresh表示既缓存又刷新页面；SonicHeaderValueCacheOfflineRefresh表示不缓存，仅仅刷新页面；SonicHeaderValueCacheOfflineDisable表示使本地缓存失效。如下所示：

当首次加载页面的时候，如果返回的是状态码200，则返回头中取出对应的缓存策略并缓存。如果返回的不是200，则是请求异常，做异常处理。如果不是首次加载页面，情况又有些不同，如下所示：

当非首次加载时，首先会看返回的状态码。如果状态码是304，说明服务端没有更新，所以客户端只更新一下配置文件里面的请求时间戳，不刷新缓存，也不刷新页面。如果状态码是200，说明服务端内容有变化，本地缓存需要刷新。但是具体是那部分发生了变化，需要根据返回头里面的Key——SonicHeaderKeyTemplateChange来判断。如果SonicHeaderKeyTemplateChange为true，则表示模板有更新，需要删除所有缓存，重新走模板数据拆分逻辑。如果缓存策略中有刷新，则向Webview发起重新加载。如果SonicHeaderKeyTemplateChange为false，则表示模板不变数据有更新，仅仅需要更新数据文件。但是如果缓存策略中有刷新，要将新的数据发给js刷新Web界面。

Local Server是VasSonic 2.0中的新特性。Local Server的目的是简化VasSonic的接入，在客户端模拟服务端的配置，省去服务端的配置。那么Local Server做了哪些处理呢？

其实Local Server可以算作是客户端和服务端的一个中间层。如果开启了Local Server模式，即使从服务端请求到的只有数据，没有返回头中的一些特定Key的配置，也没关系。因为Local Server层会通过计算把这些特定Key的配置补充到返回的头中。

在Local Server模式下，SonicHeaderKeyCacheOffline这个Key是被写死了，一定是SonicHeaderValueCacheOfflineStoreRefresh，也就是既缓存又刷新。

然后又增加了两个Key，eTag和template-tag。其中，eTag是对完整网页文件（.html文件）取SHA1码得到的，template-tag是对模板文件（.temp文件）取SHA1码得到的。

在Local Server模式下，Local Server处理逻辑如下图所示：

当服务端返回的状态码为304时，说明服务端无更新，将跳过Local Server层的处理；如果服务端返回的状态码为200，会做执行以下逻辑。首先会分别计算本地缓存的完整网页文件（.html文件）的eTag和请求到的数据的完整网页文件（.html文件）的eTag，如果两个eTag相等，说明数据无更新，将返回头的状态码置为304；如果两个eTag不相等，说明数据确实有更新，但不确定是模板更新了还是数据更新了，所以要分别计算本地缓存和本次请求数据的模板文件（.temp文件）的template-tag。如果两个template-tag不相等，说明模板有更新，将返回头中的template-change Key置为true；如果两个template-tag相等，说明模板不变，数据有更新，就将返回头中的template-change Key置为false。

经过Local Server层的处理后，Sonic内核就能按照返回头中的指令继续执行下一步 *** 作了。

上面引用的是官方wiki上的原话。但是从iOS端的源码来看，并没有找到引用的内容，这段话可能是针对Android端的。这个Cache-Control功能目前在iOS端的主要表现为以下几个点：

下篇《VasSonic 2.0 iOS端分析（二）》

见： https://www.jianshu.com/p/5d35ced5d6b4

主要内容：

---