RESTful API设计原则与规范
一、背景与基础概念 2
二、RESTful API应遵循的原则 3
1、协议(Protocol) 3
2、域名(ROOT URL) 3
3、版本(Versioning) 3
4、路径(Endpoints) 4
5、HTTP动词(HTTP Verbs) 5
6、过滤信息（Filtering） 6
7、状态码（Status Codes）7
8、错误处理（Error handling）8
9、返回结果（Response）8
10、使用HATEOAS的Hypermedia API 8
11、认证（Authentication）9
三、Swagger API标准9
REST，即Representational State Transfer的缩写。RESTful架构，是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制，所以正得到越来越多网站的采用。如果一个架构符合REST原则，就称它为RESTful架构。
本文即将描述的，即是创建RESTful架构的API所要遵循的原则与规范。
一、背景与基础概念
Web 应用程序最重要的REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。
?资源（resource）：网络上的一个实体或者说是一个具体信息，可以是一段文本、一张图片、一首歌曲、一种服务。
?统一资源定位符（URI，Universal Resource Identifier）：一个资源的识别符或者说是一个地址，通过URI你可以定位到特定的资源。要获取这个资源，需要访问它的URI，因此，URI就成了每一个资源的地址或独一无二的识别符。
?状态转换（State Transfer）: 所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。客户端与服务器互动的过程，通常涉及到服务器端数据和状态的变化过程，比如文件被修改，访问数量增加等。
使用的是标准的HTTP 方法，Http标准中定义的最主要四个动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：-GET：用来获取资源
-POST：用来新建资源
-PUT：用来更新资源
-DELETE：用来删除资源
?Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。
二、RESTful API应遵循的原则
1、协议(Protocol)
API与用户的通信协议，尽量使用HTTPs协议。HTTPs协议的所有信息都是加密传播，第三方无法窃听，具有校验机制，一旦被篡改，通信双方会立刻发现，配备身份证书，防止身份被冒充。
2、域名(ROOT URL)
应该尽量将API部署在专用域名之下。
https://https://www.doczj.com/doc/509538861.html,
如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。
https://https://www.doczj.com/doc/509538861.html,/api/
3、版本(Versioning)
应该将API的版本号放入URL。
https://https://www.doczj.com/doc/509538861.html,/v1/
另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。Github采用这种做法。
注：需要注意版本规划，以便以后API的升级和维护。使得API版本变得强制性，不要发布无版本的API，使用简单数字，避免小数点如2.5。
4、路径(Endpoints)
路径表示API的具体网址URL。在RESTful架构中，每个URL代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与代表的对象名称对应。一般来说，某一同种记录的”集合”（collection），所以API中的名词也应该使用复数。
具体细则：
1、使用名词而不是动词。举例来说，某个URL是/cards/show/1，其中show是动词，这个URL就设计错了，正确的写法应该是/cards/1，然后用GET方法表示show。如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：POST /accounts/1/transfer/500/to/2。正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务：POST /transaction?from=1&to=2&amount=500.00。
2、使用复数名词。不要混淆名词单数和复数，为了保持简单，只对所有资源使用复数。
举例：
/cars 而不是/car
/users 而不是/user
/products 而不是/product
/settings 而不是 /setting
3、使用子资源表达关系。如果一个资源与另外一个资源有关系，使用子资源。
举例：
GET /cars/911/drivers/ 返回car 911的所有司机
GET /cars/911/drivers/8返回car 911的8号司机
5、HTTP动词(HTTP Verbs)
对于资源的具体操作类型，由HTTP动词表示。常用的HTTP动词有下面五个：
?GET（SELECT）：从服务器取出资源（一项或多项）。
?POST（CREATE）：在服务器新建一个资源。
?PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
?PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
?DELETE（DELETE）：从服务器删除资源。
还有两个不常用的HTTP动词。
?HEAD：获取资源的元数据。
?OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。
注：Get方法和查询参数不应该涉及状态改变。使用PUT, POST 和DELETE方法而不是GET 方法来改变状态。
6、过滤信息（Filtering）
如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。为集合提供过滤、排序、选择和分页等功能。
下面是一些常见的参数。
??limit=10：指定返回记录的数量
??offset=10：指定返回记录的开始位置。
??pageNumber=2&perSize=100：指定第几页，以及每页的记录数。
??sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
??animal_type_id=1：指定筛选条件
参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如，GET /zoo/ID/animals 与GET /animals?zoo_id=ID 的含义是相同的
注：
①移动端能够显示其中一些字段，它们其实不需要一个资源的所有字段，给API 消费者一个选择字段的能力，这会降低网络流量，提高API可用性。
②为了将总数发给客户端，使用订制的HTTP头：X-Total-Count.
7、状态码（Status Codes）
服务器向用户返回的状态码和提示信息，常见的有以下一些（方括号中是该状态码对应的HTTP动词）。
?200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
?201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
?202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
?204 NO CONTENT - [DELETE]：用户删除数据成功。
?400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
?401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。
?403 Forbidden - [*]：表示用户得到授权（与401错误相对），但是访问是被禁止的。
?404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
?406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
?410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
?422 Unprocesable entity - [POST/PUT/PATCH]：当创建一个对象时，发生一个验证错误。
?500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。
8、错误处理（Error handling）
如果状态码是4xx，就应该向用户返回出错信息。尽量使用详细的错误包装信息：
{
"errors": [
{
"userMessage": "Sorry, the requested resource does not exist",
"internalMessage": "No car found in the database",
"code": 4xx,
"more info": "https://www.doczj.com/doc/509538861.html,/api/v1/errors/12345"
}
]
}
9、返回结果（Response）
服务器返回的数据格式，应该尽量使用JSON，避免使用XML。针对不同操作，服务器向用户返回的结果应该符合以下规范。
?GET /collection：返回资源对象的列表（数组）
?GET /collection/resource：返回单个资源对象
?POST /collection：返回新生成的资源对象
?PUT /collection/resource：返回完整的资源对象
?PATCH /collection/resource：返回完整的资源对象
?DELETE /collection/resource：返回一个空文档
10、使用HATEOAS的Hypermedia API
RESTful API最好使用Hypermedia as the Engine of Application State（超媒体作为应用状态的引擎），即返回结果中提供链接，连向其他API方
法，超文本链接可以建立更好的文本浏览，使得用户不查文档，也知道下一步应该做什么。
比如，当用户向https://www.doczj.com/doc/509538861.html,的根目录发出请求，会得到这样一个文档。
{"link": {
"rel": "collection https://https://www.doczj.com/doc/509538861.html,/zoos",
"href": "https://https://www.doczj.com/doc/509538861.html,/zoos",
"title": "List of zoos",
"type": "application/vnd.yourformat+json"
}}
上面代码表示，文档中有一个link属性，用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系（collection 关系，并给出该collection的网址），href表示API的路径，title表示API 的标题，type表示返回类型。
11、认证（Authentication）
API的身份认证尽量使用OAuth 2.0框架。
三、Swagger API标准
API的文档管理和信息描述，将使用Swagger进行。
Swagger是一个规范和完整的框架，用于生成、描述、调用和可视化RESTful风格的Web服务。Swagger的目标是对REST API定义一个标准
的和语言无关的接口，可让人和计算机无需访问源码、文档或网络流量监测就可以发现和理解服务的能力。
Swagger规范定义了一组描述一个API所需的文件格式，类似于描述Web服务的WSDL。通过Swagger进行REST API的正确定义，用户可以理解远程服务并使用最少实现逻辑与远程服务进行交互。与为底层编程所实现的接口类似，Swagger消除了调用服务时可能会有的猜测。
注：Microsoft,PayPal等公司也已经引入Swagger 来定义自己的REST API 文档。
Swagger API可以使用YAML或JSON来表示。
Swagger这类API文档工具可以满足下列需求：
?支持API自动生成同步的在线文档
?这些文档可用于项目内部API审核
?方便测试人员了解API
?这些文档可作为客户产品文档的一部分进行发布
?支持API规范生成代码，生成的客户端和服务器端骨架代码可以加速开发和测试速度
通常情况下，API的Swagger描述为JSON文件，也可使用YAML描述的文件。
附Swagger文件示例：
{
"swagger": "2.0",
"info": {
"version": "1.0.0",
"title": "Swagger Petstore (Simple)",
"description": "A sample API that uses a petstore as an example to demonstrate features in the swagger-2.0 specification", "termsOfService": "https://www.doczj.com/doc/509538861.html,/terms/",
"contact": {
"name": "Swagger API team",
"email": "foo@https://www.doczj.com/doc/509538861.html,",
"url": "http://swagger.io"
},
"license": {
"name": "MIT",
"url": "https://www.doczj.com/doc/509538861.html,/licenses/MIT"
}
},
"host": "petstore.swagger.io",
"basePath": "/api",
"schemes": [
"http"
],
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/pets": {
"get": {
"description": "Returns all pets from the system that the user has access to",
"operationId": "findPets",
"produces": [
"application/json",
"application/xml",
"text/xml",
"text/html"
],
"parameters": [
{
"name": "tags",
"in": "query",
"description": "tags to filter by",
"required": false,
"type": "array",
"type": "string"
},
"collectionFormat": "csv"
},
{
"name": "limit",
"in": "query",
"description": "maximum number of results to return",
"required": false,
"type": "integer",
"format": "int32"
}
],
"responses": {
"200": {
"description": "pet response",
"schema": {
"type": "array",
"items": {
"$ref": "#/definitions/pet"
}
}
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
},
"post": {
"description": "Creates a new pet in the store. Duplicates are allowed",
"operationId": "addPet",
"produces": [
"application/json"
],
"parameters": [
{
"name": "pet",
"in": "body",
"description": "Pet to add to the store",
"schema": {
"$ref": "#/definitions/newPet"
}
}
],
"responses": {
"200": {
"description": "pet response",
"schema": {
"$ref": "#/definitions/pet"
}
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
}
},
"/pets/{id}": {
"get": {
"description": "Returns a user based on a single ID, if the user does not have access to the pet",
"operationId": "findPetById",
"produces": [
"application/json",
"application/xml",
"text/xml",
"text/html"
],
"parameters": [
{
"name": "id",
"in": "path",
"description": "ID of pet to fetch",
"required": true,
"type": "integer",
"format": "int64"
}
],
"responses": {
"description": "pet response",
"schema": {
"$ref": "#/definitions/pet"
}
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
},
"delete": {
"description": "deletes a single pet based on the ID supplied",
"operationId": "deletePet",
"parameters": [
{
"name": "id",
"in": "path",
"description": "ID of pet to delete",
"required": true,
"type": "integer",
"format": "int64"
}
],
"responses": {
"204": {
"description": "pet deleted"
},
"default": {
"description": "unexpected error",
"schema": {
"$ref": "#/definitions/errorModel"
}
}
}
}
}
},
"definitions": {
"pet": {
"required": [ "id",
"name"
], "properties": { "id": {
"type": "integer", "format": "int64" }, "name": {
"type": "string"
},
"tag": {
"type": "string"
}
}
},
"newPet": { "type": "object", "required": [ "name"
], "properties": { "id": {
"type": "integer", "format": "int64" }, "name": {
"type": "string"
},
"tag": {
"type": "string"
}
}
}, "errorModel": { "type": "object", "required": [ "code", "message"
], "properties": { "code": {
"format": "int32"
},
"message": {
"type": "string"
}
}
}
}
}
Swagger文件的构成以及规范信息，在Swagger官方的规范指导《Swagger RESTful API文档规范》中有详细描述，请参看。
http://swagger.io/specification/
服务端与手机平台 接口协议 BespRout 2014年11月
文档修改/审批记录
目录 1.概述 (4) 2.涉及接口 (4) 3.接口总体要求 (4) 3.1.系统间接口的原则 (4) 3.2.处理流程 (4) 3.3.接口实现方式 (5) 4.XXX服务端接口 (5) 4.1.XX模块-根据XX下载相关的配置文件 (5) 4.2.XX模块-生成指定XX的文件配置 (6) 4.3.APP启动-初使化参数 (7) 5.附件 (8) 5.1.备注说明 (8)
1. 概述 本文档提供接口给手机端使用，为手机端提供业务平台数据 2. 涉及接口 本文档涉及的外围系统接口包括：无 3. 接口总体要求 3.1.系统间接口的原则 接口设计遵循如下原则： ?安全可靠性原则：系统应提供良好的安全性和可靠性策略，支持多种安全而 可靠的技术手段，制定严格的安全可靠的管理措施； ?开放性原则：提供开放式标准接口，提供与其它系统的互联互通； ?灵活性原则：提供灵活的接口设计，便于接口的变动。 ?可扩展性原则：支持新业务的扩展以及接口容量与接口性能的提高； ?可管理性原则：提供良好的管理机制，保证在运行过程中提供给管理员方便 的管理方式以处理各种情况； ?统一性原则：应当保证系统的接口方式、接口形式、使用的协议等标准、统 一。 3.2.处理流程 接口处理流程
3.3. 接口实现方式 手机APP 应用 与服务端采用基于HTTP 的REST 协议完成，数据传输默认为JSON 4. XXX 服务端接口 测试地址前缀: http://192.168.3.208:8088/xxx/xxx 4.1. XX 模块-根据XX 下载相关的配置文件
健康保健知识库系统 一：概述 健康是21世纪人们非常关注的一个话题之一，随着社会的进步和发展，人们的生活水平也在不断提高，在这个多姿多彩的世界里，物质越来越满足人们的需求，然而，就在这个时候，各种疾病也随着社会的进步而迅速蔓延，疾病发生率也越来越大。虽然说医疗水平越来越先进，但是有些疾病不是医学可以解释和解决的，疾病和我们的日常生活息息相关，为了避免疾病的侵扰，我们应该了解一些健康保健的常识。有了健康我们才会赢，有了健康我们才能随心所欲，有了健康我们才能在这个繁忙的社会里抵抗各种压力。所以，健康保健是我们每个人应该关注的问题，掌握一些健康保健的知识也势在必行！ 二：系统非功能需求 1.硬件需求： 2G+运行内存，50G以上。 2.软件需求： VS2010，SQL2014。 三：功能需求 1.用户注册登陆。 2.用户可以进行健康测评，系统给出相应的结果，评价和建议。 3.用户进入健康保健中心维护知识系统，可以增加、删出、修改、查询信息。 4.用户根据类别查看知识库（小常识，减肥瘦身，运动健身，静心养神）。 5.用户可以在“你问我答”模块中提出问题，回答问题，查询问题。 四：系统功能模块图 健康保健知识库系统 健康测评 健康保健中心你问我答 健康保健小常识减 肥 瘦 身 运 动 健 身 静 心 养 神 提 问 搜 索 评价建议
二、健康保健知识库系统设计 2.1 健康保健知识库系统的功能要求 1.用户注册登陆。 2.用户可以进行健康测评，系统给出相应的结果，评价和建议。 3.用户进入健康保健中心维护知识系统，可以增加、删出、修改、查询信息。 4.用户根据类别查看知识库（小常识，减肥瘦身，运动健身，静心养神）。 5.用户可以在“你问我答”模块中提出问题，回答问题，查询问题。 2.2 健康保健知识库系统管理 功能描述： 用户打开健康保健知识库的主界面,填写相应的用户信息、点击注册、进入主页。选择健康保健知识库系统的相关功能进行操作。若用户选择退出，则返回主界面操作规程描述： 从主界面填写用户的“用户名”、“用户密码、点击“登陆”进入健康保健界面。 如果是新用户，则需先点击“新用户注册”，进入“注册”界面。按照一定的要求进行注册。 处理过程描述 若用户点击“返回”，退出当前操作； 若用户点击其它按钮则调用相关的功能操作。 2.3 健康保健知识库系统登陆界面管理工程 功能描述： 通过打开健康保健知识库系统，可以对界面上的相关信息进行操作。如“填写用户信息”、登陆”、“退出”、“新用户注册”。 操作规程描述： 在界面上的“用户名”一栏填写所要登陆的用户名，在“用户密码”区域输入相 应的信息，点击“登陆”进入聊天界面，如果“密码”错误，则需重新“登陆”。 新用户可以通过“新用户注册”后进行“登陆”。 若退出点击“返回”则退出登陆界面。
一、APP界面设计规范 （一）界面尺寸 1、IOS界面尺寸：常见为（宽度640px、高度1136px） 2、Android界面尺寸：常见为（宽度720px、高度1280px） 其他尺寸：ldpi（240*320）、mdpi（320*480）、hdpi（480*800）3、Web Mobile尺寸：常见为（宽度640px、高度960px） （二）导航尺寸 1、IOS导航尺寸：高度60px，留白7px 2、Android导航尺寸：高度64px或48px，留白8px （三）标签尺寸 1、IOS标签尺寸：高度98px 2、Android标签尺寸：高度96px （四）工具栏尺寸 1、IOS工具栏尺寸：高度88px 2、Android工具栏尺寸：高度96px （五）列表高度 1、IOS列表高度：高度88px 2、Android列表高度：高度96px （六）资源状态 对于资源通常设计弹起、点击、点击后、不可用四种状态，通常弹起、点击、点击后用不同颜色表示、不可用状态用低度灰色表示。 （七）字体
1、IOS默认英文为HelveticalNeue，中文为黑体 2、Android列表高度：默认为 Droidsans fallback （八）字号 字号通常按照标题及征文级别递减为42、36、34、30、24（九）ICON 1、IOS常用尺寸有1024*1024、512*51 2、120*120、60*60 2、Android常用尺寸有512*512、200*200、72*72、48*48（十）资源插图 1、长方形插图高度一般不超过背景宽度的二分之一 2、缩略图两张并列高度一般不超过200px，宽度要适中有留白 3、图文混排中图片一般不高过150*110
接口标准规范 目录 接口标准规范 (1) 第1章概述 (3) 第2章基本要求 (4) 2.1信息通讯安全 (4) 2.1.1 安全评估 (4) 2.1.2 访问控制 (4) 2.1.3 防恶意代码 (4) 2.1.4 加密 (5) 2.2支持高并发 (6) 2.3可监控 (6) 2.3.1 日志全覆盖 (6) 2.4系统资源的动态扩展 (6) 2.5异常处理机制 (7) 2.6业务扩展 (7) 第3章接口通讯方式 (7) 3.1同步请求/应答方式 (7) 3.2异步请求/应答方式 (7) 3.3会话方式 (7) 3.4广播通知方式 (7) 3.5事件订阅方式 (7)
3.7可靠消息传输 (8) 第4章传输控制要求 (8) 4.1负载均衡 (8) 4.2伸缩性与动态配置管理 (8) 4.3网络调度 (9) 4.4充分理由 (9) 4.5单一职责 (9) 4.6高内聚低耦合 (9) 4.7状态及消息 (10) 4.8控制数据量 (10) 4.9禁止随意拓展参数 (10) 第5章接口技术 (10) 第6章接口规范 (11) 6.1域名规范 (11) 6.1.1 http接口 (11) 6.1.2 webservice接口 (11) 6.2 API路径规范 (11) 6.2.1 http接口 (11) 6.2.2 webservice接口 (11) 6.3版本控制规范 (12) 6.3.1 http接口 (12) 6.3.2 webservice接口 (12) 6.4 API命名规范 (12) 6.4.1 新增方法 (13) 6.4.2 删除方法 (13) 6.4.3 修改方法 (13) 6.4.4 获取方法 (13) 6.4.5 获取列表方法 (13)
东方钢铁公司 知识管理系统设计说明书 东方钢铁集团股份有限公司 2010年10月
目录 目录 (2) 1．引言 0 1.1 编写目的 0 1.2 背景 0 1.3 参考资料 (1) 2. 概要设计说明书 (1) 2.1 知识管理系统功能模块图 (1) 2.2 知识管理系统数据库概念设计 (3) 3. 详细设计说明书 (5) 3.1 输入输出设计 (5) 3.2 处理模块详细设计 (6)
1．引言 1.1 编写目的 本文档是东方钢铁公司知识管理系统详细设计文档。用于指导知识管理系统编码与单元测试，主要为程序设计师和测试工程师进行代码设计和测试提供依据。 系统详细设计说明，包括： 系统功能说明、系统结构说明、ER图、操作界面设计、数据库设计、详细的数据表（包括主键、外键、数据类型、默认值、取值范围等） 1.2 背景 东方钢铁集团具有公司的局域网，直接与internet系统相联。同时规划与AA集团、AA股份及AA国际总公司的主干网接口。东方钢铁集团信息节点覆盖公司所有业务点，即人人网上互联。此外，公司还提供了远程拨号服务，供移动办公使用。 不论是网络基础设施条件、用户群体，还是在办公电子化和网络化方面都有较好的基础。多数职工对计算机特别是对信息技术的应用有较高的水平，具备了实施知识管理及协同工作项目的必要条件另一方面，现有的系统中仅实现简单的信息发布和信息
沟通功能，且信息分布零散无序。 因而对东方钢铁集团原有OA系统进行整合和升级是有必要的，应建设与其组织结构、业务方向相适应的知识管理系统，搭建统一的工作界面，建立完善的工作流程、提高内部信息共享程度、提升公司知识积累和应用的水平，最终实现利用信息化提升企业竞争力的目标。 1.3 参考资料 信息系统分析与设计（第3版）北京清华大学出版社，2006 东方钢铁集团面向新世纪发展规划和需求分析报告 东方钢铁集团组织OA系统用户使用说明书 2. 概要设计说明书 2.1 知识管理系统功能模块图 根据需求，系统用户主要有管理员和普通用户，管理员操作有分类管理，人员管理，组织结构管理，知识审核，普通用户操作有个人知识管理，评论管理，参与培训及考试。具体的功能模块图如下：
相信很多人都在开发设计APP时会遇到很多界面上的问题，要以多大尺寸来设计？分辨率是多少？该怎么切图给开发等等 下面的文字就给出一点点技巧总结，但也要给合团队在开发时的习惯。每个工程师们所使用的控件，书写布局习惯来实际移交的图是不一样的，但八九不离十，都是遵循一个原则，便捷开发、自适应强的开发模式 IOS篇 一、尺寸及分辨率 iPhone界面尺寸：320*480、640*960、640*1136 iPhone6：4.7英寸(1334×750)，iPhone6 Plus：5.5英寸(1920×1080) 设计图单位：像素72dpi。在设计的时候并不是每个尺寸都要做一套，尺寸按自己的手机来设计，比较方便预览效果，一般用640*960或者640*1136的尺寸来设计，现在iphone6和plus出来后有很多人会使用6的设计效果。 如果是我来做的话，我会使用640×1136，对plus做单独的修改适配，因为plus的屏幕实在是大了，遵循屏大显示更多内容的原则这里本应该是需要修的了。有更好办法的话希望大家可以分享一下。 Ps：作图的时候确保都是用形状工具(快捷键：U)画的，这样更方便后期的切图或者尺寸变更。 二、界面基本组成元素
iPhone的app界面一般由四个元素组成，分别是：状态栏(status bar)、导航栏(navigation)、主菜单栏(submenu)、内容区域(content)。 这里取用640*960的尺寸设计，那我们就说说在这个尺寸下这些元素的尺寸。 状态栏(status bar)：就是我们经常说的信号、运营商、电量等显示手机状态的区域，其高度为：40px 导航栏(navigation)：显示当前界面的名称，包含相应的功能或者页面间的跳转按钮，其高度为：88px 主菜单栏(submenu，tab)：类似于页面的主菜单，提供整个应用的分类内容的快速跳转，其高度为：98px 内容区域(content)：展示应用提供的相应内容，整个应用中布局变更最为频繁，其高度为：734px 至于我们经常说的iPhone5/5s的640*1136的尺寸，其实就是中间的内容区域高度增加到910px。
目录 1 接口类型 (2) 1.1 人机接口 (2) 1.2 软件-硬件接口 (2) 1.3 软件接口 (2) 1.4 通信接口 (2) 2 接口设计规范 (2) 2.1 基本内容 (2) 2.2 规格说明 (3) 2.2.1 人机接口 (3) 2.2.2 软件-硬件接口 (3) 2.2.3 软件接口 (3) 2.2.4 通信接口 (3) 3 接口设计文档提纲 (3)
1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。 2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系
4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求 9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。 2.2.4通信接口 逐个描述各个通信接口的设计特性。包括硬件描述、接口功能说明、通信协议、报文处理、存储资源分配、程序接口设计和程序编制要求等。 3接口设计文档提纲 1 概述 (2) 1.1 编写目的 (2) 1.2 参考资料 (2)
硕士研究生学位论文 题目：基于知识库的礼品推荐系统的设计与 实现 学号：085707 姓名：路卫杰 专业：计算机科学与技术 导师：孟祥武
学院：计算机学院年月日
独创性（或创新性）声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切相关责任。 本人签名：日期： 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段保存、汇编学位论文。（保密的学位论文在解密后遵守此规定） 非保密论文注释：本学位论文不属于保密范围，适用本授权书。 本人签名：日期：
导师签名：日期：
基于知识库推理的礼品推荐系统的设计与实现 摘要 当今，个性化推荐系统已经在很多领域得到了应用，如网络商品推荐、音乐推荐、影视推荐等。推荐技术包括协同过滤、内容过滤、知识发现等，但是这些推荐技术并没有考虑推荐领域的知识对推荐结果的影响，或者推荐结果没有通过与用户的交互过程中得到完善和改进。 鉴于以上问题，本文针对礼品推荐领域提出了基于知识库的推荐方法。首先在调研了礼品信息和礼品赠送知识后构建礼品知识库，然后礼品专家通过人工方式对礼品知识库进行初始化，最后系统根据礼品的基本信息计算出礼品综合相似度对礼品知识库进一步完善。本文采用AJAX等技术设计并实现具有良好用户体验的知识库推荐用户接口，采用全文检索引擎工具包Lucene对礼品信息构建索引并根据用户的日志设计个性化的礼品搜索功能。 本文第一章介绍了推荐系统的研究背景和国内外的研究现
登记结算数据接口规范（上市公司版V2.9） 二零一五年一月
版本修订历史
目录 前言 (4) 一、概述 (4) 二、数据文件命名规则 (4) 三、基本数据说明 (4) 第一章发送数据接口规范 (7) 一、中国结算上海分公司向上市公司发送的数据清单 (7) 二、中国结算上海分公司向上市公司发送的数据明细说明 (8) 1)s1(上市公司月中/末大股东名册数据) (8) 2)s1c(上市公司月末大股东名册自助补发数据) (9) 3)s2d（上市公司前N名股东名册自助发送数据） (9) 4)s2e（上市公司权益日全体股东名册自动发送） (10) 5)s3(上市公司红利退款明细数据) (11) 6)s4(人工受理的A股全体股东名册) (12) 7)s5(融资融券和转融通担保证券账户的明细数据) (13) 8)s6(股息红利差异化计税补缴明细数据) (14) 9)s7(全体股票激励期权持有人数据) (16) 10)s8(股票激励期权持有变动明细数据) (16) 11)s9(股票激励期权基本信息数据) (17) 12)s10(A股合并普通账户和信用账户前N名名册) (18)
前言 一、概述 为了进一步规范中国证券登记结算有限责任公司上海分公司（以下简称中国结算上海分公司）与上市公司之间的登记结算数据接口，确保登记结算数据处理的正确性，特编写本登记结算数据接口规范文档。本文主要针对中国结算上海分公司发送和接收的上市公司的各类登记结算数据进行详细的说明。 二、数据文件命名规则 数据文件名: =：前缀 + 标识 + “.” + 后缀 前缀：=：s1|s1c|s2d|s2e|s3|s4|s5|…… 标识：=: 证券代码[yyyymmdd][其它]，其中[yyyymmdd]和[其它]为可选内容，参见各文件的数据库名说明。 后缀：=：mdd m：=：1，2，3，……，9，a，b，c dd：=：01，02，03，……，31 目前中国结算上海分公司发送和接收的数据文件，均采用FOXPRO2.5下的标准DBF格式。为了减少数据通讯量，中国结算上海分公司发送的数据文件都经过ZIP软件压缩后发送至PROP电子信箱中。 发送数据文件的命名规则为：“前缀” + “标识” + “.mdd”；其中mdd表示日期，其中m表示月，（m=1,2,3,…,9,a,b,c），dd表示日。例如2001年12月31日发送的600001上市公司的s1数据的数据名称为“s1600001.c31”。 三、基本数据说明 1、股票的数量单位为“股”、基金的数量单位为“份”；债券、融券数量单位为“一元”面 值数量；金额单位为“元”。 2、证券类别（ZQLB）意义如下： GZ 固定收益类 JJ 基金 PT 无限售流通股 PG 配股 PS 配售股
1.bean对象中添加注解 1.1 class上添加注解@ApiModel 1.2 属性上添加注解@ApiModelProperty(value = "姓名", example = "name")，属性是属于 对象关联属性则不需要添加example。 事例： 2.controller中添加注解 2.1 class上添加注解@Api(description = " swagger事例")。Description可以描述这个 controller是用来做什么的，@ApiIgnore：在class上是过滤掉这个controller不让这个类下面的接口在前端显示，在方法上让这个接口不在前端显示 @RequestMapping(value = "/testObject",method = RequestMethod.POST) Method统一为RequestMethod.POST 2.2 方法上添加注解 2.2.1 @ApiOperation(value = "test",notes = "test",produces = "application/json") 说明： value：方法名 notes:方法描述 produces：相应格式（统一为application/json） 2.2.2 @ApiImplicitParams({ @ApiImplicitParam(name = "subcategoryId", value = "年级iD", required = true, paramType = "query", dataType = "string") }) 说明：参数传入每一个@ApiImplicitParam表示一个参数 name:参数名，通过request.getParameter("name").的名字 value:说明 required：是否必填，true:必填，false：不必填 paramType：参数获取类型（统一使用query） dataType：数据类型
刚入门UI的小伙伴是不是不知道app该怎么切图、规范是什么？怎么和程序员同学配合，用什么工具更方便，怎么标注自己的设计稿，怎么做到一稿适配多种机型，这篇文章将一一解答你的疑问! 依旧声明：这里写的不是一种规范，只是一种工作方法，大家在具体工作中，一定要灵活运用。另外，技术的更新是非常快的，所以，还是要灵活运用~ 我本身是一名GUI设计师，所以我只站在GUI设计师的角度去把APP从项目启动到切片输出的过程写一写，相当于工作流程的介绍吧；公司不同，流程不尽相同，但是终究还是能有些帮助。 这里我们只说IOS系统下的设计，至于Android，因为尺寸太多，涉及的东西比较乱，我整理好以后再说吧。 页面篇幅比较长，不推荐一次性看完，那样你潜意识里就会对它厌烦了，所以可以有时间读一读，看一看。 Part 1 项目立项 完善的公司会把项目相关人员聚集起来，产品经理会把产品详细的用原型展示出来，包括产品定位，市场需求，主打卖点，产品性质以及各模块具体功能，逻辑跳转演示一下；之后会评估项目用时，各部门协调，项目启动。 话不多说，接到原型，那我们应该做什么准备工作呢？
在项目设计之初，就该进行项目归档整理，我的习惯是“项目名称+版本序列”； 没有最正确的工作方法，只有最适合自己的工作习惯。 我个人习惯把不同类型的文件划分到不同类型的文件夹里，有的设计师习惯全都放在一个文件夹里，如果文件少还说的过去，如果页面过多，就知道这样的利弊了。 工欲善其事必先利其器，基本上我做界面设计用的最多的就是PS和AI了，版本无所谓，用着舒服就行，推荐版本高一点的，低版本好多方便功能都没有。 标注工具： PxCook，目前我还没用上Mac，所以也不知道传说中的Sketch到底多神奇。PxCook在Windows上标注还比较顺手，虽然它还附带切图功能，但是比较鸡肋，不推荐用它切图。 切图工具： Cutterman 点击下载一款PS的插件，切图非常方便，但不支持绿色免安装版本PS，而且对PS版本要求比较高，针对CS 6的已经不维护更新了。推荐安装官方完整版PS cc，然后自行破解。官网上有安装使用教程，自己研究下吧，因为我也是最近才开始接触这款插件。 Assistor PS 也是一款PS的切图标注插件，也被誉为神器；我使用了下，感觉相当不错，就是标注还没太适应，推荐一下这个。 标注工具以及这两款插件我都会上传，至于安装方法去“百度一下”吧，易学易用。
XXX接口说明书 (版本： 文档编号保密等级 作者最后修改日期 审核人最后审批日期 批准人最后批准日期
修订记录 日期版本修订说明修订人
1简介 1.1文档目的 接口文档是前端与后端交互密不可分的环节，接口的规范性会直接影响双方对接过程中的效率和质量。本着快速高效开发的目的性，避免对接过程中的错误率。 1.2接口规范 (1) 遵循RESTful API设计风格 (2) 数据格式采用json格式 (3) 返回统一结构数据 例如： 结构：data（数据）、errorCode（状态码）、msg（提示信息） { data:{}, .] 订单列表 orderList orderId string 否订单id orderName string 否订单名称
isStudent boolean 是false false 是否学生（是：true，否： false） 返回参数： 参数名类型示例值默认值描述 data array […]返回的数据 data id string 用户id gender number 1 1 用户性别（男：1，女：2）invoiceTitle string 抬头 address string 地址 billList array [...] 订单列表数据 billList id string 订单id billName string 订单名称 billStauts number 1 1 订单状态（待开票：1，回款： 2，核销：3） address string 客户地址 userInfo object {} 用户信息 userInfo name name 用户姓名 age number 用户年龄 gender string 1 1 用户性别（男：1，女：2）errorCode number 状态信息 msg string 信息提示 返回示例值: { data:[ { id:'1', gender:2, invoiceTitle:'帝国快运', address:'陕西省西安市雁塔区科技路24号', billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' }, { id:'002', billName:'测试数据02',
SOKLIB知识库管理系统 需求规格说明书 编写人员：俞育峰、周长青、刘宸哲 编写时间：2016年04月18日
目录 1.概述 (3) 1.1.编写目的 (3) 1.2.术语和标记 (3) 2.项目概述 (3) 2.1.项目总体目标 (3) 2.2.系统开发背景 (4) 2.3.主要限制和开发风险分析 (5) 3.功能需求 (5) 3.1.功能模型 (7) 3.1.1.知识导入模块 (7) 3.1.2.知识归纳模块 (10) 3.1.3.知识收藏模块 (12) 3.1.4.个人知识管理模块 (15) 3.1.5.个人信息管理模块 (16) 3.1.6.公共知识网络结构模块 (18) 3.1.7.公共知识检索模块 (19) 3.1.8.文档推荐模块 (21) 3.1.9.消息管理模块 (22) 3.1.10.后台信息统计模块 (23) 3.1.11.后台用户管理模块 (25) 3.1.12.后台知识文件管理模块 (27) 3.1.13.后台分类管理模块 (29) 3.1.14.后台系统日志模块 (31) 3.2.性能需求 (32) 3.3.非功能需求 (32) 3.4.故障处理 (32) 4.数据需求 (32)
4.1.数据项 (32) 4.2.实体关系 (35) 5.行为需求 (35) 5.1.控制模型 (35) 6.接口需求 (36) 6.1.用户界面 (36) 7.环境 (39) 7.1.运行环境 (39) 7.2.开发环境 (39)
1.概述 1.1.编写目的 本文档的编写目的是为SOKLIB知识库管理系统项目的开发提供： a) 软件总体要求，作为用户和软件开发人员之间了解的基础； b) 功能、性能、接口和可靠性的要求，作为软件人员进行设计和编码的基础； c) 验收标准，作为用户确认测试的依据 1.2.术语和标记 Spring MVC：SpringFrameWork的后续产品Spring 框架提供了构建Web 应用程序的全功能MVC 模块； MyBatis：一个基于Java的持久层框架； Apache：专门为运作一个开源软件项目的Apache 的团体提供支持的非盈利性组织； Lucene: 一个开放源代码的全文检索引擎工具包； Git：一款免费、开源的分布式版本控制系统； OpenOffice：是一套跨平台的办公室软件套件，能在Windows、Linux、MacOS X (X11)和Solaris 等操作系统上执行。 2.项目概述 2.1.项目总体目标 a)组织、公司内部人员知识资源共享 b)方便有效管理个人知识资源
UI必知之MD和IOS设计规范的区别
在UI设计师日常工作中，很重要的一个工作前提就是要熟知设计规范，那么对于移动端的设计规范，你们知道吗？那么，接下来就让小编给大家着重地分析一下MD和IOS设计规范在阴影、导航和配色这三个方面有什么区别吧，希望对大家能够有所帮助！ Material Design（以下简称MD）是谷歌研发的一套视觉语言设计规范，主要应用于安卓类应用。
iOS Human Interface Guidelines（以下简称iOS）是苹果公司针对iOS 设计的一套人机交互指南，目的是为了使运行在iOS上的应用都能遵从一套特定的视觉以及交互特性，从而能够在风格上进行统一。 相对来说，我们对于iOS的设计规范更加熟悉。因为考虑到成本，设计师进行产品设计的时候只会出一套iOS的设计稿，然后去适配安卓机型。很少会针对安卓机型再出一套MD风格的方案，这种现象虽然存在但是并不合理。不同的系统/平台采用了不同的设计语言，不同的设计语言会培养出不同的操作习惯。 例如使用安卓手机的用户平时见到的都是MD风格的界面，突然下了一个iOS风格的应用，那么操作起来就会很不习惯，增加了学习成本。为了让产品可以适用不同平台用户的操作习惯，提供MD和iOS两套设计稿是非常有必要的。 区别一：阴影 MD意味着大色块+阴影，为什么MD如此痴迷于阴影？从它的名字就可以看出来，Material Design，这里的material指的是纸张。因为来源于现实生活，所以MD非常喜欢使用真实世界元素的物理规律与空间关系来表现组件之间的层级关系。 而阴影就是最常见的表现形式：
接口设计规范 Prepared on 24 November 2020
目录 1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。
2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系 4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求 9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。
XX公司行业知识库平台 解决方案 重点行业信息化知识库及服务体系构造
1概要 行业发起建设行业知识库平台可对整个行业起到的促进作用如下： ?推动大企业向高端咨询转型。 ?引导中小企业向专业化服务转型。 ?加强行业用户与软件企业的战略合作。 ?拓展行业应用市场, 抵制国外对手占据高端应用，扩大市场份额。 ?优化行业结构，提升软件行业发展速度。 行业信息化知识库，是指软件企业在服务于行业信息化建设过程中所积累的行业关键知识、实施经验、软件构件重用等的总称。行业知识库的内容包括以下内容： 图表 1 行业知识库参考模型
行业知识库系统是一个复杂而庞大的系统，随着时代的进步而不断发展和创新，不同时期存在不同的情况、业务模式和不同的操作方法，在应用过程中又不断发现问题，不断加以改进和完善。所有这些过程、模式和业逻辑，都需要行业知识作为基础架构进行支撑，通过面向知识的架构（SOA）提升行业信息化整体应用水平。 2项目特点 行业知识库包括两大部分，即行业知识库体系以及行业知识库本身。前者是知识库理论基础，其文档系统可以概括为： 1.知识体系。行业的知识与分类、行业标准法规文件、行业业务模型、行业数据模型、 行业信息系统的构件、行业案例、行业分析报告和信息资源定义等 2.技术体系。行业总体解决方案、行业技术框架、系统需求分析、硬件网络环境、系统 概要设计、系统详细设计、系统测试报告、行业系统软件源码、构件软件和构件实体等 3.服务体系。产业链全程服务体系、服务组织机构、服务规则规章、服务方式方法、服 务技术支撑框架、售前售中售后条例等。 知识库本身是知识库解决方案的实现，包括知识库开发平台和知识库应用平台。XX公司知识库开发平台采用SOA架构，以服务方式提供知识构件。在知识应用平台上构件作为服务与知识库解决方案、业务模型、数据模型等知识一样进行注册等维护管理。 行业知识库建设将改变传统的生产经营模式，通过实施行业整个供应链的一体化管理，实现以市场为导向优化资源配置、提高效率、降低成本、提升效益的目标；把信息化融入到行业、企业的实际工作中，全面落实依法行政、依法管理、依法经营，运用信息化开展技术创新、管理创新和制度创新，建立全面准确量化的管理体系，实现管理从定性向定量、由静态向动态、由事后向实时的转变，提升行业生产经营管理水平，提高应对国际竞争环境的能力。 XX公司在行业知识库开发上从知识体系建设和技术体系建设出发，采用两个建设并进的策略进行。在知识体系建设上，首先对目标行业进行全业务梳理，摸清目标行业的家底，调查、收集和整理行业相关的法律法规、标准文件，按照元数据的标准进行编目和归类，生成可以管理和操作的知识元素库。同时在技术体系上，构建以SOA架构为基础的知识库技术平
iPhone、ipad常见设计尺寸 iPhone： iPhone 1G 320x480 iPhone 3G 320x480 iPhone 3GS 320x480 iPhone 4 640x960 iPhone 4S 640x960 iPhone 5 640x1136 iPhone 5S 640x1136 iPhone 5C 640x1136 iPhone 6 750x1334 iPhone 6 Plus 1080x1920 （开发应按照1242x2208适配） iPhone 6S 750x1334 iPhone 6S Plus 1080x1920 （开发应按照1242x2208适配） iPhone SE 640x1136 iPhone6-iPhone8这段时间苹果新手机的物理像素都是750x1334px。所有Plus手机的物理像素都是1242x2208px iPhone 7 750x1334 iPhone 7 Plus 1080x1920 （开发应按照1242x2208适配） iPhone XS Max：1242 x 2688 px iPhone XS：1125 x 2436 px iPhone XR：828 x 1792 px
但是如果我们用点的单位看就会得到： iPhone XS Max：414 x 896 pt （iPhone Plus分辨率宽度）iPhone XS：375x812 pt （iPhone 6/7/8分辨率宽度）iPhone XR：414 x 896 pt （iPhone Plus分辨率宽度）iPod Touch: iPod Touch 1G320x480 iPod Touch 2G320x480 iPod Touch 3G320x480 iPod Touch 4G640x960 iPod Touch 5G640x1136 iPad: iPad 11024x768 iPad 21024x768 The New iPad2048x1536 iPad mini1024x768 iPad 42048x1536 iPad Air2048x1536 iPad mini 22048x1536 iPad Air 2 2048x1536 iPad mini 3 2048x1536 iPad mini 4 2048x1536
ios视觉设计规范 篇一：ios用户界面《UI》设计设计规范 相信很多人都在开发设计APP时会遇到很多界面上的问题，要以多大尺寸来设计？分辨率是多少？该怎么切图给开发...... 下面的文字就给出一点点技巧总结，但也要给合团队在开发时的习惯。每个工程师们所使用的控件，书写布局习惯来实际移交的图是不一样的，但八九不离十，都是遵循一个原则，便捷开发、自适应强的开发模式。 一、尺寸及分辨率设计图单位：像素72dpi。在设计的时候并不是每个尺寸都要做一套，尺寸按自己的手机来设计，比较方便预览效果，一般用640*960或者640*1136的尺寸来设计，现在iPhone 6和Plus出来后有很多人会使用6屏幕尺寸来设计。 相比之下，使用640×1136，对Plus做单独的修改适配，效果会更好，因为Plus的屏幕实在是大了，遵循屏大显示更多内容的原则这里本应该是需要修的了，有更好办法的话希望大家可以分享一下。 Ps：作图的时候尽可能确保都是用形状工具(快捷键 U)画的，这样更方便后期的切图或者尺寸变更。
二、界面基本组成元素 iPhone的app界面一般由四个元素组成，分别是：状态栏(status bar)、导航栏(navigation)、主菜单栏(submenu)、内容区域(content)。PS：在最新的iOS7的风格中，苹果已经开始慢慢弱化状态栏的存在，将状态栏和导航栏合在了一起，但是再怎么变，尺寸高度也还是没有变的，只不过大家在设计iOS7风格的界面的时候多多注意下~ 三、图标尺寸四、字体大小 iPhone 上的字体英文为： HelveticaNeue ，而中文，Mac下用的是黑体-简，Windows下则为华文黑体，所有字体要用双数字号。 下图是百度移动用户体验部（MUX）做过的一个小调查，可以看出用户在iOS app中可接受的文字大小。五、切图山东华软科技股份有限公司是一家专业从事棋牌游戏定制开发的专业性公司。现有完善PC端，手机端棋牌游戏平台。详情咨询QQ1557924069 切图是APP设计中的一个重要过程，关系到APP的界面实现，及各种适配性还有各种性能苹果在没6 Plus前，我们只需要提供两种图，普通图及视网膜屏幕图。 以640×1136（640×960是一样的）做的设计图的话
竭诚为您提供优质文档/双击可除 iosapp设计规范 篇一：ios界面设计尺寸规范 ios界面设计尺寸规范 一、尺寸及分辨率 iphone界面尺寸：320*480、640*960、640*1136、750*1334、1080*1920等。 ipad界面尺寸：1024*768、2048*1536等。 单位：像素72dpi，在设计的时候并不是每个尺寸都要做一套，尺寸按自己的手机来设计，比较方便预览效果，一般用640*960或者640*1136的尺寸来设计。ps ：作图的时候确保都是用形状工具（快捷键：u）画的，这样更方便后期的切图或者尺寸变更。 二、界面基本组成元素 iphone的app界面一般由四个元素组成，分别是：状态栏、导航栏、主菜单栏、内容区域。 640*960的尺寸设计下这些元素的尺寸。 状态栏：就是我们经常说的信号、运营商、电量等显示手机状态的区域，其高度为：40px
导航栏：显示当前界面的名称，包含相应的功能或者页面间的跳转按钮，其高度为：88px 主菜单栏：类似于页面的主菜单，提供整个应用的分类内容的快速跳转，其高度为：98px 内容区域：展示应用提供的相应内容，整个应用中布局变更最为频繁，其高度为：734px [下图说明：] 至于我们经常说的iphone5/5s的640*1136的尺寸，其实就是中间的内容区域高度增加到910px。 ps：在最新的ios7的风格中，苹果已经开始慢慢弱化状态栏的存在，将状态栏和导航栏合在了一起，但是再怎么变，尺寸高度也还是没有变的，只不过大家在设计ios7风格的界面的时候多多注意下~ 三、字体大小 heitisc（黑体-简，黑体-简的英文名称为heiti sc。heiti为黑体的拼音，sc代表简体中文（simplifiedchinese）），是macosxsnowleopard（版本10.6）包含的简体中文字型，也是iphoneos 3.0（版本 4.0后改名为ios）及ipodnano第五代以来的预设简体中文字型。 黑体-简系为黑体，取代华文黑体成为macosxsnow leopard的预设简体中文字型。在过去，华文黑体是
《中医重点专科住院病案首页监测直报系统》 接口规范文档（适用于新版4-1） 序号字段名字段含义部分字段说明 1 USERNAME 机构名称 2 YLFKFS 医疗付款方式《医疗付款方式字典》 3 JKKH 健康卡号 4 ZYCS 住院次数 5 BAH 病案号 6 XM 姓名 7 XB 性别《性别字典》 8 CSRQ 出生日期 9 NL 年龄 10 GJ 国籍《国籍字典》 11 BZYZSNL (年龄不足1周岁的)年龄(月) 12 XSECSTZ 新生儿出生体重(克) 13 XSERYTZ 新生儿入院体重(克） 14 CSD 出生地 15 GG 籍贯 16 MZ 民族《民族字典》 17 SFZH 身份证号 18 ZY 职业《职业字典》 19 HY 婚姻《婚姻字典》 20 XZZ 现住址 21 DH 电话 22 YB1 邮编 23 HKDZ 户口地址 24 YB2 邮编 25 GZDWJDZ 工作单位及地址 26 DWDH 单位电话 27 YB3 邮编 28 LXRXM 联系人姓名 29 GX 关系《联系人关系字典》 30 DZ 地址 31 DH2 电话 32 RYTJ 入院途径《入院途径字典》 33 RYSJ 入院时间
34 RYSJS 时 35 RYKB 入院科别《科室字典》 36 RYBF 入院病房 37 ZKKB 转科科别《科室字典》 38 CYSJ 出院时间 39 CYSJS 时 40 CYKB 出院科别《科室字典》 41 CYBF 出院病房 42 SJZYTS 实际住院(天) 43 MZZD 门(急)诊诊断 44 JBBM 疾病编码 45 ZYZD 主要诊断 46 JBDM 疾病编码 47 RYBQ 入院病情《入院病情字典》 48 QTZD8 其他诊断 49 JBDM8 疾病编码 50 RYBQ8 入院病情《入院病情字典》 51 QTZD1 其他诊断 52 JBDM1 疾病编码 53 RYBQ1 入院病情《入院病情字典》 54 QTZD9 其他诊断 55 JBDM9 疾病编码 56 RYBQ9 入院病情《入院病情字典》 57 QTZD2 其他诊断 58 JBDM2 疾病编码 59 RYBQ2 入院病情《入院病情字典》 60 QTZD10 其他诊断 61 JBDM10 疾病编码 62 RYBQ10 入院病情《入院病情字典》 63 QTZD3 其他诊断 64 JBDM3 疾病编码 65 RYBQ3 入院病情《入院病情字典》 66 QTZD11 其他诊断 67 JBDM11 疾病编码 68 RYBQ11 入院病情《入院病情字典》 69 QTZD4 其他诊断 70 JBDM4 疾病编码 71 RYBQ4 入院病情《入院病情字典》 72 QTZD12 其他诊断