移动互联中CS架构要着重考虑的几点

移动互联中CS架构要着重考虑的几点
2010年06月07日
　　一、想清楚到底要做BS还是做CS
　　做CS架构的缺点很明显，研发成本太高，因为手机平台实在太多了。SYMBIAN，WINDOWS MOBILE，MTK，用C/C++的主要就三个了，然后再加上JAVA。客户端程序开发测试的工作量是很大的。到了项目后期，一旦需求变动或增加新功 能，维护量那是嗷嗷的爽。
　　但是CS架构的优点也和它的缺点一样明显。首先是我认为CS架构才能真正发挥出手机"移动"的特点来；其次，做CS架构的软件才不容易受到门户网站、互联 网巨头的冲击。
　　所以，如果有足够的预算和野心，就做CS架构；如果只是做来玩玩，或者是某个主营业务的拓展分支，就做BS。
　　我 现在是决定做CS，所以后面都是以CS架构来讨论的
　　二、客户端多瘦，服务端多胖
　　现 在的主流模式是瘦客户端&胖服务端。主要的处理逻辑、数据存储都放在服务端做。但这样的缺点就是网络流量大，用户花费高；而且由于网络延迟，用户 体验会降低。所以必须考虑把一些不太经常变化的、相对稳定的逻辑和数据存储可以缓存在客户端。但一味地缓存又会使客户端越来越肥；而且先取本地缓存，没有 的话再取从服务端取的策略，也会降低数据的时效性。因此，我们需要一种在客户端数据缓存管理策略，一方面可以管理缓存的总量（比如不能超过5M），一方面 可以管理缓存的时效（比如早于一周下载的数据会被清理掉）。这个策略会被各模块所共用。
　　三、通信协议
　　CS 架构里最烦的一件事就是通信协议。不论是用Web Service接口，或者XML，或者私定义的什么格式，我归纳了下每个字段都跑不开这么三个要素：在某次传输中的序号、数据类型、值。然后需要维护一份 巨大无比的文档来说明每个包每个字段的物理意义。这真是件无比痛苦的事情。
　　现在可能还有人在用最原始、但传输量最小的方法，就 是字节对齐、第几字节到第几字节是什么量什么物理意义。神啊救救我吧，那真是停留在石器时代了。
　　GOOGLE开发了一套叫"Protocal Buffer"的开源小项目，专门用来做这事。http://code.google.com/intl/zh-CN/apis/protocolbuf fers/docs/overview.html  支 持C++，JAVA，和Python三种语言。要知道GOOGLE和MSFT是竞争对手，所以没支持C#，C#程序员可以到一边凉快去了。据说这套方法本 质上还是基于XML的，只不过中间用了一层压缩和解压缩算法，使得在网络上传输的字节数，比直接用XML传节省了6/7左右。
　　可惜我是在花费十来天做完自己一套方法后，才知道有Protocal Buffer这东西的。不过我觉得抽象概念上都差不多。怎么搞都跳不开几个要点：
　　1、 模糊的值类型。上层应用想传输的可能是数值，或者字符串，或者一个数组，或者是一个MAP映射表。再来传个N字节的二进制BUFFER。这数组里面每个元 素的值类型还不同的还不同的，有的是数值有的是字符串；最好还能数组套数组，数组套映射，无限级联……。很神奇的是，我居然很臭屁地用C++做出来了。
　　2、 序列化和反序列化。我是做个容器来放上面描述的模糊数据类型，然后能把这个容器序列化和反序列化，这样就能实现CS通讯了。GOOGLE那套 Protocal Buffer里头用XML会更简单些，本来就是纯字符串，右面对字符串压缩一下就可以了。
　　3、数据包错误时自恢复。 CLIENT端或SERVER端收到了错误的、不完整的数据包，能够辨认出来，扔掉，下个正确的数据包拿到后可以恢复正常工作。这其实很简单，参考MP3 等可以流式传输的文件格式设计思路就可以了。其实系统底层的网络通信协议都封装得那么好，应用层拿到错包时你应该赶快去买体彩了。
　　四、 UI方案
　　做UI这事，说难也难，说简单也简单。全世界每天都有无数的程 序员在摆弄DIALOG、BUTTON、IMAGE和STATIC TEXT之类玩意儿。想起来真是无聊之极，不过倒也解决了N多人的就业问题。但就是有些不甘无聊的UI程序员，做了套牛B闪闪放光芒的UI系统，于是 iPhone就横空出世并且大卖特卖了。
　　如果你是一个想扩张自己势力地盘的项目经理，那么就可以趁机招一大票手下。移动互联重 在互动，所以即使是个中型的CS架构移动互联应用，每个手机平台上至少会有30~50个、甚至更多的对话框，层层递进的对话框逻辑关系至少能有三到四层。 而且你需要完成三到四个手机平台。那么保守估计你的项目组一共需要在CLIENT端实现并维护150个以上的对话框。可能某一天你把产品递给老板看，老板 一拍脑袋觉得这对话框太复杂了要改一下，那对话框颜色要调整一下，这里控件拜访要调整一下位置，那么恭喜恭喜，大家又有事做不会下岗了，赶快把每个平台都 改过去一遍吧。
　　如果有人觉得维护多个平台上一共150个对话框代码是在藐视架构师智力的话，那么过来咱们握一下手吧。
　　我 的设想是用一套XML方案来描述UI和逻辑。包括两方面，一是这个会对话框呈现哪些控件，相互的空间关系如何，二是应用逻辑，如某个控件被点击时发什么包 给服务器，或者被关联到执行哪个函数。另外再一套样式外观XML方案来描述各控件的缩进、底图、背景色等等风格，类似网页上用的CSS样式描述表。所以我 需要维护的代码不是150份，而是只有三四份，就是如何从两份XML动态地生成UI上的对话框，每个手机平台上各一份。UI/逻辑XML维护50份，每个 对话框一份，无视平台差异。样式外观XML维护20~30份，针对每个控件定义几种外观，够用就可以了。
　　那么我只需要找一个够 彪悍的程序员写完从XML动态生成UI的代码就可以了，测试也只要针对这一块。剩余的XML可以交给廉价的初级程序员写，或者UI设计师，甚至部门文员都 能帮着写。而如果用前面傻逼兮兮的方案，那么大概需要用三四个水平中上的程序员，除了开发，还需要浪费测试资源，后期持续地维护更新还离不开他们，整体下 来研发/测试/维护成本都会更高。
　　（有想到时再补充）