tcp的各种连接状态

LISTEN

首先服务端需要打开一个socket进行监听,状态为LISTEN. /* The socket is listening for incoming connections. 侦听来自远方TCP端口的连接请求 */

SYN_SENT

客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT. /*The socket is actively attempting to establish a connection. 在发送连接请求后等待匹配的连接请求 */

SYN_RECV

服务端应发出ACK确认客户端的SYN,同时自己向客户端发送一个SYN.之后状态置为SYN_RECV /* A connection request has been received from the network. 在收到和发送一个连接请求后等待对连接请求的确认 */

ESTABLISHED

代表一个打开的连接,双方可以进行或已经在数据交互了。/* The socket has an established connection. 代表一个打开的连接,数据可以传送给用户 */

FIN_WAIT1

主动关闭(active close)端应用程序调用close,于是其TCP发出FIN请求主动关闭连接,之后进入FIN_WAIT1状态./* The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求,或先前的连接中断请求的确认 */

CLOSE_WAIT

被动关闭(passive close)端TCP接到FIN后,就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE_WAIT. /* The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求 */

FIN_WAIT2

主动关闭端接到ACK后,就进入了FIN-WAIT-2 ./* Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程TCP等待连接中断请求 */

LAST_ACK

被动关闭端一段时间后,接收到文件结束符的应用程序将调用CLOSE关闭连接。这导致它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK . /* The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的连接中断请求的确认 */

TIME_WAIT

在主动关闭端接收到FIN后,TCP就发送ACK包,并进入TIME-WAIT状态。/* The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程TCP接收到连接中断请求的确认 */

CLOSING

比较少见./* Both sockets are shut down but we still don’t have all our data sent. 等待远程TCP对连接中断的确认 */

CLOSED

被动关闭端在接受到ACK包后,就进入了closed的状态。连接结束./* The socket is not being used. 没有任何连接状态 */

怎么样才叫软件团队开发

在我10多年的软件开发中,经历过超过200人的软件开发团队,也有过两三个人开发的小团队,但无论团队的大小,都是采用一个很简单的软件开发方法:就是把项目切分成模块,然后每个人开发一块,最后集合起来,调试完成,再经过测试,交给客户使用,就算项目完成了。

在这期间,团队成员之间没有什么交集,相互的代码也没有查看或者了解一下。因此,当某一个成员离职或者病休时,就会带来很大的问题。因为其它人员都对他的工作不了解,不能接手他的工作,导致再开发下一个项目时,就会带来高涨的成本,项目大大地增加延长开发的时间。

另外,由于成员相互之间没有了解代码,每个人的编写代码的风格也差异比较大,导致代码比较难重用。这种团队开发在目前看来,还在很多公司是存在的。那么怎么样才可以改变这种现状?也就是说怎么样才叫真正的软件团队开发呢?

由于软件开发从个人开发变成团队开发方式,在中国来说,也近来10多年的事情。在90年代都是个人开发就可以成功了,比如像金山软件的求伯君,就可单兵一个,就可以完成DOS下面的WPS开发。

放在今天这样的环境里,软件的规模已经非常大,一个人完成的软件,只有在手机领域还有市场,在其它领域已经不太可能了。

因此,必须建立团队开发为目标。

为了建立团队的开发,就需要制定各种标准。比如编码规范,有了这个标准之后,就可以让所有团队成员编写出同一样规范的代码,可以减少相互交流的成本,同时也提高了代码的质量。同时也可以让成员看不出来谁写的代码,减少心理上抗拒。但是,是否制定了标准之后,就可以万事大吉了呢?其实不然,由于每个开发人员都是人,是人就有着出错,有着自己个性表现,以及个人的习惯。因而有了标准之后,就需要想着怎么样实践了,以及让标准成为行为准则。

在以往的团队,或者说一般的团队里,都是制订标准之后,就发送给大家,就认为完事了。但在我看来,制订标准只是软件团队开发的第一步,要落实标准还需要很多的工作需要做。

那么在软件开发团队里怎么样把这些标准落地,接上地气呢?关键的一环是代码评审。从我经历过的团队,无论大小都没有去实践这个环节,但从国外的软件开发团队来看,没有这个环节的,基本不存在。为什么这个代码评审这么重要呢?

首先代码编写出来之后,需要团队查看之后,才可以认定这种代码是否符合标准,不是让开发人员认为符合了,就是符合了。

其次,代码评审是团队开发的体现。如果每个人开发完成的代码,就认为完成了,其实这份代码,还是个人之作,不是团队共同开发的,所以代码的质量可能是低下的,出错是难避免的,设计的方法是一般的。如果一个团队把个人开发的代码进行评审之后,并作出修改,那么才可以说这份代码是团队开发的软件。

再次,代码评审是经验总结和相互学习提高团队成员的关键。如果这份代码是老员工开发出来的,意味着代码是优秀的,那么新来的成员就可以学习了,从这种例子里学习到最好的代码形式。如果这份代码是新来员工开发的,那么出错,或者不符合规范的情况,就会发生,这时经过团队成员里优秀开发人员的指出,让新员工可以认识到错误,就可以快速地改正,从而快速地向高水平的开发人员看齐。

最后,代码评审是提高软件质量,降低开发成本的方法。因为通过一个团队的众多眼睛和多个大脑来看查看代码之后,代码质量都会显著地提高,同时把自己开发没有发现的错误,都会在其它人的眼睛里一眼就看出来了。这有点像考试时,自己怎么样检查都不会发现有错误,在另外一个人里一查看就看出来了。降低开发成本是关键,由于不断地通过代码评审,意味着这份代码不再属于开发人员一个人了,而属于整个团队了,大家都对代码了解,从而都可以对代码进行开发,避免开发人员离职,或者病假带来的时间和金钱上损失。另外,在今天这种快速迭代开发的环境之下,保持软件稳定发布,只能通过不断评审代码来确认软件不出大BUG了。

总之,一个真正的软件团队的开发需要是这样:团队评审需求、团队制订标准、分别编写代码、团队评审代码。如果缺少最后这个评审代码,这样的开发不叫做团队开发,还是跟个人开发是一样的。

App Store审核指南中文版

苹果在9月3日对App Store审核指南进行了重大更新,新添加了扩展、HealthKit、HomeKit以及TestFlight相关内容。另外,在9月10日新品发布会之后,苹果再次更新了App Store审核指南,添加Apple Pay相关内容。文中红色部分是相对于此前版本的新增内容,蓝色部分表示苹果相关官方文档的链接。

App Store Review Guidelines(英文版

前言

  感谢您付出宝贵的才华与时间来开发iOS应用程程序。从职业与报酬的角度而言,这对于成千上万的开发员来说一直都是一项值得投入的事业,我们希望帮助您加入这个成功的组织。我们发布了《App Store审核指南》(App Store Review Guidelines),希望通过它帮您避开开发应用程序过程中的一些问题,并帮你在提交应用时加快审核流程。
  我们将应用程序(Apps)视为与书籍或歌曲不同的产品,我们并不存储它们。如果您意欲批评宗教,那就去写本书。如果您想要描述性,那就写本书或写首歌,或者可以创建一个医疗程序。这么做可能会比较复杂,但是我们不允许在应用程序商店(App Store)出现某种禁止内容。这会让您认识到我们秉持的更为深远的目的:
  我们有很多可供儿童可以下载的应用程序。家长的监护可以很好地保护孩子,但是您需要做您应该做的那一部分。因此,您要了解我们时刻在留心着您的孩子。
  App Store中有数百万的应用。如果您的应用程序没有什么有益的用途,不是独一无二的或者不能提供持续性的娱乐功能,那它可能不会被我方接受。
  如果您的应用程序看上去像是那种只花了几天功夫简单拼凑出来的产品,或者只是想在我们的商店中抓住朋友的眼球,请提前做好被拒的准备。我们有很多态度严谨的开发者,不希望他们的高品质应用程序充斥在一些业余作品之中。
  我们将拒绝任何包含越界内容或行为的应用程序。您可能会问道,具体限制是什么?最高法院的法官曾有言:“它出现时我自然心中有数。”当您越过这一范围时,我们认为您也会有自知之明。
  如果您的应用程序被拒,我们设立了一个审查委员会供您上诉。如果您去媒体抨击我们,肯定对您于事无补。
  如果您试着作弊(比如在审核流程中作假,窃取用户数据,抄袭其他开发者作品,或者操作应用评分),我们将会移除您的应用程序,并且将您从开发者计划中除名。
  这是一个动态文档,新提交的应用程序会导致新的问题产生,并可能随时产生新的规则。或许您的应用程序会触及到这一点。
  最后要说明的是,我们非常珍惜这个平台,并且向您的作品表示敬意。我们确实在尝试尽力创建全球最佳平台,以便让您展示才华,同时获得相应的报酬。如果这读上去让您感觉我们的控制欲过强,那是因为我们曾向用户承诺保证,我们将利用我们的产品让他们获得高品质体验。
目录  
1.条款与条件 
2.功能 
3.元数据
4.位置 
5.推送通知 
6.游戏中心 
7.广告 
8.商标与商品外观 
9.媒体内容 
10.用户界面 
11.购买与货币 
12.抓取与聚合 
13.设备损害 
14.人身攻击 
15.暴力 
16.令人反感的内容
17.隐私 
18.色情 
19.宗教、文化与种族 
20.竞赛、赌博、彩票和抽奖
21.慈善与援助 
22.法律要件 
23.Passbook
24.儿童类别
25.扩展
26.HomeKit
27.HealthKit
28.TestFlight
29.Apple Pay

1. 条款和条件
1.1 为App Store开发程序,开发者必须遵守 Program License Agreement (PLA)、人机交互指南(HIG)以及开发者和苹果签订的任何协议和合同。以下规则和示例旨在帮助开发者的程序能获得App Store的认可,而不是修改或删除任何其他协议中的条款。
2. 功能
2.1 崩溃的程序将会被拒绝。
2.2 存在错误的程序将会被拒绝。
2.3 跟开发者宣传不符的程序将会被拒绝。
2.4 无应用文档或隐藏功能与描述不符的程序将会被拒绝。
2.5 使用非公开API的程序将会被拒绝。
2.6 在指定容器范围外读写数据的程序将会被拒绝。
2.7 以任何方式或形式下载代码的程序将会被拒绝。
2.8 安装或运行其他可执行代码的程序将会被拒绝。
2.9 beta版、demo版、trial版和test版的程序将会被拒绝。
2.10 iPhone程序必须不经修改就能以iPhone分辨率和2倍 iPhone 3GS的分辨率在iPad上运行。
2.11 与App Store已有程序重复的应用可能会被拒绝,特别是数量很多的情况下,比如手电筒应用和爱经应用。
2.12 有用性不显著、不独特的应用或者与网站简单捆绑的应用有可能被拒;不提供任何持久娱乐价值的程序可能会被拒绝。
2.13 主要用于营销或广告的程序将会被拒绝。
2.14 提供欺骗或虚假功能,却有没有明确标示的应用程序将会被拒绝。
2.15 大于100MB(绿色原先是50MB)无法通过蜂窝网络下载的应用(App Store会自动禁止)。
2.16 多任务程序使用后台服务仅限于几种目的:VoIP,音频播放,地理位置,完成任务以及本地提醒等。
2.17 应用程序只允许使用iOS WebKit框架和WebKit Javascript浏览web内容。
2.18 鼓励酗酒或使用违禁药物,或引诱青少年饮酒或吸烟的程序将会被拒绝。
2.19 提供错误的系统诊断或设备数据的应用将会被拒绝。
2.20 向App Store上传大量相似版本程序的开发者将会从iOS开发者计划中除名。
2.21 简单的歌曲或者影片应用要提交到iTunes store,书籍类应用应该提交到iBookstore。
2.22 武断地根据环境(如定位或者运营商)限制用户使用的应用会被拒。
2.23 应用必须遵守iOS数据储存指导方针(iOS Data Storage Guidelines ),否则应用将被拒。
2.24 存放在Newsstand的应用必须遵守开发者项目许可协议(Developer Program License Agreement)的表1、表2以及表3,否则应用将会被拒。
2.25 类似App Store,基于购买或者促销的目的而展示其他应用的应用将会被拒绝,除非是经过特殊审核批准(比如健康管理、航空以及其他无障碍需求等),或者为特殊群体用户提供具有重大意义的附加值的应用。
2.26 只有当app采集是出于特殊审核需求时,app才可以展示和推荐自身以外的其他应用程序,比如健康管理、航空以及无障碍需求等,否则应用程序将会被拒绝。(新增)
3. 元数据(名称、描述、评级、排名等)
3.1 应用或者元数据中提到其他任何移动平台将会被拒。
3.2 带有占位符文本的程序将会被拒绝
3.3 描述中有与程序内容和功能不相关的信息的应用将会被拒绝。
3.4 为了不混淆用户,iTunes Connect中的应用名称应该和展示在设备上的应用名称一致。
3.5 不同尺寸的app icon要一致,否则会造成混淆。
3.6 程序图标和截图不符合4+年龄评级的程序将会被拒绝。
3.7 目录与类型不适合于程序内容的程序将会被拒绝。
3.8 开发者有责任为其程序指定适合的评级。不相称的评级可能会由苹果公司修改。
3.9 开发者有责任为其程序指定恰当的关键字。不恰当的关键词可能会被苹果公司修改/删除。
3.10 有以下行为的开发者将会被苹果从iOS开发者计划中除名:试图操纵或者欺骗用户评级,伪造或者付费评级,以及其他不相称的行为。
3.11 在安装下载之前推荐用户重启iOS设备的应用将会被拒。
3.12 在提交审核过程中,应用程序应包含能正常运行的URL,比如支持URL和隐私政策URL。
3.13 如果应用程序的截图和营销文本没有清晰地确定需要额外单独购买(比如使用IAP)的内容或者项目,那么应用程序将会被拒绝。(新增)
4. 位置
4.1 在收集、传输或使用位置数据之前未通知并获得用户同意的程序将会被拒绝。
4.2 使用基于位置的API来自动控制车辆、飞机或其他设备的应用程序将会被拒绝。
 4.3 使用基于位置的API用于调度、车队管理或应急服务的程序将会被拒绝。
4.4 当与应用功能或服务密切相关时可以使用位置数据,或者用于经过授权的广告。
 
5. 推送通知
5.1 不使用苹果推送通知 (APN)应用接口提供推送通知的程序将会被拒绝。
 5.2 未从苹果获得Push Application ID便擅自使用APN服务的程序将会被拒绝。
5.3 在首次推送消息或者要求推送通知运行之前未获得用户许可的应用将会被拒绝。
5.4 使用推送通知发送敏感个人信息或机密信息的程序将会被拒绝。
5.5 使用推送通知发送非请求消息或用于钓鱼或群发垃圾邮件用途的程序将会被拒绝。
5.6 应用程序不可使用推送通知发送广告、促销或任何类型的直销信息。
5.7 应用程序不能向使用推送通知服务的用户收取费用。
5.8 使用推送通知会过多利用APN服务的网络流量或带宽或给设备带来过度负担的程序将会被拒绝。
5.9 如果应用程序传送病毒、文件、计算机代码或程序,并且对APN服务的正常运行造成损害或中断,那么该程序将会被拒绝。
6. 游戏中心
6.1 向终端用户或任意第三方显示玩家ID的程序将会被拒绝。
6.2 将玩家ID用于任何未经游戏中心条款批准用途的程序将会被拒绝。
6.3 试图进行反向搜索、跟踪、关联、挖掘、获得或利用玩家ID、别名或通过游戏中心获得其他信息的开发者将会iOS开发者计划除名。
 6.4 游戏中心信息(例如排行榜分数)只能通过游戏中心用于应用中。
 6.5 利用游戏中心服务发送非请求信息或用于钓鱼或群发垃圾邮件的程序将会被拒绝。
 6.6 使用游戏中心过多占用网络流量或带宽的程序将会被拒绝。
6.7 如果程序能够传送病毒、文件、计算机代码或程序,并且对游戏中心服务的正常运行造成损害或中断,该程序将会被拒绝。
7. 广告
7.1 人工刷广告浏览量或者广告点击率的应用程序将会被拒绝。
7.2 包含空iAd广告的应用程序将会被拒绝。
7.3 主要设计目的在于显示广告的应用程序将会被拒绝。
8. 商标与商品外观
8.1 应用程序必须遵守“Guidelines for Using Apple Trademarks and Copyrights”和“Apple Trademark List”中说明的所有条款与条件。
8.2 任何误导和暗示苹果公司是该应用程序来源或提供商,或者苹果公司以任何形式表示认可其质量或功能的应用程序将会被拒绝。
8.3 与目前已有苹果产品或者广告主题外观相似或混淆的应用程序将会被拒绝。
8.4 在应用程序名称中将苹果产品名拼错的应用程序(例如,GPS for Iphone,iTunz)将会被拒绝。
8.5 使用受保护的第三方材料(商标、版权、商业机密、其他私有内容)在申请时需要提供一份文本形式的版权确认。
9. 媒体内容
9.1 不使用媒体播放器框架(MediaPlayer Framework)获取音乐库中媒体内容的应用程序将会被拒绝。
9.2 用户界面模仿任何iPod界面的应用程序将会被拒绝。
9.3 通过蜂窝网络传输的音频流内容每5分钟不得超过5MB。
9.4 通过蜂窝网络传输超过10分钟的视频流内容需要使用HTTP Live Streaming,并包含一个基准线为64kbps的音频HTTP Live Streaming。
10. 用户界面
10.1 应用程序必须遵守苹果的《iOS Human Interface Guidelines》中所有的条款和条件。
10.2 外观与与iPhone的自带应用(比如App Store、iTunes Store和iBookstore)相似的应用将会被拒绝。
10.3 未能按苹果《iOS Human Interface Guidelines》描述正确使用系统提供的项目(比如按钮、图标)的应用将会被拒绝。
10.4 创建多桌面/主屏幕环境或者模拟multi-App插件体验的应用程序将会被拒绝。
10.5 修改音量大小和铃声/静音开关等标准开关功能的应用程序将会被拒绝。
10.6 苹果和我们的客户高度推崇简单、精致、富有创造性以及经过精心设计的界面。虽然需要付出更多,但却非常值得。苹果设立了很高的门槛。如果你的用户界面太过复杂或者水准不高,可能会被拒绝。
11. 购买与货币流通
11.1 使用App Store以外的渠道解锁或开启附加属性和功能的应用程序将会被拒绝。
11.2 使用应用内支付系统(IAP)以外的系统购买内容、功能或服务的应用软件将会被拒绝。
11.3 使用IAP购买实物商品和并非用于该软件的服务的应用软件将会被拒绝。
11.4 应用程序使用IAP购买积分(Credit)或者其他的货币必须在本应用中消费。
11.5 使用IAP购买已过期积分(Credit)或者其他货币的应用软件将会被拒绝。
11.6 使用IAP订阅的内容至少要持续7天,而且允许在用户的其他iOS设备间共享。
11.7 应用程序使用IAP购买项目必须分派到正确的购买类型中。
11.8  使用IAP购买iOS内置功能(如照相机,陀螺仪)的应用程序将会被拒绝。
11.9 含有超过限定时间的内容或服务的应用程序将会被拒绝,除了特殊批准的内容(比如films、电视节目音乐以及书籍)。
11.10 保险类应用程序必须免费,遵守发布地区的法律,并且不能使用IAP。
11.11 一般而言,你的应用程序越贵,我们的评审越彻底。
11.12 提供订阅功能的应用必须使用IAP,苹果将会按照 Developer Program License Agreement 中的约定与开发者按30/70比例分成。
11.13 在应用内使用跳转至外部购买或订阅链接的应用将会被拒,比如“buy”按钮跳转至一个购买电子书的web页面。
11.14 只要应用内没有跳转至外部购买、订阅的按钮或链接,苹果允许这些应用读取或展示经批准的、在应用外购买或订阅内容(特别是杂志、报纸、书籍、音频、音乐、视频以及云存储内容)。苹果只能通过应用程序内的购买获得一部分收益。
11.15 应用程序可以只使用自动更新订阅期刊(报纸、杂志)、商业应用程序(企业类、效率类、专业创意类以及云存储类)和媒体应用程序(视频、音频、声音),否则应用程序将被拒绝。
11.16 当与特定的经过审核的实体产品(比如玩具)结合使用时,应用程序可以使用获得批准的附件功能,只要附加功能完全依赖于该硬件产品(比如一款用于控制望远镜的应用程序)或者也可以在不使用实物产品的情况下使用应用程序,比如作为成功的奖励或者使用IAP。
11.17 如果应用功能遵照各州和联邦法律,那么应用可以用来促进被认可的虚拟货币的流通。(新增)
12. 抓取和聚合
12.1 从苹果网站(例如apple.com、iTunes Store、App Store、iTunes Connect以及Apple Developer Programs等)抓取任何信息或者使用苹果网站内容和服务进行排名的应用程序将会被拒绝。
12.2 应用软件可以使用获得批准的苹果RSS feeds,例如iTunes Store RSS feeds。
12.3 只是简单的网页剪切、内容整合或者收集链接的应用程序可能会被拒绝。
13. 损害设备
13.1 怂恿用户以可能造成损害的方式使用苹果设备的应用软件将会被拒绝。
13.2 快速耗光设备电量或产生过多热量的应用软件将会被拒绝。
13.3 能导致用户人身伤害的app将会被拒绝(新增)
 
14. 人身攻击
14.1 涉及诽谤、人身攻击性质以及内容狭隘卑鄙的应用软件或者打击特定个人或组织的应用软件将会被拒绝。
14.2 职业政治讽刺家和幽默作家不受这一条款约束。
15. 暴力
15.1 应用程序中出现人或动物被杀、致残以及枪击、刺伤、拷打等受伤情形的真实画面将会被拒绝。
15.2 出现描绘暴力或虐待儿童等内容的应用程序将会被拒绝。
15.3 游戏中出现的“敌人”不可指向一个特定种族、文化、一个真实存在的政府、企业或者其他任何现实中的实体。
15.4 对武器进行真实描述以怂恿非法使用或滥用这些武器的应用程序将会被拒绝。
15.5包含俄罗斯轮盘赌博内容的游戏将会被拒。
 
16.令人反感的内容
16.1 应用程序中出现过于令人反感或者低俗的内容将会被拒绝。
16.2 在设计上激怒用户或令人感到厌恶的应用程序将会被拒绝。
17.隐私
17.1 在未经用户事先许可,或未告知用户如何使用信息,在何处使用信息的情况下,应用程序不能传输用户数据。
17.2 要求用户提供电子邮箱地址和出生日期等私人信息才可使用其功能的应用程序将会被拒绝。
17.3 仅出于遵守适用的儿童隐私法规的目的,应用程序可以要求用户的出生日期(或者使用其他age-gating机制),但是必须包括一些有用的功能或者娱乐价值,不管用户年龄大小。
17.4 应用程序收集、传输以及分享未成年用户个人信息(比如名字、地址、邮件、位置、照片、视频、绘画、聊天以及其他个人数据,或者与以上所述相关的永久性标示符)必须遵守应用儿童隐私法规,并且必须包含隐私条款。
17.5 包含账号注册或者访问用户现有账号的应用程序必须包含隐私策略,否则将会被拒绝。
18. 色情
18.1 含有色情素材,也就是《韦氏词典》中定义的“旨在激发情欲,对性器官或性行为的明确描述或展示,而无关美学或情绪感受”的程序将会被拒绝。
18.2 用户频繁提供生成色情内容的应用程序(比如以前的Chat Roulette程序)将会被拒绝。
19.宗教,文化与种族
19.1 涉及宗教、文化或种族群体的引用或评论包含诽谤性、攻击性或狭隘内容,或会使特定群体遭受伤害或暴力的应用程序将会被拒绝。
 19.2 程序可以包含或引用宗教经文,程序所提供的引用或翻译必须准确且不会引起误导。评论应该有教育意义,可以令人开阔眼界,而不应有煽动性。
20. 竞赛、赌博、彩票以及抽奖 
20.1 赌博和竞赛必须由应用程序的开发者或者app所属公司发起。
20.2 应用程序必须展示赌博和竞赛的正式规则,并声明苹果不是发起者,也没有以任何方式参与活动。
 20.3 开发者运营一款具有抽奖性质的应用必须经过法律允许,并且抽奖应用必须具备以下特征:报酬、机会以及奖品。
  20.4 允许用户在应用中直接购买彩票或彩券的应用将会被拒绝
20.5 提供真钱游戏(比如体育博彩、扑克牌、赌场游戏以及赛马)的应用程序必须有应用使用区当地必要的许可和允许,必须限制在这些区域,必须可以从App Store免费下载。
20.6  使用IAP购买信誉或者货币,且结合真钱游戏的应用将会被拒绝。
21.慈善与援助
21.1 包含可以向已认证的慈善组织捐赠功能的应用程序必须是免费的。
21.2 捐赠款项的募集必须通过Safari浏览器访问web页面或是手机短消息完成。
22. 法律要件
22.1 应用程序必须遵守所有发布地区当地法律,开发者有义务了解并遵守所有当地法律。
 22.2 包含虚假,欺诈或误导性陈述的程序将会被拒绝。
22.3 任何招徕、促进或鼓励犯罪或明显鲁莽行为的程序将会被拒绝。
22.4 支持非法文件共享的程序将会被拒绝。
22.5 被设计用以非法赌博工具的应用程序(包括点算牌)将会被拒绝。
22.6 具有匿名或恶作剧拨打电话或发送类似短信/彩信功能的程序将会被拒绝。
22.7 任何开发暗中收集用户密码或用户私人数据程序的开发者将会从iOS开发者计划中除名。
22.8 包含非法律执行部分发布的DUI检查点信息,或者怂恿/协助酒后驾车的应用将会被拒绝。
22.9 任何计算药用剂量的应用必须提交药品制造商或者认可机构(比如医院、保险公司以及高校)。
23. Passbook 
23.1 Passbook Passes可被用来支付或者接收支付,传递商业信息或者提供验证(比如电影票、飞机票、优惠券以及其他),而把Passbook Passes用于其他用途的应用程序可能会遭到拒绝,并且会被撤销Passbook证书。
23.2 Passes必须包含有效的pass发行人有效的联系资料,否则app将会被拒绝,并且Passbook证书也会被取消。
23.3 Passes必须经过实体签名,并基于其名字、商标或者品牌进行分发,否则应用程序将会被拒绝,而Passbook证书也可能会被撤销。
24.儿童类别 
24.1 主要供儿童使用的应用程序必须包含隐私政策,必须适用于应用程序的儿童隐私法。
24.2 主要供儿童使用的应用程序不允许包括行为广告(比如基于用户app内部活动的广告),任何在应用程序中展示的上下文广告必须适合儿童。
24.3 主要供儿童使用的应用程序必须得到家长许可或使用parental gate才能链接至应用程序外部或进行交易。
24.4 儿童类别中的应用程序必须标明“5岁以下,6-8岁或者9-11岁”。
9月3日新增内容
25.扩展
25.1 包含扩展的应用程序必须遵照 App Extension Programming Guide (中文版,英文版)要求。
25.2 包含扩展的应用程序必须提供某些功能(辅助屏幕,附加设置)否则将会被拒绝。
25.3 如果扩展的视图中包含营销推广、广告或者IAP内容,那么包含该扩展的应用将会被拒绝。
25.4 键盘扩展必须提供一个切换至下个键盘的方法。
25.5 键盘扩展必须具有离线访问功能,否则将会被拒绝。
25.6 键盘扩展必须提供和 App Extension Programming Guide 描述一致的数字和十进键盘类型,否则将会被拒绝。
25.7 提供键盘扩展的应用必须拥有基本的功能分类和隐私政策,否则将会被拒绝。
25.8 提供键盘扩展的应用程序只允许收集用户活动以增强键盘扩展在iOS设备上的功能,否则将会被拒绝。
26.HomeKit
26.1使用HomeKit框架的应用程序必须有提供家庭自动化服务的主要目的。
26.2 使用HomeKit框架的应用程序必须在营销文本中说明用途,同时必须提供隐私政策,否则将会被拒绝。
26.3应用程序不允许将从HomeKit  API收集的数据用于广告宣传或者其他基于使用的数据挖掘。
26.4 出于其他目的使用从HomeKit  API收集的数据,而不是用于提高用户体验或者家庭自动化功能中硬件/软件性能,这类应用将会被拒绝。
27.HealthKit
27.1 使用HealthKit框架的应用程序必须遵守其所在区域的适用法律,以及iOS Developer Program License Agreement中的3.3.28和3.39条款。
27.2将虚假或者错误的数据写入HealthKit的应用程序将会被拒绝。
27.3 使用HealthKit框架iCloud中储存用户健康信息的应用程序将会被拒绝。
27.4 应用程序不允许将通过HealthKit API收集的用户数据用作广告宣传或者基于使用的数据挖掘目的,除了改善健康、医疗、健康管理以及医学研究目的。
27.5 未经用户许可与第三方分享通过HealthKit API获得的用户数据的应用程序将会被拒绝。
27.6 使用HealthKit框架的应用程序必须在营销文本中说明集成了Health app,同时必须在app用户界面清楚阐释HealthKit功能。
27.7使用HealthKit框架的应用程序必须提供隐私政策,否则将会被拒绝。
27.8 提供诊断、治疗建议或者控制硬件以诊断或者治疗疾病的应用,若没有根据要求提供书面的监管审批,将会被拒绝。
28.TestFlight
28.1应用程序仅能使用TestFlight对以公开发布为目的的应用进行beta版测试,且必须遵守完整的App Review Guidelines。
28.2 当版本中包含的内容或功能有重大变化时,使用TestFlight的应用程序必须提交审核。
28.3 使用TestFlight的应用程序不允许分发给测试者,以作为任何形式的补偿。
9月10日新增内容
29. Apple Pay
29.1 使用Apple Pay的应用程序必须在出售任何商品或者服务之前为用户提供所有材料的购买信息,否则将会被拒绝。
29.2 使用Apple Pay的应用程序必须正确使用 Apple Pay Human Interface Guidelines 中的Apple Pay标识和用户界面元素,否则将会被拒绝。
29.3 使用Apple Pay的应用程序不能提供触犯任何领域范围法律的用于交付的商品或者服务,也不能用作任何非法目的。
29.4 使用Apple Pay的应用程序必须提供隐私政策,否则将会被拒绝。
29.5 只有为了促进或提高商品和服务的交付,或者依照法律要求,使用Apple Pay的应用程序才能与第三方分享通过Apple Pay获得的数据。
动态文档
这份文档展现了我们在竭尽所能向您分享我们对提交到App Store的程序的审查方式,我们希望您在开发和提交程序时,这份指南能对您有所帮助。这是一份动态文档,随着新程序和新情况的发生会有所变化。我们会定期更新,以反映这些变化。
感谢您参与到iOS的开发中来。虽然此文档是一份“不该做事宜”的列表,但也请将那份短得多的“必做事宜”列表牢记在心。最重要的是,与我们一道 共同努力让用户感到惊奇和欣喜。用创新方式向他们展示世界,让他们用前所未有的方式与之交流。根据我们的经验,无论是在功能和用户界面上,用户确实会对完 善的程序有所反应。更进一步,给他们期望之外的东西,带他们去从未去过的地方。我们愿意提供帮助。

history对象

概述

浏览器窗口有一个history对象,用来保存浏览历史。比如,该窗口先后访问了三个地址,那么history对象就包括三项,length属性等于3。

history.length // 3

history对象提供了一系列方法,允许在浏览历史之间移动。

back():移动到上一个访问页面,等同于浏览器的后退键。
forward():移动到下一个访问页面,等同于浏览器的前进键。
go():接受一个整数作为参数,移动到该整数指定的页面,比如go(1)相当于forward(),go(-1)相当于back()。

history.back();
history.forward();
history.go(-2);

如果移动的位置超出了访问历史的边界,以上三个方法并不报错,而是默默的失败。

以下命令相当于刷新当前页面。

history.go(0);

history.pushState(),history.replaceState()

HTML5为history对象添加了两个新方法,history.pushState() 和 history.replaceState(),用来在浏览历史中添加和修改记录。所有主流浏览器都支持该方法(包括IE10)。

if (!!(window.history && history.pushState)){
// 支持History API
} else {
// 不支持
}

上面代码可以用来检查,当前浏览器是否支持History API。如果不支持的话,可以考虑使用Polyfill库History.js。

history.pushState方法接受三个参数,依次为:

state:一个与指定网址相关的状态对象,popstate事件触发时,该对象会传入回调函数。如果不需要这个对象,此处可以填null。
title:新页面的标题,但是所有浏览器目前都忽略这个值,因此这里可以填null。
url:新的网址,必须与当前页面处在同一个域。浏览器的地址栏将显示这个网址。

假定当前网址是example.com/1.html,我们使用pushState方法在浏览记录(history对象)中添加一个新记录。

var stateObj = { foo: "bar" };
history.pushState(stateObj, "page 2", "2.html");

添加上面这个新记录后,浏览器地址栏立刻显示example.com/2.html,但并不会跳转到2.html,甚至也不会检查2.html是否存在,它只是成为浏览历史中的最新记录。假定这时你访问了google.com,然后点击了倒退按钮,页面的url将显示2.html,但是内容还是原来的1.html。你再点击一次倒退按钮,url将显示1.html,内容不变。

注意,pushState方法不会触发页面刷新。

如果 pushState 的url参数,设置了一个当前网页的#号值(即hash),并不会触发hashchange事件。

history.replaceState方法的参数与pushState方法一模一样,区别是它修改浏览历史中当前页面的值。假定当前网页是example.com/example.html。

history.pushState({page: 1}, "title 1", "?page=1");
history.pushState({page: 2}, "title 2", "?page=2");
history.replaceState({page: 3}, "title 3", "?page=3");
history.back(); // url显示为http://example.com/example.html?page=1
history.back(); // url显示为http://example.com/example.html
history.go(2); // url显示为http://example.com/example.html?page=3

popstate事件

每当同一个文档的浏览历史(即history对象)出现变化时,就会触发popstate事件。需要注意的是,仅仅调用pushState方法或replaceState方法 ,并不会触发该事件,只有用户点击浏览器倒退按钮和前进按钮,或者使用JavaScript调用back、forward、go方法时才会触发。另外,该事件只针对同一个文档,如果浏览历史的切换,导致加载不同的文档,该事件也不会触发。

使用的时候,可以为popstate事件指定回调函数。这个回调函数的参数是一个event事件对象,它的state属性指向pushState和replaceState方法为当前url所提供的状态对象(即这两个方法的第一个参数)。

window.onpopstate = function(event) {
console.log("location: " + document.location);
console.log("state: " + JSON.stringify(event.state));
};
// 或者
window.addEventListener('popstate', function(event) {
console.log("location: " + document.location);
console.log("state: " + JSON.stringify(event.state));
});

上面代码中的event.state,就是通过pushState和replaceState方法,为当前url绑定的state对象。

这个state对象也可以直接通过history对象读取。

var currentState = history.state;

另外,需要注意的是,当页面第一次加载的时候,在onload事件发生后,Chrome和Safari浏览器(Webkit核心)会触发popstate事件,而Firefox和IE浏览器不会。

HTML6 展望

HTML5 概述
HTML5 是 HTML 语言最受欢迎的版本之一,它支持音频和视频、离线存储、移动端、和标签属性等等。还提供了<article>, <section>, <header>这样的标签来帮助开发者更好地组织页面内容。然而 HTML5 规范仍然没有最后定稿,并且它并不是一个真正意义上的语义标记语言。

HTML6 展望
你有没有曾经希望能在 HTML 中使用自定义标签?比如:使用<logo>来显示你的网站logo,还有使用<toolbar>来显示工具栏等等。我们经常使用<div id=”container”>和<div id=”wrapper”>来组织页面,在 HTML6 里我们希望可以直接使用象<container>和<wrapper>这样的自定义标签。

和 XML 一样,HTML6 应该支持 namespace(命名空间),如:xmlns:xhtml=”http://www.w3.org/1999/xhtml”

HTML6 代码样例:

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 <html:meta type="title" value="Page Title">
 <html:meta type="description" value="HTML example with namespaces">
 <html:link src="css/mainfile.css" title="Styles" type="text/css">
 <html:link src="js/mainfile.js" title="Script" type="text/javascript">
 </html:head>
 <html:body>
 <header>
 <logo>
 <html:media type="image" src="images/xyz.png">
 </logo>
 <nav>
 <html:a href="/img1">a1</a>
 <html:a href="/img2">a2</a>
 </nav>
 </header>
 <content>
 <article>
 <h1>Heading of main article</h1>
 <h2>Sub-heading of main article</h2>
 <p>[...]</p>
 <p>[...]</p>
 </article>
 <article>
 <h1>The concept of HTML6</h1>
 <h2>Understanding the basics</h2>
 <p>[...]</p>
 </article>
 </content>
 <footer>
 <copyright>This site is © to Anonymous 2014</copyright>
 </footer>
 </html:body>
 </html:html>

在上面的代码中,你也许注意到了一些奇怪的标签,它们是 W3C 和 HTML6 规范中在命名空间里定义的标签。例如:负责设定你浏览器的标题栏文字,负责显示图片等等。用户可以自己定义标签以便 JavaScript 和 CSS 识别和处理,这样页面代码会更易读,语义更清晰。

HTML6 APIs
HTML6 的标签前带有命名空间,如:<html:html>, <html:head>等等。

1.<html:html>

<!DOCTYPE html>
 <html:html>// this is equivalent to <html> tag written in previous HTML versions
 <!-- sample of HTML document -->
 </html:html>

2. <html:head> 和 <head> 标签一样。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <!-- Main content would come here, like the <html:title> tag -->
 </html:head>
 </html:html>

3. <html:title> 和 <title> 标签类似。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 </html:head>
 </html:html>

4.<html:meta> 和 <meta> 标签类似,不同之处在于,在 HTML5 中你只能使用标准的元数据类型,如:”keywords”, “description”, “author”等,而在 HTML6 中你可以使用任何元数据类型。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 <html:meta type="description" value="HTML example with namespaces">
 </html:head>
 </html:html>

5. <html:link> 和 HTML6 之前版本的 <link> 标签类似。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 <html:link src="js/mainfile.js" title="Script" type="text/javascript">
 </html:head>
 </html:html>

6. <html:body> 和 <body> 标签一样。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 </html:head>
 <html:body>
 <!-- This is where your website content is placed -->
 </html:body>
 </html:html>

7. <html:a> 和 <a> 标签类似,区别是 <html:a> 只有 “href” 一个属性。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 </html:head>
 <html:body>
 <html:a href="http://siteurl">Go to siteurl.com!</html:a>
 </html:body>
 </html:html>

8. <html:button> 和 <button> 及 <input type=”button”> 一样。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 </html:head>
 <html:body>
 <html:button>Click Here</html:button>
 </html:body>
 </html:html>

9. <html:media> 涵盖 <img>, <video>, <embed> 等标签的所有功能。<html:media> 的好处是你不用根据不同的媒体文件类型使用不同的标签,媒体的类型由浏览器从文件内容(类型属性,扩展名,和MIME type)中来判断。

<!DOCTYPE html>
 <html:html>
 <html:head>
 <html:title>A Look Into HTML6</html:title>
 </html:head>
 <html:body>
 <!-- Image would come here -->
 <html:media src="img1/logo.jpg" type="image">
 <!-- Video doesn't need a type -->
 <html:media src="videos/slide.mov">
 </html:body>
 </html:html>

标签类型(Tag types)概述
和 HTML5 一样, HTML6 也有两种标签类型:单标签(single tag) 和双标签(double tag)

<html:meta type="author" content="single tag">
<html:meta type="author" content="double tag" />

单标签不需要结束符’/’

结语
HTML6 规范还未发布,本文原作者 Oscar Godson 只是为我们提供了一个对 HTML6 规范的展望,或者说他希望 HTML6 能够支持的一些新特性。

原文链接:A Look Into HTML6 – What Is It, and What Does it Have to Offer?

 

HTTPS的“S”的代价

卡内基梅隆大学、西班牙电信和都灵理工大学的研究人员在ACM CoNEXT上发表了一篇论文(PDF),量化了网站从HTTP切换到HTTPS所付出的代价

今天越来越多的网站和服务开始启动加密,HTTPS加密Web流量占到总流量的一半,其中YouTube这样的流媒体网站首次有50%的流量是经过HTTPS,这一切证明了Web的完整加密是可行的。但启用HTTPS是有代价的。研究人员分析了启用加密对延迟、消耗数据和客户端电池寿命的影响。他们发现,HTTPS的“S”会使得页面加载时间增加了50%,增加10%到20%的耗电。

此外,HTTPS还会影响缓存增加数据开销和功耗,以及父母控制和病毒扫描等也会受到影响。