商业源码 手机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
单纯从功能测试的层面上来讲的话，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
1、系统架构方面：
web项目，一般都是b/s架构，基于浏览器的。app项目，则是c/s的，必须要有客户端，用户需要安装客户端。
web测试只要更新了服务器端，客户端就会同步会更新。App项目则需要客户端和服务器都更新。
2、性能方面:
web页面主要会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些。它们服务端的性能没区别，都是一台服务器。
3、兼容方面：
web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容。app测试则要看分辨率，屏幕尺寸，还要看设备系统。web测试是基于浏览器的所以不必考虑安装卸载。
而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件。此外APP还有一些专项测试：如网络、适配性等。
扩展资料：
Web测试和APP测试相同点：
1、设计测试用例时，依然都是依据边界值分析法、等价类划分等；
2、多数采用黑盒的测试方法，来验证业务功能是否得到正确的应用；
3、需要检查界面的布局、风格和按钮等是否简洁美观、是否统一等；
4、测试页面载入和翻页的速度、登录时长、内存是否溢出等；
5、测试应用系统的稳定性等。
—web测试
APP设计与WEB设计区别如下：
APP设计运用JAVA、Objective-C、C++、C#开发语言开发设计。
JAVA开发Android应用程序
Objective-C开发IOS苹果应该程序
C++、C#开发WindowsPhone应用程序
WEB设计运用HTML、CSS、Jquery、Javascript设计进行排版，实现静态页面互动特效。
总结：APP应用程序需要在智能设备以及平板电脑上进行安装。而WEB页面无需安装，只要上传WEB服务器后就可以通过域名在终端浏览器访问。
注：WEB设计采用响应式设计排版，可以有效解决不同显示屏幕分辨率问题，适应屏幕显示页面内容。
最近随着微信小程序的上线，估计有很多人就会疑惑，已经有App选择了，为什么要选择做应用小程序。
如果站在业务和开发者角度来看就很容易理解，微信小程序的成本要远低于独立App版本。因为微信小程序就是基于移动网页版技术的。
成本低这一点，就足够吸引资金不充裕，缺乏技术人员的小的创业团队，移动Web版由于开发方式不同降低了技术门槛。同时微信则提供了一个开放的开发平台给商户和创业者，何乐而不为呢。
所以作为业务方，就得把移动App和移动Web版的区别搞清楚，根据自己的实际需求来选择产品方案。
这两者之间的区别有如下：
1，产品环境打开方式的不同
移动Web：需要移动设备上的浏览器且支持上网；
App客户端：由智能移动设备的操作系统来支持,包括安卓、以及基于安卓的各种的二次开发系统、苹果等操作系统，并安装此应用之后才可以打开。
2，产品使用门槛高低不同
移动Web：支持跨平台，无安装成本，用户只需要输入URL（网址地址）即可访问,一个浏览器就满足了任何需求，使用门槛较低；
App客户端：用户需要下载并安装之后才可以打开,使用成本相对较高。
3，用户体验
移动Web：每次加载时，会给用户一种感觉“需要等待一下才可以展示内容”，影响用户使用的流畅度
App客户端：操作习惯符合用户预期，对于一些并不非依赖网络的应用，通过app实现也可以减少加载资源的时间，比如缓存内的内容。
4，产品的内容展示
移动Web：内容展示上有了局限，页面信息的布局也需要考虑设备中浏览器的兼容性以及浏览器的上下导航；
App客户端：可以整屏的显示所有的页面信息，无需考虑其它因素。
5，快速更新产品迭代
移动Web：站点服务器自己可控，保证了较为敏捷相应到用户的时间，产品更新、设计、开发完成后只需发布到线上服务器，用户通过浏览器访问WAP，就能看到最新修改的网页；
App客户端：因各应用平台发布应用都需要一定的审核周期，在产品做出调整后，相应到用户的周期相对较长。
所以我个人的看法就是，对于交互性低频次的应用完全可以选择移动Web版，如果是社交类的工具，那就更好不过，完全可以利用微信这个小程序平台来做。
还有比如一些实体或硬件产品的商家也可以不用勉强开发独立App，因为本身对积累用户的要求并不高，毕竟是以销售实体为主。小程序也能够借助微信提供了一些基础的系统调用，使移动Web版成为一种选择的可能。
总之，我觉得主要还是根据这两者之间不同的特点，结合自己的实际情况来选择。
Web App即是一种框架型APP开发模式(HTML5 APP 框架开发模式)，该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。
原生APP又称Native App，该开发针对IOS、Android、Windows等不同的手机操作系统要采用不同的语言和框架进行开发，该模式通常是由“云服务器数据+APP应用客户端”两部份构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。
开发方面的区别
移动Web App
1、因为运行在移动设备的浏览器上，所以只需要一个开发项目
2、这种应用可以使用HTML5,CSS3以及JavaScript以及服务器端语言来完成(PHP,Ruby on Rails,Python)
3、这里可没有标准的SDK，基本任意选择别忘了有一些跨平台的开发工具，比如PhoneGap, Sencha Touch 2以及Appcelerator Titanium等等。
原生App
1、每一种移动操作系统都需要独立的开发项目
2、每种平台都需要独立的开发语言。Java(Android), Objective-C(iOS)以及Visual C++(Windows phone)等等
3、需要使用各自的软件开发包，开发工具以及各自的控件
能力方面的区别
移动Web App，只能使用有限的移动硬件设备功能。原生App，能够与移动硬件设备的底层功能，比如个人信息，摄像头以及重力加速器等等
获取方法的区别
移动Web App
1、从移动设备上的浏览器访问
2、不需要安装额外的软件
3、软件更新只需要服务器就够了
4、因为现在没有什么商品或卖场提供这种App，所以如何搜索这些移动Web App相当不简单
原生App
1、直接下载到设备
2、以独立的应用程序运行(并不需要浏览器)
3、用户必须手动去下载并安装这些原生App
4、有一些商店与卖场来帮助用户寻找你的App，目前app市场不计其数。
版本控制的区别
移动Web App，所有的用户都是用同样的版本。原生App，用户可以自由地选择是否更新软件版本，所以会出现不同用户同时使用不同版本的情况
原生App的优势:
1、比移动Web App运行快
2、一些商店与卖场会帮助用户寻找原生App
3、官方卖场的应用审核流程会保证让用户得到高质量以及安全的App
4、官方会发布很多开发工具或者人工支持来帮助你的开发
移动Web App
1、跨平台开发，用户不需要去卖场来下载安装App
2、任何时候都可以发布App，因为根本不需要官方卖场的审核
原生APP的特点：
1、每次获取最新的APP功能，需要升级APP应用;
2、原生型APP应用的安装包相对较大，包含UI元素、数据内容、逻辑框架;
3、手机用户无法上网也可访问APP应用中以前下载的数据。
4、原生型的APP可以调用手机终端的硬件设备(语音、摄像头、短信、GPS、蓝牙、重力感应等)
5、APP应用更新新功能，涉及到每次要向各个应用商店进行提交审核。
App测试方面
不管是移动web App还是原生App，都是需要在移动终端上运行的，那么对移动终端的兼容性配适的需求就是一样的。基本上线前，都需要进行app兼容性测试，app功能测试等，确保产品质量和用户体验。
移动Web无所不在，移动Web是目前唯一的支持各种设备访问的平台，与桌面Web一样，移动Web支持各种标准的协议。移动Web也是唯一一个可供开发者发布移动应用的平台，它将各种移动交互与桌面任务有效地连接了起来;而开发Native App可以充分利用设备的特性，而这一点往往是Web浏览器做不到的，所以对一个产品本身而言，Native App是最佳的选择。
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、小程序、移动网站和微商城等。
0条评论