边界接口设计
用户交互设计原则、模板
分离具体业务，基于认知规律，抽象出通用指导原则。
总体原则
l 心智模型：感知；理解；目标、计划、执行、解惑、总结；
l 一致性：习惯、操作系统、品牌识别、关联软件、软件内部
感知体验
原则：简洁、对比、流畅
视觉：配色、布局、排版、动画
媒体：文字、图像、音视频
交互：键鼠、触摸、手势
理解内容
原则：降低复杂度
主次：重要(基本)、次要(详细)
分组：同类信息
分层：面向用户、面向设备
联想：运用比喻、类比辅助理解
任务处理
原则：站在用户角度（使用用户语言、工作流、交互流），简单（步骤少、有向导）,智能
目标（做什么）
被动任务通知：紧急信息、重要信息、普通信息
主动任务导航：常用功能、所有功能（功能分组、子功能）
计划（怎么做）
分解流程，预计花费时间，分析使用者情绪
执行（做得好）
输入：模板、向导、默认值
提交：动作、响应、历史
处理故障：预防避免、提示改正、恢复、提交故障反馈
寻求帮助：提示、帮助文档、咨询反馈、远程协助
典型场景
安装：硬件连接向导、一键安装环境，程序安装向导
调试：部署人员工具箱
培训：演示、试用、多媒体帮助文档、宣传材料
日常使用-主界面
l 待处理任务：区别重要性、复杂任务向导
l 常用任务：快捷访问，复杂任务向导
l 功能导航：提供所有功能的入口
日常使用-功能界面
l 多模块：划分子功能、划分功能步骤（向导）
l 数据显示：基本信息（列表）、详细信息；信息分组
l 表单提交：提供模板、提供默认值、隐藏高级参数；模糊查询、高级查询；
l 提交响应：主动（即时、长时）、被动（系统通知）、及时紧急通知
日常使用-处理故障
l 提示：输入错误实时提示、业务逻辑提示、提交后提示
l 恢复：向导
l 反馈：环境与日志输出向导
软件升级：自动升级、新功能使用向导
风格指南
LOG、配色、功能模板、语言词典
跨平台接口设计原则、模板
设计原则
职责独立：上层决定下层，下层提供可行性验证，上下层依赖抽象
通信类型：请求响应(即时、长时)、通知
模板-PINVOKE
会话类型
同步请求DLL
类似于System.IO. Stream类的方法
int Read(byte[]
buffer, int offset, int count)
异步请求DLL
类似于System.IO. Stream类的方法
IAsyncResult
BeginRead(byte[] buffer, int offset, int count, AsyncCallback callback, object
state)
int
EndRead(IAsyncResult asyncResult)
DLL主动通知
例如告警信息上报
基本概念
参数寻址方式
DoWork(MyStruct x); 要求零级间接寻址。 允许
DoWork(MyStruct* x); 要求一级间接寻址。 允许
DoWork(MyStruct** x); 要求二级间接寻址。 禁止
结构类型字节对齐
单字节
状态模板
启动
初始化开始-》各项设置-》初始化结束
正常运行
基本状态：连接、断开；接口：注册，注销，连接、断开事件通知
关闭
释放
函数模板
请求
Int 模块名方法名( [const] 类型1 _参数1， [const] 类型n _参数n)
类型分类
简单类型：char、char*等
结构体：Json
输入输出
参数可以作为输入或输出使用，默认为输入，如果是用于输出需要注明
回调
XXXCallback(int业务标识，
枚举类型 事件类型, object 事件参数)
XXXCallback(int业务标识， object 参数)
重构：去除超时参数（由实现方决定是否超时，然后通过返回值体现）、不加Sync
DLL主动通知
代码模板
模板-SOCKET私有协议
会话类型
请求：例如链路建立与链路响应，支持一次请求中包含多条关联报文
通知：例如心跳报文、GPS信息上报
基本概念
报文格式
报文 = 报文头 + 报文内容
报文头格式如下
字段 | 类型 | 长度(字节) | 说明 |
起始标识 | Int16 | 2 | 固定为0xAAAA，用于识别报文开始 |
报文内容长度 | Int32 | 4 | 后面所有字段总长度 |
功能标识 | Int16 | 2 | 用于识别报文类型 |
注册标识 | Int32 | 4 | 类似于动态密码，客户端注册成功后获得 |
发送方事务标识 | Int32 | 4 | 由发送方指定。当会话类型为请求型时，用于区别发送方的不同请求；当会话类型为通知型时，固定为0。 |
接收方事务标识 | Int32 | 4 | 由接收方指定。当会话类型为请求型时，用于区别接收方的不同请求，特别的，会话开始的第一条报文，发送方的该字段填0；当会话类型为通知型时，固定为0。 |
事务标识
以链路建立为例，正常流程是客户端发送“链路建立”，服务器端发送“链路建立回复”。客户端发送时，在报文头填写“发送方事务标识”为X（X不为0，可以用递增的方式区别不同请求过程），“接收方事务标识”为0；服务器发送时，在报文头填写“发送事务标识”为Y（Y不为0），“接收方事务标识”为X。
如果客户端发起对同一号码的两次跟踪，那么两次跟踪的“发方事务标识”应该是不同的。
一个报文如果发方事务标识和收方事务标识都为0，表示是通知型会话；如果发方事务标识不为0，收方事务标识为0，表示请求型会话的第一条报文；如果发方事务标识和收方事务标识都不为0，表示请求型会话，但不是请求过程中的第一条报文。
注册标识
逻辑上用于鉴权，类似于动态密码。服务器端和客户端通信的第一组报文就是注册与注册响应（链路建立与链路建立响应），注册成功后，客户端获得注册标识，之后服务器和客户端通信的所有报文的报文头中，都包含该注册标识。客户端重新注册后会获得新的注册标识。
变长报文
有些报文中的部分字段是可选的或者是变长的，都可能导致报文的长度是可变的。这就要求，解码报文时需要逐字段解码。定义报文的字段时，用（*）表示该字段是可选的或是变长的。
解码规则
接收到的所有字节存放在接收字节队列中，先依据起始标识（0x55AA）寻找到可能的报文头，解码报文头，获得功能标识、报文内容长度、注册标识，验证功能标识合法性、验证报文内容长度小于等于1000、验证注册标识的合法性，如果验证不成功，继续寻找可能的报文头，如果验证成功后，读取报文内容字节，依据具体功能的报文结构逐字段解码报文内容，如果解码成功，则在队列中截掉该报文对应的字节（如果报文头之前还有字节，也截掉），如果解码不成功，继续寻找可能的报文头。
字节序
short(int16)、int(int32）、long(int64)、ushort(uint16)、uint(uint32）、ulong(uint64)采用网络字节序编码，关于网络字节序的具体概念，请参见MSDN或是百度。
单字节对齐
因为服务器与客户端都是X86/X64平台，对字节对齐没有特殊要求，所以采用最简单的单字节对齐。
代码模板
模板-桌面应用程序与网页
会话类型
桌面应用程序发起请求
例如：桌面应用程序使用定位功能，发起在网页中显示地图位置的请求
网页发起请求
例如：在地图中已定位的图标（对应一个人）上，发起在桌面程序中对该用户的呼叫
基本概念
桌面应用程序
对象：
System.Windows.Forms.WebBrowser、HtmlDocument
成员：GetElementById、InvokeScript、AttachEventHandler
复杂参数传递：JSON方式
对象：JavaScriptSerializer
状态模板
桌面应用程序和WEB客户端的状态同步
桌面应用程序：属性（简单类型、各种集合类）
WEB客户端：JS全局变量（简单类型、Array对象）
