一、基于TCP长连接的“服务器推”技术

当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要四次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的.

经典的三次握手示意图：

经典的四次握手关闭图：

所谓长连接，client向server发起连接，server接受client连接，双方建立连接。client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。而且，这种连接是全双工通讯，即客户端可以向服务端发送数据，服务端也可以主动向客户端发送数据，以便服务器更实时地推送客户端需要的信息。

基于TCP长连接方式的优点是iOS提供原生的socket连接支持，缺点是Socekt连接代码比较底层，对程序开发要求较高。另外，服务端还需要额外支持TCP连接的子网穿透和防火墙穿透问题，也增加了开发成本。

raywenderlich网站上有一篇从零开始构建基于Socket的长连接文章Networking Tutorial for iOS: How To Create A Socket Based iPhone App and Server

二、基于HTTP长连接的“服务器推”技术

1. Comet

浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web...

在项目里经常会遇到设计上有很多图片显示成圆角的问题，最常见的解决方案是直接设置layer的两个属性：

view.layer.cornerRadius = 5.0f; view.layer.maskToBounds = YES;

如果在UITableViewCell中使用这种方法绘制圆角，会造成table滚动时的卡顿。卡顿的原因主要是系统的渲染分成了两个部分：屏幕上（onscreen）的渲染和屏幕外（offscreen）CALayer的渲染。offscrren渲染完全是计算出来的，不能用到硬件加速，而每次table滚动时，都需要重新渲染这两个部分，造成GPU计算量大而卡顿。 要解决这种卡顿一般实现方案有三种：

直接使用圆角图片覆盖原图

这种方法适用于背景是纯色的情况，直接把圆角mask图片覆盖原图即可。这种方法比较灵活，还可以适用于各种形状的mask。

在子线程绘制圆角图片，绘制好后到主线程显示

这种方法不使用CoreAnimation的来渲染圆角，因此把最费时的offscreen计算省下来。主要思路是在子线程上绘制图片，使用BezierPath对图片进行裁剪，将最后生成的UIImage传到主线程显示。 裁剪图片的代码如下：

GitHub Pages有两种建站方法

• user websites，如http://wuhui519.github.io。 user websites不需要分支，直接在master上修改提交，然后jeykll会自动解析master分支生成静态网页
• project websites，如http://wuhui519.github.io/testblog/。 project websites原本是为github上各种开源项目设置的静态网页，用于介绍开源项目的各方面情况，但是实际上也可以用于个人博客，project websites必须在github项目的gh-pages分支上提交，只有在这个分支下的文件才会被GitHub Pages解析

了解了这两种建站方式的区别，就可以选择建站的模板了，我的两个pages选择了两种不同的模板

• https://github.com/barryclark/jekyll-now
• https://github.com/minixalpha/StrayBirds

使用模板建站的步骤非常简单，以jekyll-now为例：

• Fork jeykyll-now到本人GitHub帐号
• 点击分支的Settings按钮，修改repository的名字为wuhui519.github.io，此时刷新wuhui519.github.io就可以看到正常运行的网页了
• 修改_config.yml里面各种帐号详情，如名字、介绍、联系方式等
• 所有的文章都放在/_posts/文件夹下，jeykll支持markdown文件的解析，新建的markdown文件以year-month-day-title.md的格式命名。重要的一点是，markdown文件必须包含Additional front-matter variables，格式为：

      
      Read More