商业源码 手机APP和web服务端 跨域问题
跨域问题来源于JavaScript的同源策略，即只有 协议+主机名+端口号 (如存在)相同，则允许相互访问。也就是说JavaScript只能访问和操作自己域下的资源，不能访问和操作其他域下的资源。
在以前，前端和后端混杂在一起， 比如JavaScript直接调用同系统里面的一个Httphandler，就不存在跨域的问题，但是随着现代的这种多种客户端的流行，比如一个应用通常会有Web端，App端，以及WebApp端，各种客户端通常会使用同一套的后台处理逻辑，即API， 前后端分离的开发策略流行起来，前端只关注展现，通常使用JavaScript，后端处理逻辑和数据通常使用WebService来提供json数据。一般的前端页面和后端的WebService API通常部署在不同的服务器或者域名上。这样，通过ajax请求WebService的时候，就会出现同源策略的问题。
需要说明的是，同源策略是JavaScript里面的限制，其他的编程语言，比如在C#，Java或者iOS等其他语言中是可以调用外部的WebService，也就是说，如果开发Native应用，是不存在这个问题的，但是如果开发Web或者Html5如WebApp，通常使用JavaScript ajax对WebService发起请求然后解析返回的值，这样就可能存在跨域的问题。
一般的，很容易想到，将外部的资源搬到同一个域上就能解决同源策略的限制的。即在Web网站上同时开发一个Http服务端页面，所有JavaScript的请求都发到这个页面上来，这个页面在内部使用其他语言去调用外部的WebService。即添加一个代理层。这种方式可以解决问题，但是不够直接和高效。
目前，比较常见的跨域解决方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解决方案需要客户端和服务端配合如JSOP，一些则只需要服务端配合处理比如CORS。下面分别介绍这两种跨域方案，以及服务端WebService如何支持这两种跨域方案。
JSONP以及WebService的支持
同源策略下，某个服务器是无法获取到服务器以外的数据，但是html里面的img,iframe和script等标签是个例外，这些标签可以通过src属性请求到其他服务器上的数据。而JSONP就是通过script节点src调用跨域的请求。
当我们向服务器提交一个JSONP的请求时,我们给服务传了一个特殊的参数,告诉服务端要对结果特殊处理一下。这样服务端返回的数据就会进行一点包装，客户端就可以处理。
举个例子，服务端和客户端约定要传一个名为callback的参数来使用JSONP功能。比如请求的参数如下:
http://wwwexamplenet/sampleaspxcallback=mycallback
如果没有后面的callback参数，即不使用JSONP的模式，该服务的返回结果可能是一个单纯的json字符串，比如：
{ foo : 'bar' }
如果和服务端约定jsonp格式，那么服务端就会处理callback的参数，将返回结果进行一下处理，比如处理成：
mycallback({ foo : 'bar' })
可以看到，这其实是一个函数调用，比如可以实现在页面定义一个名为mycallback的回调函数：
mycallback = function(data)
{
alert(datafoo);
};
现在，请求的返回值回去触发回调函数，这样就完了了跨域请求。
如果使用ServiceStack创建WebService的话，支持Jsonp方式的调用很简单，只需要在AppHost的Configure函数里面注册一下对响应结果进行过滤处理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFiltersAdd((req, res, dto) =>
{
var func = reqQueryStringGet("callback");
if (!funcisNullOrEmpty())
{
resAddHeader("Content-Type", ContentTypeHtml);
resWrite("<script type='text/javascript'>{0}({1});</script>"
FormatWith(func, dtoToJson()));
resClose();
}
});
}
JSONP跨域方式比较方便，也支持各种较老的浏览器，但是缺点很明显，他只支持GET的方式提交，不支持其他Post的提交，Get方式对请求的参数长度有限制，在有些情况下可能不满足要求。所以下面就介绍一下CORS的跨域解决方案。
CORS跨域及WebService的支持
先来看一个例子，我们新建一个基本的html页面，在里面编写一个简单的是否支持跨域的小脚本，如下：
<html xmlns="http://wwww3org/1999/xhtml">
<head>
<title>AJAX跨域请求测试</title>
</head>
<body>
<input type='button' value='开始测试' onclick='crossDomainRequest()' />
<div id="content"></div>
<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
documentgetElementById("content")innerHTML = "开始……";
if (xhr) {
xhropen('POST', url, true);
xhronreadystatechange = handler;
xhrsend();
} else {
documentgetElementById("content")innerHTML = "不能创建 XMLHttpRequest";
}
}
function handler(evtXHR) {
if (xhrreadyState == 4) {
if (xhrstatus == 200) {
var response = xhrresponseText;
documentgetElementById("content")innerHTML = "结果：" + response;
} else {
documentgetElementById("content")innerHTML = "不允许跨域请求。";
}
}
else {
documentgetElementById("content")innerHTML += "<br/>执行状态 readyState：" + xhrreadyState;
}
}
//]]>
</script>
</body>
</html>
然后保存为本地html文件，可以看到，这个脚本中，对本地的服务http://localhost:1337/json/Hello 发起了一个请求， 如果使用chrome 直接打开，会看到输出的结果，不允许跨域请求。 在javascript控制台程序中同样可以看到错误提示：
那么如果在返回响应头header中注入Access-Control-Allow-Origin，这样浏览器检测到header中的Access-Control-Allow-Origin，则就可以跨域操作了。
同样，如果使用ServcieStack，在很多地方可以支持CORS的跨域方式。最简单的还是在AppHost的Configure函数里面直接写入：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
thisAddPlugin(new CorsFeature());
}
这样就可以了，相当于使用默认的CORS配置：
CorsFeature(allowedOrigins:"",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);
如果仅仅允许GET和POST的请求支持CORS，则只需要改为：
PluginsAdd(new CorsFeature(allowedMethods: "GET, POST"));
当然也可以在AppHost的Config里面设置全局的CORS，如下：
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
baseSetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}
现在运行WebService，使用postman或者Chrome调用这个请求，可以看到返回的值头文件中，已经加上了响应头，并且可以正常显示返回结果了：
CORS使用起来简单，不需要客户端的额外处理，而且支持Post的方式提交请求，但是CORS的唯一一个缺点是对客户端的浏览器版本有要求，支持CORS的浏览器机器版本如下：
总结
本文介绍了JavaScript中的跨域基本概念和产生的原因，以及如何解决跨域的两种方法，一种是JSONP 一种是 CORS,在客户端Javascript调用服务端接口的时候，如果需要支持跨域的话，需要服务端支持。JSONP的方式就是服务端对返回的值进行回调函数包装，他的优点是支持众多的浏览器， 缺点是仅支持Get的方式对服务端请求。另一种主流的跨域方案是CORS，他仅需要服务端在返回数据的时候在相应头中加入标识信息。这种方式非常简便。唯一的缺点是需要浏览器的支持，一些较老的浏览器可能不支持CORS特性。
跨域支持是创建WebService时应该考虑的一个功能点，希望本文对您在这边面有所帮助，文中是使用ServiceStack来演示跨域支持的，如果您用的WCF的话，知道跨域原理的前提下，实现跨域应该不难。
参考资料：
https://githubcom/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://githubcom/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflowcom/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflowcom/questions/15224038/rename-callback-parameter-for-jsonp
1开发方面
原生APP：每一种移动操作系统全部须要独立的开发项目，iphone版本、WP版本、安卓版本。每种平台全部须要独立的开发语言。Java(Android),Objective-C(iOS)等等，必须要使用各自的软件开发包，开发工具乃至各自的控件。开发费用高、开发速度慢、维护费用高。三个平台（IOS、安卓、windows）的规则、推广、运营全部不一样。官方应用商店对APP上线审核过程相对复杂并且慢长，严重影响APP的发布上线。
WebApp：因为运行在移动设备的浏览器上，于是只须要一个开发项目。能够通过HTML、CSS或许JavaScript来实行WebAPP的开发。开发费用低、开发速度快。
2功能方面
原生App：原生APP就是一个系统性的应用程序，能够类比在电脑上的软件。原生app能够调用移动终端的硬件设备，好比：麦克风、摄像头、短信、GPS、蓝牙、重力感应等。完成功能丰富
WebApp：WebAPP能够类比在电脑上的网页。WebAPP很多就是页面展示类的APP。只可以使用有限的移动硬件设备功能。很多用来页面展示，侧重在简单的交互，没办法使用很多硬件设备独特的功能。
3应用安装使用方面
原生App：须要通过应用商店会原生app下载到手机上或移动终端上。以独立的应用程序运行，用户必需手动去下载并安装这些原生App，原生应用能够节约宽带费用，能够访问本地资源、缓存。
WebApp：通过移动设备上的浏览器访问，软件更新只须要更新服务器就够了，用户层面不须要做一切操作。不须要安装客户端，能够节省手机终端的内存空间。
4版本控制方面
原生App：用户能够自由地选取能否更新软件版本，于是能显现不一样用户一起使用不一样版本的状况。一起同样能引起维护费用相对比较高。使用旧版本的用户没办法体验新版本的完整功能。
WebApp：全部的用户全部就是使用同样的版本，全部用户得到的功能全部就是一样的。版本更新相对比较便利，马上在服务器侧更新数据就可以。一个功能做好了就可以上线，1天更新几十次全部毫无压力。假如客户端不过是个浏览器，那所有都会变得非常简单。其它web统一性高，跨平台实用时开发量少。因为其入口不显著（浏览器导航或许随意点击链接进入），令用户记住的门槛同样随之拔高，每次推广导入的流量全部也许沦为一次性努力，用户留存率低。
5加载速度方面
原生App：原生APP由“云服务器数据APP应用客户端”两个别构成，APP应用全部的UI元素、数据内容、逻辑框架均安装在手机终端上。访问的时刻，不须要重新下载加载应用页面框架，只须要加载数据就可以。于是加载速度更快，页面响应更快。
WebApp：而WebAPP开启一个页面，全部需要重新加载页面的全部元素，访问速度受手机终端性能与网络环境的限制，引起加载速度慢，并且操作频繁容易卡死。
总结
原生App偏向在交互，注重用户体验（导航切换、勾选选项、相片、视频等操作），WebAPP偏向和浏览与简单的交互。一些功能须要访问硬件（摄像头、传感器等），使用原生App,WebAPP用来信息展示。费用有限时，中心的功能使用原生APP，周边辅助的功能能够使用WebApp。
现状：相对比较流行的技巧便是会原生App和WebApp实行融合，就是说应用大的框架就是原生的，其余详细的内容就通过网页封装，如此做的好处便是在方便更新的时候，同样可以确保中心功能的交互体验。
商领云可以定制开发APP以及h5网站，也可以入驻商领云SAASpaas系统进行在线制作APP、小程序、移动网站和微商城等。
单纯从功能测试的层面上来讲的话，APP 测试、web 测试 在流程和功能测试上是没有区别的。
根据两者载体不一样，则区别如下：
系统结构方面
web项目，b/s架构，基于浏览器的；web测试只要更新了服务器端，客户端就会同步会更新。
app项目，c/s结构的，必须要有客户端；app 修改了服务端，则客户端用户所有核心版本都需要进行回归测试一遍。
性能方面
web项目 需监测 响应时间、CPU、Memory
app项目 除了监测 响应时间、CPU、Memory外，还需监测 流量、电量等
兼容方面
web项目：
1 浏览器（火狐、谷歌、IE等）
2 操作系统（Windows7、Windows10、Linux等）
app项目：
1 设备系统: iOS（ipad、iphone）、Android（三星、华为、联想等） 、Windows（Win7、Win8）、OSX（Mac）
2 手机设备可根据 手机型号、分辨率不同
相对于 Wed 项目，APP有专项测试
1 干扰测试：中断，来电，短信，关机，重启等
2 弱网络测试（模拟2g、3g、4g，wifi网络状态以及丢包情况）；网络切换测试（网络断开后重连、3g切换到4g/wifi 等）
3 安装、更新、卸载
安装：需考虑安装时的中断、弱网、安装后删除安装文件等情况
卸载：需考虑 卸载后是否删除app相关的文件
更新：分强制更新、非强制更新、增量包更新、断点续传、弱网状态下更新
4 界面操作：关于手机端测试，需注意手势，横竖屏切换，多点触控，前后台切换
5 安全测试：安装包是否可反编译代码、安装包是否签名、权限设置，例如访问通讯录等
6 边界测试：可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等
7 权限测试：设置某个App是否可以获取该权限，例如是否可访问通讯录、相册、照相机等
测试工具方面
自动化工具：APP 一般使用 Appium; Web 一般使用 Selenium
性能测试工具：APP 一般使用 JMeter; Web 一般使用 LR、JMeter
0条评论