vkeyi项目架构设计总结

总体概况:

1.  最普通Client - Server模式

2. Client端目前包含Wince 以及Android

3. 通信方式采用Http + Json 字符的方式

4.  后台采用OSGi架构

5. 数据库访问采用ibatis + MySql【另外一端物联网接口部分用到了Oracle】

架构失误的地方:

1.  通信接口上, HTTP + JSon的方式无问题,  但采用了一个会话过期的机制以防止非法访问, 试图做成PC网页的访问session过期的方式保持长连接     更合理的方式: 无状态的HTTP连接, 每次传入用户名 + MD5 密码的方式, 保证有效性。 

【微信的接口就非常合理，可以常驻后台，但无需和服务端通信， 也不会保持HTTTP长连接。 陌陌也没有保持长连接，这样可以避免超大用户量对服务端的压力】

2.  采用不成熟的XMPP作为聊天功能, 这一功能目的是为了增强用户交流, 但这个模块Android版本不够成熟, 所以带来诸多问题, 这样的影响目前依然存在。

      更合理方式: 不采用不成熟的方案, 避免出先问题搞不定, 通信问题, 可以采用微博的API接口. 避免自己开发也方便推广。

3.  GPS定位模块出现较多问题,  这个模块隔离性比较差,  LBS作为软件的重要模块, 实在不应该这样设计

     更合理的方式: 与UI无关的功能, 尽量提取出来

4. Android客户端代码静态变量和静态方法带来了灾难,  一旦资源不足，就自动释放, 注意后面少用静态变量, 静态变量的本质是全局变量

5. UI 细节设计过度, Dialog甚至都采用了自己设计的图标, 这个绝对不可取，因为很多Android都自己定义了UI风格的默认控件, 如果自己连这样小的控件都设计，将很难做到在深度定制的UI系统比如米聊，moto手机上做到非常漂亮。 重申这里不是反对UI设计，而是小控件，比如对话框之类的，绝对要慎重，不要为了漂亮而做出一套难以适配各个平台的UI

6. 前期分离出一个下载器, 意图通过【下载器】 + 【主程序】的方式, 分辨出版本及其分辨率, 对其进行升级和版本,  经验证是个极大的失误: 增加管理成本, 没有给自动升级带来明显的好处, 用户需要下载两次等问题。   后期调整不同平台，不同分辨率采用同一个版本管理的方式

7. UI操作过于复杂, Activity过多, 用户找到自己需要的功能，有的需要点击4~5步, 同时也造成释放Activity的管理异常复杂

【我觉得陌陌这点设计很好， 基本上就是一两个Activity，所见即所得的功能操作，连Menu菜单都完全没有，这样的用户体验是做得非常到位，用户学习代价非常少, 还有一个就是网易新闻客户端，其维度划分的方式，值得学习】【采用父亲UI+ 子UI的方式, 子UI可以抹去或者新增】

图一: 复杂情况下的维度划分, 非常合理

图二: 复杂情况下的维度划分, 非常合理

图三: 没有Menu的陌陌模式

架构优良的地方:

1. HTTP的过滤器设计得很好, 这点是我没有想到. 这个主要用来拦截, 用户分析等功能, 开始我觉得没有必要, 但后来证实还是发挥了它拦截的威力

2. 客户端采用轻量级xml文件存储的方式, 缓存数据, 废弃沉重的数据库存储方式【更重要的只需要维护一套解析的代码】\

    经验: 尽量用熟悉的东西, 用已有的东西, 这样维护起来只有一套代码

3. 重用模块比较多，日志模块提取比较好, 工作简报做成可配置方式。但存在缺陷，UI重用的时候，应该采用AChartEngine这样的复用模式【单UI控件复用，而不是Activity复用, 这样可以保持足够大的灵活性】

4. 前期功能细分过于复杂, 插件数目太多, 似乎是以前HW工作留下的弊端, OSGi这端注意了均衡, 经过重构后，代码清晰了很多

    经验: 分离很好，但分离过多就带来了复杂性, 减少不必要的分割

另外一些认识上的更新, 也放在这里讨论一下:

1. 中小应用的平台， 需要有自己的数据服务器， 存储用户数据等小规模的数据， 产品先期可以省略的尽量省去，一旦需要有，则立即需要自己架设一个足够简单的服务器

2. 大数据服务器，比如图片，视频，以及文件，可以借助当下比较NB的云平台