一、app三个基础的技术框架

不知道大家有没有遇到过这种情景，当你做好一个设计方案，满心欢喜地给开发讲解方案的思路和创意时，开发突然说一句：“这个方案实现不了”，这时你整个人都不好了，心里开始嘀咕“这么简单的设计都实现不了，你是搞技术的吗？”然并卵，在产品和开发的催促下，作为设计师的你只能加班加点地改方案。

到底问题出现在哪呢？这其实是由于我们设计师对App技术框架的知识匮乏所导致的，虽然我们不必做到会写代码，但掌握必要的App技术框架原理，能更有效地帮助我们预判哪些方案可行和实现效果较好，来让设计方案更接地气，让我们一起来了解一下App技术框架都有哪些。

框架，你装个.Net就好了”。

其实解决依赖环境的办法很简单，那就是所有机器都用同一套环境。但是对于一些web服务，它所依赖的软件及关联软件可能有上百个，让你去配一台机器已经要吐血了，如果让你把这个服务发布到100台不同的机器上，那么你就应该会阵亡了。同时，很有可能因为不同的机器已有的环境不同，你安装这些依赖的同时还要保证不能影响其它已有应用。

说了这么多，其实就是三个大问题，如何解决环境依赖？如何解决大规模部署？如何解决应用与应用的互相影响？Docker就是这些问题的一种解决方案，它是一个容器，也可以说是一个软件集装箱，这个箱子里面可以塞入特定版本的操作系统、数据库、服务器程序和web应用，这样一套完整的web服务就集成在这个箱子里面了，当要发布服务的时候，直接将这个集装箱放在我们的服务器船上。如果你想发布到100台机器上，没问题，只需要ctrl-c、ctrl-v，将这些集装箱复制到100台机器上，它不会在乎船的配置高低，只要能放得下就行。

如果你想发布10个不同的服务，还是没问题，你只需将这10个不同的集装箱依次排列在服务器船上，它们之间完全不会互相影响，因为各自被锁在不同的箱子里。

有的同学可能会说了，这不就是虚拟机嘛…是的，Docker算是一种轻量级的虚拟机，它比起传统的虚拟机更快，更节省资源。打个比方，虚拟机就是轮船上的豪华包间，即使它用不了这么多资源，它也霸占着不让别人使用，而Docker容器就是一个简单的集装箱，它只占据它需要的资源。

他就打开了百度的页面）来展示一个网页的，同时WebView为网页和原生App建立一个桥梁，让网页和原生App能够看到彼此暴露的一些方法，从而达到互相操作的目的。

当然，这些操作是需要前端页面和终端程序互相协商的。虽然很多App遵守了一些相同的原则，使网页在不同的APP中都能具备相同的能力，但是如果你看到同一个网页在一个App中能够调用一些安卓系统的能力，而在另一个APP中却没有对应的能力也不要觉得奇怪（找对应App的开发勾兑一下就好了）。

一个原生应用为网页开放的能力越多，网页对原生系统的操作能力就越强，就越能做出逼近原生应用的体验。但是，这却是一把双刃剑，因为原生App开放的能力有可能会被恶意的页面利用，对用户造成伤害，如何控制能力的开放，也是需要产品和开发一起思考的问题。

例如微信是一个终端能力的宿主，拥有支付，登录，分享，获取App信息等能力，并以Js接口的形式提供给前端页面使用，前端开发则需要在微信申请对应的Js接口使用权限，才能够在微信中正常使用对应的能力。

最后总结一下，网页塑造界面的优势在于灵活，随时可以更新，而原生APP塑造的界面则能够提供更流畅的用户体验，但是却无法热更新，只能依靠发布版本来提供新功能。通过上面说的这种技术，就可以利用各自的优势，规避各自的劣势来提供更好用户体验，例如在微信中购物的展示是网页形式的，方便运营快速更新，通过Js接口调用起原生的支付界面，给用户更流畅的支付体验，提高支付成功率。

/weixin/android/”来向DNS服务器获取确认“订单（下载）服务器”的IP地址，IP地址在互联网中相当于日常生活中“电话号码”，有了它，就可以连接到这台“订单（下载）服务器”，而DNS服务器就像一个存贮着大量“姓名”（域名）和“电话号码”（IP地址）的黄页。当客户端获得了“订单（下载）服务器”的“电话号码”（ip地址）后，就会连接“订单（下载）服务器”，并告知“订单（下载）服务器”客户端需要获取服务器上的“微信安卓版”apk文件，一般情况下，服务器在这个阶段确认了“订单”后，就会向客户端“快递”（传输）对应的apk文件，当客户端将文件下载完毕后，这次“网购”也就完成了。

下面，我们引入运营商（电信、联通等）网关的概念。运营商网关可以类比成日常生活中的“总机”，接入运营商的互联网设备想要能够“上网”，都需要经过“总机”（运营商网关）的转接。也就是说，在上图中的第二步，我们并不能直接通过“订单（下载）服务器”的“电话号码”（IP地址）联系到“订单（下载）服务器”，而是需要先连接到“总机”（网关），并且告诉它，我们要向某某某服务器下“订单”，经过“总机”的转接，我们才能真正连接到“订单（下载）服务器”。整个过程如下图：

可以发现，DNS服务器和网关的决策，确定了客户端“订单”（下载请求）的走向。而“下载劫持”也就发生在这两个关键节点上。

假设客户端获取下载服务器“电话号码”的DNS服务器被篡改，那么客户端可能会通过“”查询到一个“骗子服务器”的“电话号码”（IP地址），当我们联系到这个“骗子服务器”时，我们的“订单”（下载请求）可能会换来一些奇奇怪怪的“商品”。

当我们遇到这种情况时，可以手动修改DNS服务器IP（具体方法请问度娘）来解决。然而当运营商的“总机”（网关）“出了问题”（这些“问题”一般是运营商主动造成的）时，就没那么容易解决了。假设当客户端拿着“订单（下载）服务器”的电话号码要求“总机”（网关）转接到我们指定的“订单（下载）服务器”时，“总机”（网关）对客户端说“哎呀，不要去A家下载微信了，你去我给你介绍的B家下载“XX助手”吧，比微信好用”（这个过程在技术上是被一个叫做302跳转的机制完成的，如果你不知道什么是302，出门左转，查询我们星期一的文章）。客户端是个实在人，就这样被“引诱”到B家的服务器上下载了。

“总机”（网关）和服务器B就这样沆瀣一气，来骗客户端的下载量。

①正常情况下，涉及前台和用户行为的业务流程：

②涉及后台的产品数据&订单状态更新（部分简略）：

按接口类型和属性可分为三类：数据类、交易类和通知类。有一部分为美团接口，另一部分接口需要商家进行开发。

数据类：商家数据对接到美团（涉及到商家的4个接口，拉取产品信息、产品变化通知、拉取景点信息、拉取价格日历）

交易类：“用户——美团——商家”的交易行为（涉及到商家的5个接口）

通知类：包括商家开发的已出票、票已使用、已退款3个接口，美团自有的已退款、查余额、编审状态通知的3个接口。

我做过的接口产品不多，但问题类似，主要包括两类：接口问题、产品问题。接口问题就是无响应、响应过慢、重复响应等，产品问题就是存量少、变价快、时间差导致下架更新不及时等。

在做接口相关的产品时，异常与正常流程同等重要，这与核心用户和边缘用户不是一个概念。所以在考虑每一步的流程时，必须兼顾异常问题的发生与解决方法，尽量避免损害用户体验和商家损失。

一般的解决方法是数据监控，通过对每个业务节点的多项指标进行监控，一旦超出阈值，就可以用邮件、短信等形式通知相关人员，及时解决问题。

接下来我们从两个方面具体探讨如何应对这些问题。

1.用户体验——具体场景&数据监控

对用户来说，流程的任一节点不顺畅，都会导致体验不好，故根据用户行为轨迹来进行数据监控。

①页面展示慢——接口响应时长、用户页面停留时长、跳失率

Reason：实时调接口查询景点&产品信息，因数据量大或频率快导致。

Solution：缓存数据，每N分钟更新一次。

②数据展示异常——后台返回接口异常的次数和概率

Reason：接口超时或异常。

Solution：可以设定重复调用，多次重试失败后，通过邮件等形式通知到运营、技术或商家。

针对数据型接口，对产品进行下架或隐藏处理。

针对交易型接口，下单、支付的问题可以提醒用户、为用户推荐同类产品、对产品进行下架或隐藏处理；退票类问题可以建议用户之后重试，如果比较紧急可以联系客服加急处理。

针对通知型接口，不涉及用户，邮件处理即可，可人工介入更新信息。

③产品变动，特别是变价——下单失败率、变价率、出票失败率

Reason：数据更新有时间差。

当某一产品的失败率或变价率超出规定，可隐藏或下架；

针对某些产品库存少的情况进行提示，预告风险；

设定合理的定时更新任务。

④下单/支付/退票失败——失败率、失败原因

Reason：用户可能多次提交，或者订单已使用、已关闭等客观原因，无法成功。

需要加入检验机制，比如在短时间内重复提交不调用接口，直接返回原结果；

善意提醒用户不要重复提交，如“您的手太快了，请休息30s后再试”；

可以提供IM人工或电话咨询、留言等选项。

⑤服务响应时间长——手工操作订单量和占比

Reason：比如用户提交退票后长时间不退款；支付后长时间不出票

定时调用订单查询接口，更新订单状态并短信/推送消息告知用户；

超过服务规范时间前发送预警邮件，人工介入处理。

2.商家体验——数据监控&具体场景

对商家来说，用户体验不重要，转化率和利润才是重点，故数据监控以业务指标为主。

①重复生单、生单不支付占库存——订单量、订单支付转化率、支付失败率、库存占用量和支付量

Reason：用户手速太快；恶意占库存

Solution：制定规则，同一人只能占一个库存；同一订单最多只能订N个人。

②恶意重复调用接口——涉及到的每个接口调用频率

Reason：比如短时间重复调用某一接口

规定同一IP地址不能在短时间内多次调用；

直接返回第一次调用接口的结果，不再重复调用；

每个接口在同一时间最多N次调用，否则返回失败等。

③因数据更新不及时等导致的亏损——（佣金、广告）投入产出比、人为损失

Reason：用户使用后退款完成、用户支付后变价等

Solution：根据时间差、处理规则来明确划定责任方。

④结算问题——财务对账自身支出（退款）和收入（美团给商家的结算金额）

Reason：平台和商家以“T+N”的方式结算

B端订单系统里的财务对账功能，可以用邮件形式每日发送；

监测异常数据，如当日无结算、结算金额与订单金额不一致。