移动开发设计，用户体验之我见

我从事移动互联网也有近两年时光了，这个总结主要写一下这两年得体会，从用户体验，架构设计，编码规则等方面写，有写得不好得地方，欢迎拍砖，毕竟这只是我个人体会，不能做到尽善尽美，面面俱到。

1.用户体验
把用户体验放在第一位，说明用户体验很重要，无论用什么技术还是什么平台，首先要考虑的就是用户体验；如果一款应用技术很高深，用户体验很差，注定要失败。
大家都在谈用户体验，到底什么是用户体验，我百度了下：用户体验（User Experience，简称UE）是一种纯主观在用户使用产品过程中建立起来的感受。
说得太抽象了，简单得说，就是让你用得很爽，什么叫爽？只可意会不可言传，所以是一种体验，我说几种不爽的：
a).程序不稳定，用着用着突然闪退很不爽;
b).操作复杂，一个常用功能找了半天也没找到也不爽;
c).最常用功能摸(现在流行电容大屏幕，以摸为主）好多次才能完成也不爽；
d).同一类型操作，在不同界面表现不同，经常让人很晕。
e).有效区域(除去特定功能导航区域，某个功能实际展示的区域称为有效区域）太少也不爽等等。

既然这么多不爽，那怎么才能爽呢，以下个人意见仅供参考。
a)，程序稳定，程序一定要稳定，如果经常卡主或者崩溃，谁愿意用？个人认为无论程序实现多复杂还是多简单的功能，稳定性是第一位，如果追求界面炫丽或者技术复杂高深而放弃程序稳定性，是一种舍本逐末的作法，当然这只是个人观点，不代表所有人观点；这是一个指导思想，是关于架构设计的指导思想，将在后文中关于架构设计方面还会再提起。

b），功能单一，解决某些问题，这一点跟普通PC程序有很大不同，在PC，很多程序都是集大成者，功能很强大。这一套做法在移动应用没有市场，原因有三：第一屏幕大小限制，屏幕就那么大，很多功能怎么体现？第二输入限制，现在移动平台基本都是触屏，那么小得屏幕，很容易误操作，如果摆放一大堆功能或者东西，很容易给用户造成干扰，其三CPU,内存，散热，电池续航能力等等限制，在移动平台上面做应用应该短小精悍为主，试想一下，如果一个程序启动或一个操作花掉几十秒，谁能忍受？
c），设计太繁琐，不经过培训无法使用，本人有幸参与过一款基于通讯录的群组聊天软件，在里面有好几种用户名片信息（本地通讯录信息，网络名片，组织成员信息），各种名片信息可以相互转换，有些名片可以修改，有些不能修改，有些用户可以添加，有些需要高级权限才能添加，这一套东西，你不好好琢磨琢磨还真不会用。让开发人员都会奔溃，何况一个小白级的用户呢。
d）,同一APP内一些常用习惯性操作力求表现一直，比如在聊天软件界面中，既有聊天内容，又有图册；习惯性做法是下拉获取历史记录；有些应用在查看聊天历史时用下拉，查看图册历史时有用上拉；让人着实很晕。
e).在ios中要利用好导航栏上面的左右按钮，一般左侧按钮式返回上一级，个人建议没没必要修改；右侧按钮要合理利用起来，具体可参照ios系统自带软件。本人看过一些软件，上面什么也没有，在最后一行加了一个提交或保存按钮，完全让键盘遮挡了，不滑动还真看不见。这样做一两个好处：一是方便用户触摸，减少滑动触摸次数；二是此处位置比较显眼，对用户有一个明显提示功能，也符合ios UI习惯。

2.平台
移动互联网包含很多内容，最主要得就是智能终端客户端软件；目前主流智能终端操作系统有iOS,Android两个占据90%以上市场，WP，Megoo,黑莓相对来说毕竟还是少数；在资金有限得情况下，一般公司都只选择做IOS和Android两个平台，也有好多有钱得公司比如腾讯，好多移动产品都是只推iOS和Android,著名得微信就走得这条路。

3.原生技术与跨平台
参加过几次技术交流会，看到好多跨平台技术，PC,MAC,IOS,Android统统能跨，我个人利用业余时间也研究了下QT，也做了个小程序测试了下，结果体验很差。
由于我近两年都做得是应用开发，所以在此讨论仅限于应用；个人建议要做应用，还是用原生开发语言和SDK做UI用户体验比较好。

另外安卓SDK和界面UI有自己的UI和用户操作规则，开发时要注意尽量利用自身SDK特性，符合本平台上用户使用习惯；本人看到一些应用在安卓上面仿照iOS某些效果和用户习惯，结果搞得代码很复杂，何必呢？
iOS尽量利用nav bar上面得导航按钮，Android尽量利用功能键及菜单键，虽然说Android4.0以后增加了actionbar 类似于iOS nav bar但是目前2.x得程序还是占大多数。


4.架构设计
这部分对于在CSDN里面晃悠的人来说，都是一个熟悉的话题；越熟悉的话题越难谈，原因很简单每个人都有自己的设计宗旨和设计思想；我在此只是表达一下我数十年来对于架构设计方面经验和教训。如果对您有帮助，你一句谢谢我就很高兴。如果对你没帮助，那说明你的水平比我高，还希望多多赐教。本人虽不是真正的技术控，但也很热衷一些钻研自己喜欢的技术门类，相互交流共同提高嘛。

我对架构设计就两个字-简单；力求简单，因为简单所以稳定。
下面主要对简单做一详细描述；
a).模块简单；设计模块时能少则少，每个模块力求功能单一，目前一般UI,DB,Network,protocol，util这几个模块都成系统标配了，不用我解释看名字就知道了；其他处理模块根据系统特点来决定；对于各个模块直接的关系也很有学问，根据系统的不同能直接调用的尽量直接调用；最好不要套什么外壳或者做一个中间层，处理不好后患无穷；
b）.规则简单：包括程序处理规则和编码规则；首先说程序处理规则，对于a）中其他模块都是为UI服务的，所以满足UI快速及时处理时第一位，对于UI调用其他模块刷新界面一般都用异步，异步就牵扯到数据通知和刷新，对于刷新一定要确立好处理规则，整个系统就用这种规则统一处理；这样做的好处多多；有两种情况，一种是UI发起请求，请求后台数据，对于这种情况一ios为例，两种处理最好:GCD和delegate;第二种情况是后台有数据需要刷新界面，也有两种处理方式KVO和Notifycation；我更喜欢后者，当然可以用其他方式，比如delegate，不推荐使用；条条大道通罗马，我一般选择少写代码容易维护的道路。多一行代码多一个坑嘛。
对于编码规则，我想我也不想说太多，这个必须要有；最重要的是一些命名规则，书写格式和关键代码的处理，大家都按照规则处理，代码可读性会增强很多，也便于维护。
c).关系简单：各子系统或者模块之间尽量减少交叉引用；要利用好每个操作系统或者变成语言提供的有效设计模式来处理其关系。

以上是个人基于架构设计关于简单的理解和经验总结，到现在肯定有人会提出疑问，按照我的设计规则来设计，如果有功能需要扩展，如何扩展？这个问题很好，各位先不要着急，下面我就回答一下：
首先，简单并不表示没有扩展性，在设计的时候要考虑有一定的扩展性，不能太过度；考虑太多，设计太复杂会变成过度设计，我参与过很多项目，有很多就是由于前期考虑太多，可扩展性太强最后导致项目很难维护，多了很多本来不必要的模块和子系统。所以这个度一定得把握好，个人意见宁可少扩展，也不要多扩展。因为少了我们可以通过重构来完成。
其次，重构是另一种设计，如果出现bug，或者有一些新的小功能需要实现，切记打补丁，一定要理清关系进行局部重构彻底解决问题，如果采取打补丁，久而久之就会成为系统累赘，到最后换上几岔人，谁也不知道突然出来的一段代码是做什么的，变成一个没人敢动的孤岛。如果整个系统架构简单，处理流程和规则都简单，发现不符合规则的进行重构，这问题可以避免。当然这样做是需要领导支持的，因为重构是需要时间成本，这个时间成本和让项目失控比较起来，我想还是划算的。

这就是开始简单，修改重构，过程可控。如果设计一个系统到最后变成一个不可控的项目，到最后都摆脱不了推倒重来的命运，因为没人能搞的定，还不如重新设计一套系统来得快，重新设计可以吸取老系统的教训。

还有一点，就是一个系统设计好了，要和相关得人商量开会再定夺，这个过程叫review，毕竟一个人得能力有限，也有盲区，大家取长补短，三个臭皮匠还抵一个诸葛亮呢，何况一群高级码农呢。

所以一个项目的关键不是有几个高手能解决问题，能当救火队员；最好的情况是能有一个好的架构和和一套规则，让项目变得可控，即使城头变换大王旗，我自浑然不动可把控。

本人文笔实在不是很好，不能妙笔生花，力求能说明问题，我一向很随意，也许没有很强的逻辑性，大家凑合看懂就成。如果有好的建议和意见，还请多多提醒和赐教，本人会虚心接受，活到老学到老嘛。对于无礼谩骂本人一向拒绝，请有此想法的还是免开尊口。



小文写至此处，也要快结束了，照我个人习惯，对自己也有个总结。对我来说2012很有收获，当然主要是在码农得技术生涯上得收获，11年算是入行进入移动互联网，开始移动方面开发，12年算是对移动互联网有了一个更深得理解，在技术上面也更近一步，一个产品如何从想法到最终产品发布基本有自己一套运作方式了，人多有人多得玩法，人少有人少得玩法，我是一个方法论的推崇者，只要掌握方法，灵活运用就能解决问题。

2013年已经来了，我们还得生活，只要你还活在这个世界上，就得忙碌，正所谓“生容易，活容易，生活不容易”；这年头什么都涨了，就一样不怎么涨，我不说你也知道是什么，毕竟年景不好，想开点，别给自己添堵，喜也一天，忧也一天，有什么理由让自己放弃喜选择忧呢？希望大家在2013年都有一个好得收成，天天好心情。