浅谈手机软件架构设计

 


2010-12-24 作者:陆征 来源：网络


 

今天的话题相对有些偏技术层面，主要想分享一些手机客户端产品架构工作中的一些理解，也希望得到同行的一些交流机会。

手机软件对用户来讲，是一个完整的整体，一个封装好的安装包，一个可以运行的执行文件。但是在我们设计软件，特别是一个相对复杂的软件的时候，就必须要将它的内部立体化，理清它的结构框架，确保软件的整体一致性。

软件的架构工作，通常由一个公司的研发组来做出，但是我认为作为一个参与软件产品的产品经理来说，了解一些架构设计方面的工作是会有帮助的。

软件的架构设计的重要性有两个，一个是增强项目的协作并行能力。这一点和互联网产品经常提到web重构具有相似性的。如果我们不能将整体架构标准化，不能约束好各个功能模块的衔接性，没有定义好功能层与界面层的配置协议，那么整个软件开发过程必然是一个链条式，每一个时间点只能进行一项工作，大大增加了项目开发时间，而时间永远是宝贵的。而良好的前期架构，有助于将各个功能点拆分开，交给多个人同时并行，最后仅需简单的拼装，就可以完成一个成型的产品。可以说，软件越复杂，前期合理架构就越重要。

第二个重要性，是提升软件的可扩展能力。当前的软件领域非常像房地产行业的一个地方，在于分布开发上市。一个房地产项目，占地数公顷，这里是各期楼盘，那里则是底商乃至于公园。这些不可能都做好，才会开盘销售。那么软件也一样，做好一期之后，就要面对用户，而后续的延续性版本和横向扩展能力，都仰仗良好的前期产品架构。可以说，一个产品的生命力和发展，仰仗的就是软件前期架构的合理性和前瞻性。

事实上，单一的技术主导的架构设计，存在一定的误区。研发人员多会关注前沿技术的演进，考虑将新技术的可能加入软件架构中。但是新技术与用户需求之间往往存在距离，一个是新技术可能并非具有用户所认可的产品实用性，二是新技术带来的是极不合理的投入产出性价比。而一个成熟的产品人员，会更关注实用性和用户表现力，对于用户需求的敏感程度要高于一直置身于技术发展研发人员，而且偏运营的产品会计算出运作的成本与难度。两种人相互配合，会达到更好的效果。当然，存在这样一种天才，他们是兼具技术前瞻性、良好的产品眼光，以及市场控制能力的人，这种人可遇不可求，不讨论也罢。

很多时候，我所在的产品经理群时常会争议一个产品经理要对技术了解到什么程度为止。其实这个要结合具体情况来判断。如果你的工作中很少涉及到产品前期的架构工作，更多的是对成型产品的表现层做演进性改进工作，或者更加偏重产品化后的运营、市场营销工作。那么相对而言，技术并非是关键因素。但是，如果想要按照自己的思路，去设计一款完整的产品，那么对于产品所处的平台特性、实现能力等技术层面的东西，就应该有一定的了解。

当然，试图深入了解各平台技术的具体实现，这同样是一个需要天才才可以做的事情。以手机软件而言，所涉及的平台，包括服务器所涉及的Windows/linux特点、数据库特点，终端的C\C#环境，以及android（J2ME）、symbian、WM（win CE）等等开发平台，每一个都可以深入进去钻研出无穷无尽的东西出来。研发工程师尚且分平台，有专攻，何况一个产品人员。更重要的是，是对平台的共性和特性有所了解，多去观察一些该平台下产品的功能实现程度，来判断平台的潜力。当然，这表明产品很难站在技术的前沿，事实上也不应该站在前沿。前沿往往意味着更大的风险，以及更高标准的研发投入。而且，一些无法判断的技术实现难度，可以通过和该领域的研发人员交流获得。

回到手机软件，从整体架构考虑，我们可以优先将其分类为终端（客户端）和云端（服务器端）。无论是从手机和无线网络的性能角度出发，还是从业务的控制、计费、统计和安全性考虑，我们都不可能将软件的所有工作放在终端层面。因此，一个手机软件的背后，其实往往有类似网络软件产品的支撑服务器。不过，今天主要谈终端。

而终端，实际上也应该考虑用一个梯形结构，将层级分开，做到逻辑分明，拆卸拼装方便，各模块单独维护。

简单来讲，由上至下，按照用户可见到不可见，我们可以将终端大致分为：

界面层（框架层）

功能层

数据层

层级之间，利用配置好的相应协议进行传输控制。界面层的独立，一有助于设计师可以按照相应的规范进行平行工作，而不要等到软件完成原型之后，再进行界面设计；二也符合用户对界面表现力越来越高的要求。只有将界面层独立，才可能将界面元素更进一步拆分，更换界面让软件改头换面，而又不影响软件的正常使用。

事实上，界面层应该包括基础框架逻辑（主要是根据终端尺寸和分辨率进行模块化布局）以及皮肤层（主要是以个性化为目的的可拆卸替换的皮肤和配色方案）。对于手机而言，这些还要考虑终端操作特点，比如触摸屏、非触摸屏，以及一些支持手势和力感应的终端的特殊利用。

功能层，试功能的复杂程度和关联程度，有平行并列和网状结构等多重布局。这一点实际上已经涉及到了研发人员具体编码时的功能模块拆分，这一点产品人员可以视情况适度介入。当然了解的更好，也有助于在产品需求文档撰写时更好的书写“具体功能需求”部分。有一点是需要特别注意的，就是哪些功能模块，是需要和云端交互的，而哪些是更适合放在云端而不要放在终端上的。这些内容产品人员可以在需求中提出，在具体设计过程中沟通决定。

由于一个软件产品可能涉及多终端，那么不同终端的功能层差异，也是一个重要的考虑因素。在确保核心功能被满足的条件下，对不同终端进行适当的功能层版本拆分是必要的。这时候主要参考的是产品的统一性以及具体产品维护的难度。每多一个版本，其维护的难度和成本都要相应增加，这是显而易见的。

数据层，包括了终端保存的配置文件、数据表、对应表和终端上的相关文件。这些数据的读写增删转移，当然是通过功能层来控制的。但是架构时可以着重查漏补缺，观察哪些关键数据项是在前期需求规划时被遗漏的。

事实上，功能和数据分级别细分的好处还在于，产品升级的便捷性。参考一些成熟的产品，发布大版本通常周期较长，而过程中经常会通过文件增量或者替换，来实现小规模的升级优化，这就是建立在整体结构的细致拆分之上。如果各种功能混杂编排在一起，这种微调是不可能做出的。

除了上面说的，能展开的东西还很多，但是相对是一些更具体的设计了。比如如何合理的配置网络的同步异步传输，如何在功能层设置监控点进行相应的触发逻辑。超出今天的浅谈和架构话题，以后有机会再说吧。

理解的不够准确的地方，欢迎同行指正。