好久没有上博客园了，也好久没有写博客了。为什么呢？最主要自己近段时间比较懒，在公司的项目里面完全找不到以前的那种成就感了。
好了，让我们回到正题上面来吧！说到自己近几个月的技术收获，我想最大的便是自己由之前的纯粹native android客户端的开发，转型到服务端了。说也奇怪，自己转型之前一直对后端的东西是比较的好奇的，一直认为native的客户端开发，其实所用的技术点都是比较局限的，没有什么高深的东西。你想想一个app真正成型起来之后，他应该包括哪些东西呢？首先也许最直观的认识就是UI界面了，确认UI起到一个承载用户直观体验的重要性。假如现在有一款app摆在你的面前，当前满怀着期待的心情打开app的时候，却...字体大的可怕，然后整个界面布局乱七八糟，甚至有的时候，某些按钮却点不了。当你刚刚静下心来，想想忍一忍，再点点试试吧。却发现连个最基本的注册、登录功能都麻烦的要死，然后各种弹窗提示。如果是这种情况下，我想好多用户已经不能够在忍了，马上卸载掉吧！所以一款好的app最起码的条件就是要有一个牛逼的设计。
说到app设计，我还是想凭借着自己的一些开发经验、还有一些书籍上面的要点，让我们摆一下例子，对比对比。首先，app设计的首要原则：1.就是极简原则。也许你知道吧，当初微信为什么会起来呢？就是凭借着提供着及时聊天功能，同时绑定着qq大面积的稳定用户，拿下来最开始的一些用户。慢慢地微信才在核心功能下来，开发了更多的用户粘性功能，渐渐地有了朋友圈、有了微信公众号。然后就有现在的微信，一个完整的微信生态圈。2.细节照顾，苹果为什么能够每出一款产品就能够大卖，甚至现在已经出现了稳定的脑残粉，每一款产品都会去定时更新、推进。让我们来看一下另一款大家都比较熟悉的app-陌陌，说实话，最初陌陌刚出来的时候，用户体验还是非常的糟糕的。整个界面字体太大了，然后呢？用户好友添加过程、或者聊天、朋友动态查看都是比较麻烦的。现在的陌陌呢？产品设计已经到了一定的级别了。今天我又重新下了一款app，重新体验了一把，发现极简、细节都已经做的很好了。3.做到上面两个原则之后，后面才有可能会留在你这个app里面。然后你要做什么呢？也许你会想到我需要加什么新的功能，才能够将用户黏在我的app里面呢？这个时候，你就需要做好充分的用户调研工作了，用户需要的才是最重要的。说起来似乎这点在app开发之处就应该做好的，然后你看我说起来似乎很简单的样子是吗？其实，这个才是最核心的东西，用户的需求总是不断的变化着，而且有的时候就连用户自己他也不知道自己想要什么。这个才是现在企业最应该关注，但是好多企业都不太关注的事情。
当我们的设计做好之后，也许你就会想这个时候，我们应该能够开始功能的开发工作了吧！我想这个应该放到第三步，第二步我们应该好好的想想到底我们的app架构的时候，应该包括哪些功能模块呢？让我们来理一理，到底app里面一个简单的登录/注册功能，应该怎么做呢？首先登录功能，当我们点击登录按钮的时候，后台到底做了什么呢？后台代码肯定会先拿到UI界面里，你输入的用户、密码吧，然后做相关的校验工作。当你输入的账号信息满足条件之后，后台代码会将你的账号、密码调用相关的api封装成请求报文，发送到服务器。服务器收到你的报文之后，它又会怎么做呢？解析报文拿出账号信息，然后查找数据库进行账号对比，不管成功、失败都会给客户端返回相应的响应报文。你想想、报文到达客户端之后，客户端应该怎么做呢？需要有一个同时兼容不同数据格式的解析模块吧！比如支持同时解析xml/json格式，拿出里面的msg字段，给出响应的提示信息（这里面可能就牵涉到一个体验细节问题，尽量不要用弹出框的方式提醒用户，可能在登录页面用不同的字体输入信息，因为弹出框的方式会打断用户的直观体验）。通过这些步骤以后一个完整的登录流程才完成了吧。所以通过这样的分析，我们发现一个app后台代码里面，最起码、必不可少的功能模块就是：Http/Https请求发送模块、数据解析模块、必要的时候，我们可能还需要加上安全加密、条件校验模块、动画模块等。
所以通过上面的分析过程，我们可以发现客户端实际上所做的事情还是比较少，甚至现在流行什么？瘦客户端的概念，移动端的东西越少越好，如果要达到这种要求，我们应该怎么做呢？H5技术就可以很好的满足这种需求，这个时候客户端只要提供一个外壳就可以了，所有的H5页面，后台代码逻辑都放在了服务端。这个时候，理论上我们只需要上线一次客户端app就可以了，而且可以实现高可配置性。但是这对服务端的要求就比较高了。
说到服务端的架构就比较麻烦了，因为服务端需要考虑的事情太多了。一个请求到了之后，我首先应该丢给哪个模块进行处理，该模块处理之后，拿到请求里面的数据。这个时候我又应该怎么进行处理呢？数据是不是需要保存到数据库，还是说我只需要简单的用个临时变量保存就可以了。或者其他页面又需要使用这个请求里面的数据，我是不是就应该保存到session里面呢？这还是说只有一笔请求的时候，如果这个时候同时有多笔请求的并发情况下呢？我同时去保存数据库是不是有可能会发生错误呢？数据保存过程中是不是有可能因为多笔操作，导致流程比较慢呢？用户体验非常差的情况，这种情况下，我是不是就应该考虑使用一个稳定/成熟的框架呢？针对数据库读写慢的这种情况，我是不是又应该考虑使用一些分布式存储的技术框架呢？内存数据也是不错的选择，最终后端系统好不容易开发完成之后，这个时候我又应该考虑部署上线的相关事情了。
好了，上面说了这么多。让我们在后面的章节拆开细讲吧！