开发笔记 第605页

[转载]SocialBeta » Blog Archive » 11值得关注的TechStars初创企业—-社会化媒体|社会化媒体营销|社会化设计|社区型网站运营|社会化媒体相关资源分享|We dream of being a Mashable in China..

在孵化器TechStars近日组织的活动中，有不少优秀的初创企业亮相，下面的这11家就是从600多个申请者中脱颖而出的，不少有着很酷的创意：

Nestio：减少找公寓的烦恼

创始人:
Caren Maio – CEO, Mike O’Toole – CTO, Matt Raoul – COO

目标:
Nestio想在一个清爽有序的界面上帮你摆脱寻找公寓的烦恼

实现方法:
每年有4000万纽约人寻找住所，为此要花费16亿小时：包括把收集打印资料、频繁的与室友和中介机构联系、翻看Craigslist上众多的帖子。

Nestio通过让用户简便地记录房屋信息来简化这个流程。在“对比图”应用中，用户可以同时比较多个房源的信息。其移动应用允许用户在任何地方拍 摄图片、记录下房屋信息并上传至平台。另外，合住的室友也可以添加到用户的Nestio账户中，他们可以看到房屋信息并加以评论。

ThinkNear：利用优惠券帮商家在淡季吸引顾客

创始人:
Eli Portnoy – CEO, John Hinnegan – CTO

目标:
生意总有忙时与闲时之分，ThinkNear 希望通过优惠券让商家在生意不那么景气的时间段获得更多消费者。

实现方法:
ThinkNear的API能捕捉到商户生意繁忙和不景气的时间信息，然后与天气、交通等宏观信息结合，从而指出什么样的优惠券能最有效的将顾客吸引到商家来，并随后发送手机优惠券。自从2周前开放API之后，已经有了25个基于其开发的应用。

Immersive：将《少数派报告》带入现实

创始人:
Jason Sosa, Alessio Signorini, and Christopher Piekarski

目标:
在2002年的科幻片《少数派报告》中，片中汤姆克鲁斯路经一排数字标牌，标牌扫描了一下他的视网膜就展出了他可能喜欢产品的全息图。而Immersive利用人脸识别技术，展示了一个男人在看向一副卫生巾的数字广告牌时，广告牌自动更换至百威淡啤的场景。

实现方法:
Immersive的人脸识别技术可以判断出广告观众的年龄区间和性别，然后计算出并展示最有效的广告。Immersive也能够知道顾客看广告的时间，然后把时间值和人口统计资料发送给广告主。

“数字标牌和户外广告是35亿美金的生意，”Sosa说，这是仅次于互联网广告的增长最快的广告机会。到2016年，户外广告预计将达到60亿美元。.

而这家公司可以将整个行业中的浪费降至最低。Sosa说这项技术已经被商家试用，而顾客花在观看数字广告上的时间增加了60%。

Friendslist：协助你帮助你的朋友

创始人:
Jonathan Wegener，Benny Wong

目标/实现方法:
你可能知道哪些朋友需要室友，哪些朋友正在找房子。做中间人将双方连接起来并不是件轻松的事。

Friendslist希望移除中间人的角色，通过朋友关系创建分类广告的社交网络。

OnSwipe：帮内容出版商甩掉App

创始人:
Jason Baptiste，Andres Barreto

目标:
“App是垃圾”， Baptiste 说，“昂贵，而且在iPad, iPhones, Android系统上是割裂的。”而App的唯一优点是漂亮的设计。OnSwipe 希望能够“帮助任何内容出版商在不制作App的情况下，高度美化其网页在移动设备上的展示”。

实现方法: 创建OnSwipe账户需要不到5分钟，之后用户连接到类似于wordpress或更加定制化的内容管理系统中，并会看到数以千计的设计方案。出版商仅仅需要复制粘贴网址，选择设计方案，一切就做好了。

在体验OnSwipe所制作出的网页时，用户可以随意点击分享或者保存正在阅读的文章，也能看到朋友们正在读什么。OnSwipe相信这将是一个巨 大的市场，“我们位于两种巨大的变革中”， Baptiste说，“从印刷到数字，从点击到触摸设备。我们有机会改写游戏规则。”

CrowdTwist：找出公司忠实用户并奖励他们

创始人:
Irving Fain, Mike Montero, Josh Bowen

目标:
大多数公司都不清楚他们的忠实用户是谁。CrowdTwist帮助这些公司找到并奖励他们，通过社交网络提升品牌。

实现方法:
CrowdTwist 白标平台为用户提供一系列在各种社交网络上赚取积分的方法。它同时提供对每次社交交互的分析统计，从用户参与度到人口统计学，以便客户分析活动效果。演出公司Live Nation在使用了该服务后，用户参与度提升了900%，票务收入提高了一倍。

Migration Box ：帮所有人迁移到云端

创始人:
Eduardo Fernandez，Carlos Cabanero

目标/实现方法:
Migration Box帮助人们把电子邮件、联系人信息、文档、约会记录等一切东西迁移到云端。据Fernandez说，目前只有5%的网民将有价值的信息放在了云端，而 截至2014年，这个数据将达到70%。Migration Box 是一个平台，用户可以使用多种服务将信息无缝的、轻松的放在云端。

ToVieFor：为设计师品牌组织拍卖

创始人:
Melanie Moore，Eric Jennings

目标:
大多数商品最终给都将被甩卖，有时候它们会被估值过低，以至于顾客感觉自己是在抢劫。这种情况下，其实顾客可以接受更高的价格，但商家无法知道这一点。ToVieFor希望能够通过拍卖使商品的售价和实际价值和出售价格更加接近。

实现方法:
“在这里，女人买到包只需两步，”Melanie Moore说，“决定参与拍卖后，立刻就可以出价，如果成为出价最高者，就可以赢得商品。”Moore说在 ToVieFor上，零售商获得的毛利率会比传统的网上甩货方式高出50-55%。

上线10天以来，ToVieFor拥有5000个用户，15000美金收入，51%的毛利率。要知道时尚电子商务是个300亿美金的大市场，甚至比整个在线广告市场都要大。

Red Rover：为大公司提供p2p学习平台

创始人:
Kevin Prentiss, Tom Krieglstein，Dan Storms

目标:
Red Rover为企业提供p2p学习平台，减少时间的浪费

实现方法:
雇员为公司创造价值同时也是公司最大的成本之一。他们在试图自己克服困难时，会浪费许多时间。而一个有经验的人会帮他们迅速的解决问题。但是在许多大公司里，不是所有雇员都能认识并了解对方。

Red Rover可以导入LinkedIn、Twitter等社交网络中的信息，将公司中的每个雇员统计进在线目录中，帮助彼此不熟悉的雇员进行更多的专业交流。

Shelby.tv：基于朋友推荐的个性定制化频道

创始人:
Reece Pacheco, Dan Spinosa, Henry Sztul ,Joe Yevoli

目标:
Shelby.tv 能收集你朋友在社交网络上的视频分享链接，并将其转化为一个定制化的频道。实现方法: 每天上百万个在线视频被观看，人们观看视频的地方也很多，例如不同朋友的推荐会将你带向YouTube， Facebook等网站。而利用Shelby.tv，你不再需要打开不同的视频播放网站，就能了解朋友的所有推荐。Shelby.tv上的视频也能进行进 一步的社交分享。 到目前为止，Shelby.tv的每个用户每天会在网站上花上15分钟。

Veri：在线游戏竞赛，使学习变得有趣

创始人:
Lee Hoffman, Brian Tobal, Angela Kim

目标:
Veri 希望能通过用户获取世界上所有内容，将其转化为在线游戏竞赛

实现方法:

“不是我们建立Veri，是用户”，Hoffman说，“他们创建问题，提交链接，想出答案。”用户可以将其问题分享到社交网络上，大家共同竞争以 在网站上获得更高排名。当用户答对问题时，他们的总排名将会上升。如果答错了，用户将来到“学习时间”，阅读到相关的文章或观看视频。Veri使得学习变 得更富竞争性、更有趣、更有吸引力。用户在该网站上的平均浏览时间为超过27分钟。

本文链接：http://www.socialbeta.cn/articles/the-11-promising-techstar-startups.html
原文链接http://www.businessinsider.com/the-11-promising-techstar-startups-that-beat-out-600-other-applicants-2011-4#nestio-is-eliminating-apartment-search-headaches-1
译者：@符星辰

转载请保留以上信息和链接，违者必究。

[转载]SocialBeta » Blog Archive » 12个值得关注的LBS营销案例—-社会化媒体|社会化媒体营销|社会化设计|社区型网站运营|社会化媒体相关资源分享|We dream of being a Mashable in China..

最近在微博上看到不少lbs相关的产品和营销案例，本文就整理了最近一段时间的一些lbs方面营销案例，各位如果对lbs感兴趣，可以关注下面这些分享案例的微博，也欢迎大家继续分享这方面的优秀案例。

@Hawk-yin：《波斯王子》是游戏界一个非 常响亮的名字。在DOS年代，她就已经成名。由其改编的电影已经上映。如你还不了解她，没有关系。掏出你的手机，用GPRS定位到其海报灯箱前。你会发现 神秘美丽的塔米娜公主出现在你的屏幕上，如果你可以答对她所提出的问题，你将赢得在movieminutes.com上50分钟的电影观看权。

李伟Nelson：Starbucks 太牛了。新推出Mobile Pour服务：你在路上走着，突然想喝咖啡，通过Mobile Pour APP，允许星巴克知道你的位置，点好你要的咖啡，然后你就接着走你的，走啊走，不一会儿一个星巴克小伙子或者大姑娘就会踩着滑轮车给你送一杯来。目前已 经在美国7个大城市开始。我看过的LBS最佳商业应用。

扩展阅读：http://www.starbucks.com/blog/introducing-starbucks-mobile-pour/987

红杉殷明：iButterfly，属于日本人的浪漫，是我看过的将AR（延伸现实）和LBS（位置服务）结合的最完美的应用，国内的开发者加油啊，可以给大城市里长大的孩子们创造一个更美好的童年。 http://t.cn/hbxAFd

新浪第一互动：【每日营销案例】LBS营销：比利时知名啤酒Stella Artois结合AR与LBS技术,做了一个APP#Le Bar Guide#.开启摄像头对着街道,显示离自己最近的酒吧,包括地址名称。最特别的是,将手机往地上拍摄,还会出现箭头符号,引导一步步走到酒吧.如果喝醉了,APP提供叫车服务http://t.cn/htJbo3

http://v.youku.com/v_show/id_XMjUwOTU4NjI0.html

LBS观景台：#LBS营销案例# 伦敦博物馆手机行销案例“时光机器”。这是伦敦博物馆推出的基于iPhone的应用程式。用户可以使用GPS定位，然后把手机对准当前所在的位置，那么系统会帮你匹配当前位置几十年前的样子。LBS的互动营销可以借鉴。http://t.cn/htFl08

LBS观景台：走进一家杂货店，手机响了，提醒你 这家店现正提供的优惠券，结账时向收银员出示接收到的手机优惠券即可，你可以自行订制接收哪些商户的提醒，定制触发提示的条件。你会动心吗？采用 Location Labs旗下产品Sparkle平台的手机优惠券应用Cellfire正开始将地理位置服务引入人们的日常生活。www.cellfire.com

陈亮途Hugo：#分享#Mini 设计了一个GPS定位地图的程式，显示了一部虚拟的Mini、你的和其他用户的位置。只要你到了虚拟车的50米内，你可以得到那部车。假如别的用户在你 50米内，又可以抢了你的车。假如你能够保管你的Mini一周，你就可以得到真的Mini一部！推广期间，上千瑞典人在街头奔跑！http://t.cn/hq0ru7

陈亮途Hugo：#分享##LBS#美 国密尔沃基只有400个Foursquare的用户，当地餐厅AJ Bombers发起了一个Party，就是假如有50个人在某一个时间同时出现在该餐厅，大家就可以拿到一个蜂群徽章（Swarm Badge），可以优惠价吃大餐。这消息在推特上被转发了。结果在约定时间160人到达了餐厅，餐厅赚了本来3天才能有的生意！

扩展阅读：http://blog.steffanantonas.com/case-study-how-to-use-foursquare-to-draw-a-crowd-into-your-restaurant.htm

bjfangyan：SCVNGR将商家优惠活动引入LBS社交游戏 http://t.cn/hBThSi 位置游戏公司SCVNGR新推出的LevelUp平台把基于地理位置的游戏引入到优惠活动领域。你使用LevelUp越多，你就可以越早进入某个特定商家的新“级别”，从而获得更好的优惠。

唐寅Jacob：【大众汽车】为即将到来的上海车展特别制作了一款手机App，是基于LBS 位置服务的游戏，在上海，苏州，杭州三个城市收集虚拟徽章，就可以免费获得上海车展门票，并且有机会获得限量版大众汽车车模。欢迎下载体验！http://t.cn/hBjej1

派代网官方：【#派代资讯#】《凡客诚品试水LBS营销 已有万人参与》据凡客诚品方面透露，凡是冒泡网的用户，即可利用冒泡网的地理位置服务(LBS)方式，在北京主要公交站点和北京各地铁站等站牌广告位置使用手机“签到”，活动推出当日即吸纳上万人参与。http://t.cn/hbw7sV

麻省理工科技创业：BreezeLiving：基于AR和LBS的周边优惠服务http://t.cn/hBMDar 渣打银行 (中国) 也赶时髦啦。

[转载]Android与服务器端数据交互（基于SOAP协议整合android+webservice） – 东子哥 – 博客园.

上一节中我们通过http协议，采用HttpClient向服务器端action请求数据。当然调用服务器端方法获取数据并不止这一种。WebService也可以为我们提供所需数据，

那么什么是webService呢？，它是一种基于SAOP协议的远程调用标准，通过webservice可以将不同操作系统平台，不同语言，不同技术整合到一起。

我们在PC机器java客户端中，需要一些库，比如XFire,Axis2,CXF等等来支持访问WebService，但是这些库并不适合我们资源有限 的Android手机客户端，做过JAVA ME的人都知道有KSOAP这个第三方的类库，可以帮助我们获取服务器端webService调用，当然KSOAP已经提供了基于Android版本的 jar包了，那么我们就开始吧：

首先下载KSOAP包：ksoap2-android-assembly-2.5.2-jar-with-dependencies.jar包

然后新建android项目：并把下载的KSOAP包放在android项目的lib目录下：右键->build path->configure build path–选择Libraries，如图：

以下分为七个步骤来调用WebService方法：

第一：实例化SoapObject 对象，指定webService的命名空间（从相关WSDL文档中可以查看命名空间），以及调用方法名称。如：

//命名空间
private static final String serviceNameSpace="http://WebXml.com.cn/";
//调用方法(获得支持的城市)
private static final String getSupportCity="getSupportCity";

//实例化SoapObject对象
SoapObject request=new SoapObject(serviceNameSpace, getSupportCity);

第二步：假设方法有参数的话,设置调用方法参数

request.addProperty(“参数名称”,”参数值”);

第三步：设置SOAP请求信息(参数部分为SOAP协议版本号，与你要调用的webService中版本号一致):

//获得序列化的Envelope
SoapSerializationEnvelope envelope=new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.bodyOut=request;

第四步：注册Envelope,

(new MarshalBase64()).register(envelope);

第五步：构建传输对象，并指明WSDL文档URL：

//请求URL
private static final String serviceURL="http://www.webxml.com.cn/webservices/weatherwebservice.asmx";
//Android传输对象
AndroidHttpTransport transport=new AndroidHttpTransport(serviceURL);
transport.debug=true;

第六步：调用WebService(其中参数为1：命名空间+方法名称，2：Envelope对象):

transport.call(serviceNameSpace+getWeatherbyCityName, envelope);

第七步：解析返回数据：

if(envelope.getResponse()!=null){
return parse(envelope.bodyIn.toString());
}

/**************
* 解析XML
* @param str
* @return
*/
private static List parse(String str){
String temp;
List list=new ArrayList();
if(str!=null && str.length()>0){
int start=str.indexOf("string");
int end=str.lastIndexOf(";");
temp=str.substring(start, end-3);
String []test=temp.split(";");

for(int i=0;i if(i==0){
temp=test[i].substring(7);
}else{
temp=test[i].substring(8);
}
int index=temp.indexOf(",");
list.add(temp.substring(0, index));
}
}
return list;
}

这样就成功啦。那么现在我们就来测试下吧，这里有个地址提供webService天气预报的服务的，我这里只提供获取城市列表：

//命名空间
private static final String serviceNameSpace="http://WebXml.com.cn/";
//请求URL
private static final String serviceURL="http://www.webxml.com.cn/webservices/weatherwebservice.asmx";
//调用方法(获得支持的城市)
private static final String getSupportCity="getSupportCity";
//调用城市的方法(需要带参数)
private static final String getWeatherbyCityName="getWeatherbyCityName";
//调用省或者直辖市的方法(获得支持的省份或直辖市)
private static final String getSupportProvince="getSupportProvince";

然后你可以在浏览器中输入地址（WSDL）：serviceURL,你会看到一些可供调用的方法：

我们选择获取国内外主要城市或者省份的方法吧：getSupportProvice,然后调用，你会发现浏览器返回给我们的是xml文档：

<!--?xml version="1.0" encoding="utf-8" ?-->
-
直辖市
特别行政区
黑龙江
吉林
辽宁
内蒙古
河北
河南
山东
山西
江苏
安徽
陕西
宁夏
甘肃
青海
湖北
湖南
浙江
江西
福建
贵州
四川
广东
广西
云南
海南
新疆
西藏
台湾
亚洲
欧洲
非洲
北美洲
南美洲
大洋洲

我们可以用 listview来显示：

那么下面我将给出全部代码：

public class WebServiceHelper {

//WSDL文档中的命名空间
private static final String targetNameSpace="http://WebXml.com.cn/";
//WSDL文档中的URL
private static final String WSDL="http://webservice.webxml.com.cn/WebServices/WeatherWebService.asmx?wsdl";

//需要调用的方法名(获得本天气预报Web Services支持的洲、国内外省份和城市信息)
private static final String getSupportProvince="getSupportProvince";
//需要调用的方法名(获得本天气预报Web Services支持的城市信息,根据省份查询城市集合：带参数)
private static final String getSupportCity="getSupportCity";
//根据城市或地区名称查询获得未来三天内天气情况、现在的天气实况、天气和生活指数
private static final String getWeatherbyCityName="getWeatherbyCityName";

/********
* 获得州，国内外省份和城市信息
* @return
*/
public List getProvince(){
List provinces=new ArrayList();
String str="";
SoapObject soapObject=new SoapObject(targetNameSpace,getSupportProvince);
//request.addProperty("参数", "参数值");调用的方法参数与参数值（根据具体需要可选可不选）

SoapSerializationEnvelope envelope=new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.dotNet=true;
envelope.setOutputSoapObject(soapObject);//envelope.bodyOut=request;

AndroidHttpTransport httpTranstation=new AndroidHttpTransport(WSDL);
//或者HttpTransportSE httpTranstation=new HttpTransportSE(WSDL);
try {

httpTranstation.call(targetNameSpace+getSupportProvince, envelope);
SoapObject result=(SoapObject)envelope.getResponse();
//下面对结果进行解析，结构类似json对象
//str=(String) result.getProperty(6).toString();

int count=result.getPropertyCount();
for(int index=0;index provinces.add(result.getProperty(index).toString());
}

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (XmlPullParserException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return provinces;
}

/**********
* 根据省份或者直辖市获取天气预报所支持的城市集合
* @param province
* @return
*/
public List getCitys(String province){
List citys=new ArrayList();
SoapObject soapObject=new SoapObject(targetNameSpace,getSupportCity);
soapObject.addProperty("byProvinceName", province);
SoapSerializationEnvelope envelope=new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.dotNet=true;
envelope.setOutputSoapObject(soapObject);

AndroidHttpTransport httpTransport=new AndroidHttpTransport(WSDL);
try {
httpTransport.call(targetNameSpace+getSupportCity, envelope);
SoapObject result=(SoapObject)envelope.getResponse();
int count=result.getPropertyCount();
for(int index=0;index citys.add(result.getProperty(index).toString());
}

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (XmlPullParserException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return citys;
}

/***************************
* 根据城市信息获取天气预报信息
* @param city
* @return
***************************/
public WeatherBean getWeatherByCity(String city){

WeatherBean bean=new WeatherBean();

SoapObject soapObject=new SoapObject(targetNameSpace,getWeatherbyCityName);
soapObject.addProperty("theCityName",city);//调用的方法参数与参数值（根据具体需要可选可不选）

SoapSerializationEnvelope envelope=new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.dotNet=true;
envelope.setOutputSoapObject(soapObject);//envelope.bodyOut=request;

AndroidHttpTransport httpTranstation=new AndroidHttpTransport(WSDL);
//或者HttpTransportSE httpTranstation=new HttpTransportSE(WSDL);
try {
httpTranstation.call(targetNameSpace+getWeatherbyCityName, envelope);
SoapObject result=(SoapObject)envelope.getResponse();
//下面对结果进行解析，结构类似json对象
bean=parserWeather(result);

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (XmlPullParserException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return bean;
}

/**
* 解析返回的结果
* @param soapObject
*/
protected WeatherBean parserWeather(SoapObject soapObject){
WeatherBean bean=new WeatherBean();

List> list=new ArrayList>();

Map map=new HashMap();

//城市名
bean.setCityName(soapObject.getProperty(1).toString());
//城市简介
bean.setCityDescription(soapObject.getProperty(soapObject.getPropertyCount()-1).toString());
//天气实况+建议
bean.setLiveWeather(soapObject.getProperty(10).toString()+"\n"+soapObject.getProperty(11).toString());

//其他数据
//日期，
String date=soapObject.getProperty(6).toString();
//---------------------------------------------------
String weatherToday="今天：" + date.split(" ")[0];
weatherToday+="\n天气："+ date.split(" ")[1];
weatherToday+="\n气温："+soapObject.getProperty(5).toString();
weatherToday+="\n风力："+soapObject.getProperty(7).toString();
weatherToday+="\n";

List icons=new ArrayList();

icons.add(parseIcon(soapObject.getProperty(8).toString()));
icons.add(parseIcon(soapObject.getProperty(9).toString()));

map.put("weatherDay", weatherToday);
map.put("icons",icons);
list.add(map);

//-------------------------------------------------
map=new HashMap();
date=soapObject.getProperty(13).toString();
String weatherTomorrow="明天：" + date.split(" ")[0];
weatherTomorrow+="\n天气："+ date.split(" ")[1];
weatherTomorrow+="\n气温："+soapObject.getProperty(12).toString();
weatherTomorrow+="\n风力："+soapObject.getProperty(14).toString();
weatherTomorrow+="\n";

icons=new ArrayList();

icons.add(parseIcon(soapObject.getProperty(15).toString()));
icons.add(parseIcon(soapObject.getProperty(16).toString()));

map.put("weatherDay", weatherTomorrow);
map.put("icons",icons);
list.add(map);
//--------------------------------------------------------------
map=new HashMap();

date=soapObject.getProperty(18).toString();
String weatherAfterTomorrow="后天：" + date.split(" ")[0];
weatherAfterTomorrow+="\n天气："+ date.split(" ")[1];
weatherAfterTomorrow+="\n气温："+soapObject.getProperty(17).toString();
weatherAfterTomorrow+="\n风力："+soapObject.getProperty(19).toString();
weatherAfterTomorrow+="\n";

icons=new ArrayList();
icons.add(parseIcon(soapObject.getProperty(20).toString()));
icons.add(parseIcon(soapObject.getProperty(21).toString()));

map.put("weatherDay", weatherAfterTomorrow);
map.put("icons",icons);
list.add(map);
//--------------------------------------------------------------

bean.setList(list);
return bean;
}

//解析图标字符串
private int parseIcon(String data){
// 0.gif，返回名称0,
int resID=32;
String result=data.substring(0, data.length()-4).trim();
// String []icon=data.split(".");
// String result=icon[0].trim();
// Log.e("this is the icon", result.trim());

if(!result.equals("nothing")){
resID=Integer.parseInt(result.trim());
}
return resID;
//return ("a_"+data).split(".")[0];
}
}

以及帮助类：

public class WebServiceUtil {

//命名空间
private static final String serviceNameSpace="http://WebXml.com.cn/";
//请求URL
private static final String serviceURL="http://www.webxml.com.cn/webservices/weatherwebservice.asmx";
//调用方法(获得支持的城市)
private static final String getSupportCity="getSupportCity";
//调用城市的方法(需要带参数)
private static final String getWeatherbyCityName="getWeatherbyCityName";
//调用省或者直辖市的方法(获得支持的省份或直辖市)
private static final String getSupportProvince="getSupportProvince";

/*************
* @return城市列表
*************/
public static List getCityList(){
//实例化SoapObject对象
SoapObject request=new SoapObject(serviceNameSpace, getSupportCity);
//获得序列化的Envelope
SoapSerializationEnvelope envelope=new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.bodyOut=request;
(new MarshalBase64()).register(envelope);
//Android传输对象
AndroidHttpTransport transport=new AndroidHttpTransport(serviceURL);
transport.debug=true;

//调用
try {
transport.call(serviceNameSpace+getWeatherbyCityName, envelope);
if(envelope.getResponse()!=null){
return parse(envelope.bodyIn.toString());
}

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (XmlPullParserException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

return null;
}

public static List getProviceList(){
//实例化SoapObject对象
SoapObject request=new SoapObject(serviceNameSpace, getSupportProvince);
//获得序列化的Envelope
SoapSerializationEnvelope envelope=new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.bodyOut=request;
(new MarshalBase64()).register(envelope);
//Android传输对象
AndroidHttpTransport transport=new AndroidHttpTransport(serviceURL);
transport.debug=true;

//调用
try {
transport.call(serviceNameSpace+getWeatherbyCityName, envelope);
if(envelope.getResponse()!=null){
return null;
}

} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (XmlPullParserException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

return null;
}

/*************
* @param cityName
* @return
*************/
public static String getWeather(String cityName){

return "";
}

/**************
* 解析XML
* @param str
* @return
*/
private static List parse(String str){
String temp;
List list=new ArrayList();
if(str!=null && str.length()>0){
int start=str.indexOf("string");
int end=str.lastIndexOf(";");
temp=str.substring(start, end-3);
String []test=temp.split(";");

for(int i=0;i if(i==0){
temp=test[i].substring(7);
}else{
temp=test[i].substring(8);
}
int index=temp.indexOf(",");
list.add(temp.substring(0, index));
}
}
return list;
}

/*********
* 获取天气
* @param soapObject
*/
private void parseWeather(SoapObject soapObject){
//String date=soapObject.getProperty(6);
}
}

以上就是我所作的查询天气预报的全部核心代码了，读者可以根据注释以及本文章了解下具体实现，相信很快就搞明白了，运行结果如下：

到此结束，下一节主要是socket通信了。

[转载]【原创】构建高性能ASP.NET站点 第五章—性能调优综述（中篇） – ASP.NET 架构 – 博客园.

构建高性能ASP.NET站点 第五章—性能调优综述（中篇）

前言：本篇主要讲述用一些简单的工具来分析一些与站点性能有关的数据，在上一篇文章中，我们讨论了一下性能调优的一般过程，本篇就开始介绍一些方法和工具，让大家快速的入门。

系列文章链接：

构建高性能ASP.NET站点 开篇

构建高性能ASP.NET站点之一 剖析页面的处理过程（前端）

构建高性能ASP.NET站点之二 优化HTTP请求(前端)

构建高性能ASP.NET站点之三 细节决定成败

构建高性能ASP.NET站点 第五章—性能调优综述（前篇）

大型高性能ASP.NET系统架构设计

构建高性能ASP.NET站点 第五章—性能调优综述（中篇）

构建高性能ASP.NET站点 第五章—性能调优综述（后篇）

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

本章的议题如下：

性能调优的一般过程

利用分析工具分析页面加载信息

利用分析工具分析性能瓶颈

利用分析工具分析加载页面信息

站点的优化说到底还是站点每一个页面的优化，即使得站点的页面更快的呈现在用户的眼前。所以在此之前，我们首先来看看一个web页面的组成部分：

1. Html文件:在ASP.NET中，Html文件通常是通过解析.aspx页面而产生的。而这个解析过程在服务端进行，同时这个过程也消耗了服务端的大部分资源。

2. 图片和flash文件：一个站点往往包含很多这样的的文件。

3. Js和css文件：这些文件可以阻止页面的呈现。

清楚了页面的组成部分之后，我们可以把使得页面加载变慢的因素分为如下几类：

1. 服务端的花费大量时间解析.aspx，也就是说服务端产生html文本的时间过长（导致这个问题的原因很多，例如数据库查询很慢，影响了页面的生成）。

2. 在服务端和浏览器之间，传递html文本花费大量的时间（例如，页面中的Viewstate很大，网络很慢等）。

3. 图片和flash文件的加载花费大量的时间。

4. Js和css的加载花费大量的时间。

为了使得一个页面的加载变快，那么我们就得知道：是以上哪一个过程影响了速度(本系列的后续文章会详细讲述)。一旦知道了是那类问题导致了性能问题，那么我们就可以对症下药。

下面我们就通过一些工具来简单的查看和分析站点的性能，目的让大家快速的了解如何进行简单的性能分析。

我们用瀑布图来分析页面的每个组成部分加载所花的时间，例如下面就是博客园首页加载的分析图（部分的截图）。

我们可以通过图中的“时间线“长短来知道每个文件加载的时间。时间线长越长，那么加载该文件的时间越长，反之。

看完了上面的图之后，大家应该很想知道：上面的图是如何生成的，那么下面就介绍一些生成页面加载瀑布图的工具。

我们首先来看看：Firefox+Firebug

Firefox下载地址：http://www.mozilla.com/en-US/firefox/

Firebug下载地址：http://getfirebug.com/

下面就开始演示如何生成页面加载的瀑布图（如果熟悉这个流程的朋友可以跳过此段）

1. 打开Firefox，然后按下F12,就看到如下的画面：

2. 在Firebug中，在选择“网络”下拉框中选择“启用”。

OK，下面我们就来详细的看看在瀑布图中一些数据和图示的意义。

1． 请求和响应的相关信息

在瀑布图中，点击每一行的”+”如下：

符号展开之后，我们可以看到所有的请求和响应头，如下：

2． 时间线的相关信息

当我们把鼠标移到着色的时间线bar上面的时候，我们就可以看到请求该文件所花的时间的详细信息，如下：

我们用一个表格来讲述每个时间段的含义：

3． 页面级的请求信息

也就是整个页面的请求的一些汇总信息。

OK，今天就基本讲述这些，下一篇就开始讲述利用分析工具分析性能瓶颈，用上面的瀑布图来分析一些常见的性能问题，这些性能问题会在后续文章中一个个的给出解决方案，敬请关注！ ：）

[转载]【转】大型高性能ASP.NET系统架构设计 – ASP.NET 架构 – 博客园.

大型高性能ASP.NET系统架构设计

大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。

系列文章链接：

构建高性能ASP.NET站点 开篇

构建高性能ASP.NET站点之一 剖析页面的处理过程（前端）

构建高性能ASP.NET站点之二 优化HTTP请求(前端)

构建高性能ASP.NET站点之三 细节决定成败

构建高性能ASP.NET站点 第五章—性能调优综述（前篇）

大型高性能ASP.NET系统架构设计

构建高性能ASP.NET站点 第五章—性能调优综述（中篇）

构建高性能ASP.NET站点 第五章—性能调优综述（后篇）

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

大型动态应用系统又可分为几个子系统：

Web前端系统

负载均衡系统

数据库集群系统

缓存系统

分布式存储系统

分布式服务器管理系统

代码分发系统

Web前端系统

为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服 务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。

该Web前端系统基于IIS/ASP.NET等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理。

负载均衡系统

负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs,nginx。大多数网站都是硬件、软件负载均衡系统并用。

数据库集群系统

由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系?

我们可以采用如上图所示的方案：

1)使用SQL数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。

2)使用同步机制实现快速将主库(写库)的数据库复制到从库(读库)。一个主库对应多个从库，主库数据实时同步到从库。

3)写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。

4)读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。

5)数据库服务器和应用服务器分离。

6)从数据库使用BigIP做负载均衡。

缓存系统

缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcachd。使用正确的缓存系统可以达到实现以下目标：

1、使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。

2、减轻对数据库及存储集服务器的访问压力。

3、Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。

分布式存储系统

Web系统平台中的存储需求有下面两个特点：

1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。

2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。

因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。(这个地方需要加入对某个分布式存储系统的简单介绍。)

分布式服务器管理系统

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。

在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。

它是基于C/S 结构的，所有的服务器配置和管理脚本程序都保存在Cfengine Server上，而被管理的服务器运行着 Cfengine Client程序，Cfengine Client通过SSL加密的连接定期的向服务器端发送请求以获取最新的配置文件和管理命令、脚本程序、补丁安装等任务。

有了Cfengine 这种集中式的服务器管理工具，我们就可以高效的实现大规模的服务器集群管理，被管理服务器和 Cfengine Server可以分布在任何位置，只要网络可以连通就能实现快速自动化的管理。

代码分发系统

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，为了满足集群环境下程序代码的批量分发和更新，我们还需要一个程序代码发布系统。

这个发布系统可以帮我们实现下面的目标：

1) 生产环境的服务器以虚拟主机方式提供服务，不需要开发人员介入维护和直接操作，提供发布系统可以实现不需要登陆服务器就能把程序分发到目标服务器。

2) 我们要实现内部开发、内部测试、生产环境测试、生产环境发布的4个开发阶段的管理，发布系统可以介入各个阶段的代码发布。

3) 我们需要实现源代码管理和版本控制，SVN可以实现该需求。

这里面可以使用常用的工具Rsync，通过开发相应的脚本工具实现服务器集群间代码同步分发。

[转载]SQL点滴9—使用with语句来写一个稍微复杂sql语句 – Tyler‘s DoNet – 博客园.

今天偶尔看到SQL中也有with关键字，好歹也写了几年的SQL语句，居然第一次接触，无知啊。看了一位博主的文章，自己添加了一些内容，做了 简单的总结，这个语句还是第一次见到，学习了。我从简单到复杂地写，希望高手们不要见笑。下面的sql语句设计到三个表，表的内容我用txt文件复制进 去，这里不妨使用上一个随笔介绍的建立端到端的package的方法将这些表导入到数据库中，具体的就不说了。

从这里下载文件employees.txt，customers.txt，orders.txt

参考文章：http://www.cnblogs.com/wwan/archive/2011/02/24/1964279.html

使用package导入数据：http://www.cnblogs.com/tylerdonet/archive/2011/04/17/2017471.html

简单的聚合

从orders表中选择各个年份共有共有多少客户订购了商品

第一种写法，我们可以写成这样

select YEAR(o.orderdate) orderyear,COUNT(distinct(custid)) numCusts
from Sales.Orders o
group by YEAR(o.orderdate)
go

要注意的是如果把group by YEAR(o.orderdata)换成group by orderyear就会出错，这里涉及到sql语句的执行顺序问题，有时间再了解一下
第二种写法，

select orderyear,COUNT(distinct(custid))numCusts
from (select YEAR(orderdate) as orderyear,custid from sales.orders) as D
group by orderyear
go

在from语句中先得到orderyear，然后再select语句中就不会出现没有这个字段的错误了
第三种写法，

select orderyear,COUNT(distinct(custid)) numCusts
from (select YEAR(orderdate),custid from sales.orders) as D(orderyear,custid)
group by orderyear
go

在as D后面加上选择出的字段，是不是更加的清楚明了呢！
第四种写法，with出场了

with c as(
select YEAR(orderdate) orderyear, custid from sales.orders)
select orderyear,COUNT(distinct(custid)) numCusts from c group by orderyear
go

with可以使语句更加的经凑，下面是权威解释。
指定临时命名的结果集，这些结果集称为公用表表达式 (CTE)。该表达式源自简单查询，并且在单条 SELECT、INSERT、UPDATE、MERGE 或 DELETE 语句的执行范围内定义。该子句也可用在 CREATE VIEW 语句中，作为该语句的 SELECT 定义语句的一部分。公用表表达式可以包括对自身的引用。这种表达式称为递归公用表表达式。

—-MSDN

第五种写法，也可以借鉴第三种写法，这样使语句更加清楚明了，便于维护

with c(orderyear,custid) as(
select YEAR(orderdate),custid from sales.orders)
select orderyear,COUNT(distinct(custid)) numCusts from c group by c.orderyear
go

上面5中写法都得到相同的结果，如下图1：图1
添加计算

现在要求要求计算出订单表中每年比上一年增加的客户数目，这个稍微复杂

with yearcount as(
select YEAR(orderdate) orderyear,COUNT(distinct(custid)) numCusts from sales.orders group by YEAR(orderdate))
select cur.orderyear curyear,cur.numCusts curNumCusts,prv.orderyear prvyear,prv.numCusts prvNumCusts,cur.numCusts-prv.numCusts growth
from yearcount cur left join yearcount prv on cur.orderyear=prv.orderyear+1
go

这里两次使用到with结果集。查询得到的结果如下图2

图2

复杂的计算

查找所有美国雇员掌握的所有至少有一个订单的客户的客户id，查询语句如下

with TheseEmployees as(
select empid from hr.employees where country='USA'),
CharacteristicFunctions as(
select custid,
case when custid in (select custid from sales.orders as o where o.empid=e.empid) then 1 else 0 end as charfun
from sales.customers as c cross join TheseEmployees as e)
select custid,min(charfun) from CharacteristicFunctions group by custid having min(charfun)=1
go

这里嵌套with语句，第with语句查找美国雇员的id，第二个语句使用这个结果和拥有客户的客户id和拥有关系标识做笛卡尔积运算。最后从这个笛卡尔积中通过标识找到最终的custid。
结果如下图3

图3

这里只有简单地介绍，没有深入，高手们不要见笑啊。

[转载]【原创】构建高性能ASP.NET站点之二 优化HTTP请求(前端) – ASP.NET 架构 – 博客园.

上一篇文章主要讲述了请求一个页面的过程,同时也提出了在这个过程中的一些优化点,本篇就开始细化页面的请求过程并且提出优化的方案.同时,在上篇文章中,不少朋友也提出了一些问题,在本篇中也对这些问题给出了回答!

系列文章链接：

构建高性能ASP.NET站点 开篇

构建高性能ASP.NET站点之一 剖析页面的处理过程（前端）

构建高性能ASP.NET站点之二 优化HTTP请求(前端)

构建高性能ASP.NET站点之三 细节决定成败

构建高性能ASP.NET站点 第五章—性能调优综述（前篇）

大型高性能ASP.NET系统架构设计

构建高性能ASP.NET站点 第五章—性能调优综述（中篇）

构建高性能ASP.NET站点 第五章—性能调优综述（后篇）

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

本篇的议题如下:

HTTP请求的优化

HTTP请求的优化

在一个网页的请求过程中,其实整个页面的html结构(就是页面的那些html骨架)请求的时间是很短的,一般是占整个页面的请求时间的10%-20%.在页面加载的其余的时间实际上就是在加载页面中的那些flash,图片,脚本的资源. 一直到所有的资源载入之后,整个页面才能完整的展现在我们面前.

下面,我们就从一个页面开始讲述:

小洋,燕洋天

<script src="../demo.js" type="text/javascript">
      </script>
<div><img src="../images/1.gif" alt="" />
<img src="../images/2.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/3.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/4.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/5.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/6.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/7.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/8.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/7.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/8.gif" alt="" /></div>

如果我们向服务器请求这个页面,客户端的浏览器首先请求到的数据就是html骨架,即:

小洋,燕洋天

<script src="../demo.js" type="text/javascript">
      </script>
<div><img src="../images/1.gif" alt="" />
<img src="../images/2.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/3.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/4.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/5.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/6.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/7.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/8.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/7.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/8.gif" alt="" /></div>

在此之前,首先来普及一下页面加载的小知识:

当页面的html骨架载入了之后,浏览器就开始解析页面中标签,从上到下开始解析.

首先是head标签的解析,如果发现在head中有要引用的js脚本,那么浏览器此时就开始请求脚本,此时整个页面的解析过程就停了下来,一直到js请求完毕.

之后页面接着向下解析,如解析body标签,如果在body中有img标签,那么浏览器就会请求img的src对应的资源,如果有多个img标签,那么浏览器就一个个的解析,解析不会像js那样等待的,如果发现img的url地址是同一个地址,那么浏览器就会充分的利用这个已经打开的tcp连接顺序的去一个个的请求图片,如果发现有的img的url地址不同,那么浏览器就另开tcp连接,发送http请求.

注意之前请求js的区别:请求需要js,浏览器会一直等待,不在解析下面的html标签

但是解析到img的时候,尽管此时需要加载图片,但是页面的解析过程还是会继续下去的,然后决定是否发送新的tcp连接加载资源.

大家可能觉得这个之前的代码片段一样,确实代码是一样的,但是,在最开始的时候,发送到浏览器中的只是那些html的代码,任何的js脚本和图片还没有发送过来.

当html代码到了浏览器中,那么浏览器就开始一步步的解析这些代码了,只要遇到了需要加载的资源,浏览器就向服务器发出http请求,请求所需的资源.

整个页面的加载时间图如下:

大家从图中可以看出:

第一条线中分为一半黄色和一半蓝色,其实黄色的部分就代表了打开一个tcp连接花的时间,而后面的蓝色的部分就是请求整个html骨架文档的时间.可以看出,请求html骨架的时间是很短的.其余蓝色的线就表示了图片,脚本资源加载所花的时间.

很显然,这样页面的整个加载时间就很长了.因为页面的加载几乎是顺序的载入,时间就是所有资源加载时间的总和.

下面我们把上面的页面代码代为如下:

小洋,燕洋天

<script src="../demo.js" type="text/javascript">
    </script>
<div><img src="http://demo1.com/images/1.gif" alt="" />
<img src="http://demo1.com/images/2.gif" alt="" />
<img src="http://demo2.com/image/3.gif" alt="" />
<img src="http://demo2.com/image/4.gif" alt="" />
<img src="http://demo3.com/image/5.gif" alt="" />
<img src="http://demo3/image/6.gif" alt="" />
<img src="http://demo4.com/image/7.gif" alt="" />
<img src="http://demo4.com/image/8.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/7.gif" alt="" />
<img src="http://yanyangtian.cnblogs.com/image/8.gif" alt="" /></div>

我们再来看看页面的加载时间图

这就是所谓的”并行”载入了.

比较一下两段代码的不同:其实就在img的src属性上面:

第一段页面的代码:img的src属性都是指向一个域名的.

第二段页面的代码:img的src属性指向了不同的域名

这样做的结果是什么?

请大家注意比较img的src的不同.

解释之前,首先来看一个小的常识(在上篇文章中也提过):

当页面请求向服务器请求资源的时候,如果浏览器已经在客户端和服务器之前打开了一个tcp连接,而且请求的资源也在开了连接的服务器上,那么以后资源的请求就会充分的利用这个连接去获取资源. 这样也就是第一个时间图的由来.

如果请求的图片分别位于不同的服务器网站,或者那个请求的服务器网站有多个域名,那么因为浏览器就会为每一个域名去开一个tcp连接,发送http请求,这样,结果就是同时开了多tcp连接,这也是第二个时间图的由来.

虽然说并行加载,确实使得页面的载入快了不少,但是也不是每一个图片或者其他的资源都去搞一个不同的域名,像之前的第二个并行载入图片的例子,也是让两个图片利用一个tcp连接.如果每个图片都去开一个连接,这样浏览器就开了很多个连接,也是很费资源的,而且浏览器还可能会”僵死”.而且有时还会严重的影响性能.

所以,这是需要权衡的.

除了上面的优化方式,还有其他的图片优化的加载方式.主要是通过减少http的请求达到优化

大家都知道网站的一个menu菜单,有些菜单就是用图片作出来的.如

如果上面的图片一个个载入,势必影响速度,如果开多和请求,有点得不偿失.而且图片也不是很大,那么就一次把整个menu需要的图片作为整个图片,一次加载,然后通过map的方式,控制点击图片的位置来达到导航的效果.

这样一个问题就是:算出图片的坐标,不能点击了”主页”图片,然后却跳到了”帮助”页面了.

本篇就讲述到这里,下篇讲述其他的资源文件的优化,希望 多多提出建议,争取把这个系列写好!

[转载]【原创】构建高性能ASP.NET站点之一 剖析页面的处理过程（前端） – ASP.NET 架构 – 博客园.

构建高性能ASP.NET站点之一 剖析页面的处理过程（前端）

前言：在对ASP.NET网站进行优化的时候，往往不是只是懂得ASP.NET就足够了的。 在优化的过程中，一般先是找出问题可能存在的地方，然后证明找出的问题就是要解决的问题，确认之后，在进行一些措施。系列文章在结构上的安排是这样的：先讲述前端的调优，我会在文章的标题后面标上”前端”，如果是后台代码的调优，我会在标题上标上”后端”，如果是数据库设计的调优，我会在标题上标上”数据库”，希望大家多多提建议。

系列文章链接：

构建高性能ASP.NET站点 开篇

构建高性能ASP.NET站点之一 剖析页面的处理过程（前端）

构建高性能ASP.NET站点之二 优化HTTP请求(前端)

构建高性能ASP.NET站点之三 细节决定成败

构建高性能ASP.NET站点 第五章—性能调优综述（前篇）

大型高性能ASP.NET系统架构设计

构建高性能ASP.NET站点 第五章—性能调优综述（中篇）

构建高性能ASP.NET站点 第五章—性能调优综述（后篇）

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施

构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

本篇主要剖析过程，让大家有个全面的了解，下一篇就开始分步剖析了。

本篇的议题如下：

剖析页面的解析过程

分析出可能存在的优化点

剖析页面的解析过程

页面的解析过程，这里说的过程不是我们常说的ASP.NET页面的生命周期的过程，而且浏览器请求一个页面，然后浏览器呈现页面的过程。

在本篇的文章中，我会先阐述页面的解析过程，显示从整体上阐述，然后在每一个点上提出优化的方法。先整体，后局部。

当浏览器在请求一个Web页面是从URL开始的。下面就是过程描述：

1． 输入URL地址或者点击URL的一个链接

2． 浏览器根据URL地址，结合DNS，解析出URL对应的IP地址

3． 发送HTTP请求

4． 开始连接请求的服务器并且请求相关的内容（至于请求时怎么被处理的，我们这里暂时不讨论，只是后面的文章要讨论的问题）

5． 浏览器解析从服务器端返回的内容，并且把页面显现出来，同时也继续进行其他的请求。

上面基本上就是一个页面被请求到现实的过程。下面我们就开始剖析这个过程。

当输入URL之后，浏览器就要知道这个URL对应的IP是什么，只有知道了IP地址，浏览器才能准备的把请求发送到指定的服务器的具体IP和端口号上面。

浏览器的DNS解析器负责把URL解析为正确的IP地址。这个解析的工作是要花时间的，而且这个解析的时间段内，浏览器不是能从服务器那里下载到任何的东西的。但是这个解析的过程是可以优化的。试想，如果每次浏览器每次请求一个URL都需要解析，那么每次的请求都有一点的时间消耗，可能这个时间消耗很短，但是性能的提升就是一点点的“调”出来的。如果把对应URL和IP地址缓存起来，那么当再次请求相同的URL时，浏览器就不用去解析，而是直接读取缓存，这样势必会快一点。

其实浏览器和操纵系统是提供了这样的支持的。

当获得了IP地址之后，那么浏览器就向服务器发送HTTP的请求，下面我们就稍微看下这个发送请求是怎么样被发送的：

1． 浏览器通过发送一个TCP的包，要求服务器打开连接

2． 服务器也通过发送一个包来应答客户端的浏览器，告诉浏览器连接开了。

3． 浏览器发送一个HTTP的GET请求，这个请求包含了很多的东西了，例如我们常见的cookie和其他的head头信息。

这样，一个请求就算是发过去了。

请求发送去之后，之后就是服务器的事情了，服务器端的程序，例如，浏览器清楚的文件是一个ASP.NET的页面，那么服务器端就把请求通过IIS交给ASP.NET 运行时，最后进行一系列的活动之后，把最后的结果，当然，一般是以是以html的形式发送到客户端。

其实首先到达浏览器的就是html的那些文档，所谓的html的文档，就是纯粹的html代码，不包含什么图片，脚本，css等的。也就是页面的html结构。因为此时返回的只是页面的html结构。这个html文档的发送到浏览器的时间是很短的，一般是占整个响应时间的10%左右。

这样之后，那么页面的基本的骨架就在浏览器中了，下一步就是浏览器解析页面的过程，也就是一步步从上到下的解析html的骨架了。

如果此时在html文档中，遇到了img标签，那么浏览器就会发送HTTP请求到这个img响应的URL地址去获取图片，然后呈现出来。如果在html文档中有很多的图片，flash，那么浏览器就会一个个的请求，然后呈现。

到这里，大家也许感觉到这种方式有点慢了。确实这个图片等资源文件的请求的部分也是可以优化的。暂不说别的，如果每个图片都要请求，那么就要进行之前说的那些步骤：解析url，打开tcp连接等等。开连接也是要消耗资源的，就像我们在进行数据库访问一样，我们也是尽可能的少开数据库连接，多用连接池中的连接。道理一样，tcp连接也是可以重用的。但是重用也有问题：如果两个图片它们的url地址如下：

代码

请求这些图片的时间消耗如下图：

大家首先看到最上面的黄线的部分，这个黄线就代表了浏览器打开连接，黄线的后半部分为蓝色，就表示浏览器请求到了html的文档。

最上面的第二条蓝线就表示第一个图片已经请求到了，此时请求这个图片使用还是之前的一个tcp的连接。

大家在看到第三条线，前部分是黄色的，表示请求第二个图片的时候又开了一个tcp的连接，这条线的后半部分为蓝色，表示图片已经请求到了。

剩下的要请求的一些图片都使用上一个tcp连接。

确实，tcp的连接时充分的被使用了，但是图片下载的速度确实慢了，从图中看出，图片是一个个的顺序的下载下来的。整个页面的响应时间可想而知。

如果采用下一种方式，如：

可以看出连接时多了，但是图片的几乎都是并行下载下来的，相比而言就快多了。

其实这就是一个权衡的问题了。

实际上浏览器也是内置了以一些优化方式的，例如缓存图片，脚本等。或者采用并行下载图片的方式，谈到并行下载，就如上图所看到的，势必会消耗更多的连接资源。

今天主要对页面的过程进行了初步的剖析，是的大家有个总体的把握，下一篇我们就开始逐步优化，敬请关注，也希望大家多多提出意见和反馈。先谢过了啊！ ：）

版权为小洋和博客园所有，欢迎转载，转载请标明出处给作者。

http://www.cnblogs.com/yanyangtian

[转载]如何剖析一个类 – Tekkaman – 博客园.

[转载]【开源系列】移动互联网项目：三国演义LBS （一）商业计划书 – 美丽人生 – 博客园.

前言：

———————————————–

本开源系列包含了移动互联网项目计划书、总策划案、项目源代码、数据库设计与文档、项目使用的基础框架源码、策划案明细等。

您（您的团队） 掌握了本项目的开源技术，能够快速的开发任意互联网项目，领先其他团队几个脚步。

由于资料过多，本开源系列分为若干阶段进行。源码授权等协议的问题在对应章节进行陈述。

本文为开源系列第一章，精选了商业计划书部分核心思想，原文在附件中，可在本文末尾获取自行下载。

我们希望通过本开源系列结交相关领域的人才朋友，共同聊聊移动互联网相关思路发展。

相关讨论组入口： http://www.pixysoft.net/ (点击进入)

计划书精选：

———————————————–

一、 三国演义LBS 概述

锁定北京、上海、广州三大城市中使用智能手机的高端用户群体，在三国时代的背景下，利用地理位置信息，为用户提供群体社会化游戏互动。让用户从简单的个人地理位置“签到”，逐步引导向基于地理位置的群体性质互动，养成一种全新的社会化生活娱乐习惯。

1.1 三国演义LBS的目标

以三国演义故事情节为背景，在地理位置信息基础上，通过持续性人人互动的游戏机制，引导用户关注、掌握、习惯与依赖移动社会化服务，从而构造出的稳定繁荣的移动社会化平台；为后续的多元化社会化业务的开展打下基础。

1.2 三国演义LBS特点

1) 玩法创新 有持续性

过 于开放的游戏玩法导致失去目的性与娱乐性，过于封闭的游戏导致失去新鲜感；社会群体需要一定的规则方向去遵守不至于迷失，又需要存在不确定的新鲜因素去追 求去刺激自身的探索求知欲。因此三国演义LBS的核心玩法是攻打关卡，追求后续的剧情发展；玩家在预先策划的游戏发展剧情中不断探索，满足自身的好奇心与 征服感。

玩法引入了地理位置因素，增加了游戏的新鲜感，不同地理位置群体在游戏中有差异，而不同群体又有着相同的游戏发展追求；因此让用户能感知新鲜感的存在，也体会到满足新鲜感存在的地理位置成本，形成一种“饥饿感”。

2) 有话可说 有事可做

移动社交流行普及，需要满足群体内在的普遍的轻量级社交需求，并且具备比传统的社交平台更简单、高效、直接的特点；同时需要一个非常低的入门门槛，降低群体的抵触感。

游 戏本质是对现实生活的一种提炼、简化，规避了现实社会中复杂的人际关系、不确定自然因素等，通过简单的“有付出就有收获”的游戏规则吸引用户不断投入发 展，即满足休闲娱乐，又满足一定的社交需求。因此以游戏为切入点，能够减少用户的抗拒与陌生心理，让用户围绕游戏本身有话可说，有事可做，再在此基础上迅 速了解并习惯LBS社会化平台的服务。

3) 快速传播 爆发力强

游戏发展设计依赖群体的推动，而不是个体的努力。只有不断有新用户加入共同发展，提高游戏的繁荣度，游戏的情节才能进一步推动深化，因此参与游戏的用户内在存在了一种推广传播三国演义LBS的需求。

游戏运营基于移动通讯终端，通过合理、合法的手段获取群体之间的人际关系网络，能够迅速的形成一种强人际关系纽带，极大降低运营成本。因此三国演义LBS在技术上提供了推广传播的保证。

4) 盈利模式鲜明 针对性强

三国演义LBS自身提供了一套完善的虚拟货币体系，用户通过充值获取虚拟货币，加快游戏中的发展速度，获取更高的地位感与虚荣心。这是盈利模式的基础保障。

其次，三国演义LBS提供了完善的VIP等级制度，在不同人群中根据投入的资金划分出VIP等级，形成一种地位身份象征。根据VIP等级再建立社会化交互服务，让用户狠心投资，获取身份上的差异，以便有针对性的、有范围的进行社会化交互。

二、 行业与市场分析

2.6 国内LBS现状问题

国内LBS的跟随者还有网易八方（bafang.163.com）、盛大切客（qieke.com）等。虽然打着大公司的牌子，但是仍然无法走出Foursquare设下的游戏规则，也无法在国内掀起一场LBS热潮。他们存在的问题，主要有以下几个方面：

1） 无强取代性

目前的LBS应用大部分处于跟风状态，模仿抄袭美国的Foursquare，因此并没有考虑国内的实际国情，无法针对中国人的性格特点，如谨慎、保守、羊群效应等去提供服务。

技术上大部分在传统的社交平台、微博基础上“强行”加入了地理位置因素，仅仅成为一种辅助信息，因此与传统的电脑客户端社交服务比较，缺少优势、操作琐屑、信息量小，无法成为潮流。

有部分LBS应用具备一定的创新力，例如疯狂城市等，其引入了大富翁等经济玩法因素，但是游戏目的性没有突出社交，没有一种内在的传播推动力与外在的技术保障，因此无法流行。

2） 无法把握地理位置差异产生的成本优势

地理位置差异存在的成本是巨大的，过去传统互联网一直在淹没这种差异，例如淘宝的商品交易搜索、开心网提供的好友推荐等，都提供了一种无差别的推荐机制，试图利用互联网的覆盖性去弱化地利位置差异的成本。

这种传统发展思路，使成本最终会转嫁到其他形式，例如增加服务提供商的运营成本、降低了用户期待感与所提供的服务的心理价值等。

信息的价值是巨大的，未知转变为已知的过程应该付出相应的代价。目前LBS刚刚兴起，但是国内仍然没有一个LBS应用能够把握住地理位置差异去赚取信息不对称产生的巨大价值财富，没有去尝试利用地理位置的差异有目的性的隔离信息流通，从而制造出利润空间。

3） 无法把握社会化交互的核心

无论是签到、还是LBS游戏，都仅仅提供了一种人与平台之间的单向交互；即签到的地点、LBS的地点是静态的死的，这样很容易导致这种游戏规则缺少新鲜感和生命力。

用户签到的目的是希望能够与相同地理位置的人进行交互，但是目前国内LBS平台并没有直接满足此用户需求，仅仅用各种积分制度、排名制度间接的建立人人交互。

因此国内LBS本身是个“错失了交互的时间，在一个仅仅是经过或逗留过的地点，做着与他人没有任何关联的事情”。因此这种LBS的交互没有体现人人社会化交互。

4） 小结

三 国演义LBS设计上把握住了“城市上班族上下班时间无聊，通过参与各种游戏事件，以便认识不同的人，扩大自己的交际圈”这个核心。以游戏为切入点去培养用 户使用LBS应用的习惯，再逐步开放各种基于LBS应用的免费服务。而且服务带有地域性，能够在商家与消费者之间构成双赢的博弈结果。

四、 技术可行性分析

4.6 三国演义LBS的技术选型方案——HTML5

智能手机开发目前仍然属于混乱状态。IPhone开发环境自封闭、Android自身就存在版本控制问题，版本之间不兼容也不向下兼容；WM仍然没有成为主流等。如果需要针对所有的手机系统开发出适用的应用程序，则工作量巨大，版本管理复杂；而且对消费者来说也会迷茫。

考虑到以上存在的问题，本平台实施以HTML5为主、平台应用为辅的技术方案。

HTML5 的前身是 Web Applications 1.0，由 WHATWG 于2004年提出。2007年，它被 W3C 接纳，并于2008年1月22日发布第一份正式草案。2010年随着HTML 5的迅猛发展并牢牢占据了Web开发的核心位置，各大公司如Google、微软、苹果、Mozilla和Opera的浏览器开发业务在这一年都异常繁忙。

虽然在PC系统是微软IE的天下，但是在手机领域，目前并没有一家独大的情况。在这个时期，所有智能手机系统平台却有一个共同点，就是支持HTML5。

HTML5开发主要使用了传统的HTML格式，以及扩展的js语法，因此学习曲线非常低；而且HTML5已经支持本地数据存储、图片数据缓存、获取地理位置信息、socket长链接等功能，因此技术上完全可以胜任目前的LBS平台开发。

使用BS架构，为平台发展升级带来了极大的便利。用户无需下载客户端，仅仅通过浏览器（或者网络访问快捷方式），即可获取最新的信息与数据，用户数据也保存在网络端，不用担心数据丢失被盗等问题。

虽 然HTML5非常强大，但是其无法接触智能手机底层接口，例如无法获取用户联系人列表、无法获取重力感应数据、无法直接操作GPS、WIFI等，有其局限 性。因此需要通过收手机本地应用软件进行支持。考虑到这个因素，三国演义LBS会使用HTML5的同时，必要的时候也运行本地软件应用以便提供更加底层的 数据。但是开发上仍然保持以HTML5为主、本地应用为辅的策略。

相关资料

———————————————–

000 三国演义LBS 商业计划书 v6.0.doc

http://www.boxcn.net/shared/7tkgho1szo

游戏试玩入口

http://www.citi-box.com/sango/sango_login.aspx

我们的最新动态 (Bamboo@pixysoft.net)

• 1.解决comet在多页面中冲突的问题.[2011-1-23]
• 2.优化部分后台逻辑代码.提升首页访问性能[2011-1-20]
• 3.网络Comet平台再次成功对接上线.[2011-1-9]

• 我们每天都在努力着！