本发明属于移动互联网技术领域，特别涉及一种用于旅游产品销售的客户端系统。
背景技术：
H5是HTML5的简称。HTML5是HTML最新的修订版本，是一种超文本标记语言。H5作为一个集文字、图片、动画、链接等展现方式为一体的场景页面，已经在微信中进行了广泛的传播。当H5详情页用于产品分享的场景，旅游产品销售门店的工作人员将产品的内容分享给客户，让客户在即时通讯软件上就可看到产品详情，仔细了解产品信息。然而，作为移动终端的手机应用，H5详情页由于需要点击打开浏览，由于信息量和显示屏幕尺寸的问题，不便于客户快速了解产品重点，区别不同产品的特色。
微博推出的产品微刊由多张图片及文字组成，用户可以将站内或者站外喜欢的内容采集到过来，类似糖堆、花瓣、topit.me等社会化分享站点的“专辑模式”，页面呈现上采用了目前流行的“瀑布流”布局。
技术实现要素：
本发明的目的是提供一种用于旅游产品销售的客户端系统。
一种用于旅游产品销售的客户端系统，将旅游产品信息用微刊的方式分享到移动终端，该微刊内容包括旅游产品的特色、行程、预订政策基本信息，
用户通过不断上滑浏览微刊，
如果用户对旅游产品感兴趣，只需要在页面底部输入手机号，提交后，意向用户信息就会通过短信推送到相关销售顾问的终端上。
旅游产品的微刊共享到移动终端的即时通信软件上。
微刊分享的实现接口是，
通过dubbo服务框架获取底层封装的业务信息，再与客户端通过HTTP传输协议将返回的数据以JSON形式进行解析，
客户端拿到与接口协商定义好的分享名称、分享文案、分享链接字段数据，再通过第三方SDK，将数据集成分享到各个平台，用户再通过分享链接进入原先预定好的展示页面，
用户填写完手机号提交后，H5通过http请求访问接口内容里面的发送短信的接口，传入参数分享页面的分享用户名、客户的手机号、以及分享页面的地址，接口通过分享用户名远程dubbo调用数据层的方法来获取要发送到的手机号，通过封装将客户的手机号、分享的页面地址以及要发送的顾问手机号当作参数传入spring-dubbo-consumer.xml配置的远程调用的发送短信接口，调用成功时返回true传给客户端，调用失败时返回false给客户端，客户端通过判断接口返回的值来进行相对应的提示。
为实现行程数据的显示，在客户端屏幕的滑屏动画里加入滚动条事件，即在一屏展示不完的情况下，通过向上滚动来查看下面的内容，
当手指向上滑动时会触发Swiper滑屏动画滚动到下一页，若当前页有滚动条存在，就阻止默认事件滑向上一页或下一页，然后运用touch事件不断监听手势，根据当前手势来触发滑向上一页或下一页的指令，
如果滚动条在顶部时，当前手势向上，就触发滚动到上一页的指令，手势向下就触发滚动条事件；
如果滚动条滚动到底部，手势向上就触发滚动到下一页的指令，手势向下就触发滚动条事件，
对于左右的滑动，采用了css样式来实现。
进一步的，用户输入中文姓名后，自动补全对应的英文；
在英文姓/英文名中获取焦点时，把中文姓/名自动补全至英文中；
英文姓取姓名中第一-第N个字，数据参考百家姓；
中文姓名为复姓时，第一个词条展示复姓，第二个词条展示中文名第一个字的拼音；
遇到中文多音字时，平铺展示所有改字的读音。
当客户端为安卓系统时，
在获得用户中文名一栏输入的字符串后，对字符串的首字母进行截取判断，如果是汉字，就截取和转译，同时进行监听，
首先去除特殊字符和表情，如果整体是纯英文，英文汉字混编,我们会给予用户提示更改成“请输入中文汉字”的提示框以保证在输入端的录入正确，之后以dialog提示选择框的形式来让客户选择并把对应的拼音带入对应列表中。
在逻辑方面，确保用户输入是汉字之后，为区分复姓，进行二次匹配，在名字长度大于3时，去截取前两个汉字或者更多去匹配我们本地录入的常见复姓，匹配规则是截取输入的排头且连续的汉字(从2开始到N，N最大为总长度-1)去在表格查找对应数字的汉字，从长到短匹配，如果匹配不到复姓的数据，即说明复姓库里不存在，那么便截取第一个汉字为姓。和匹配字数N都是后台给予，本地设置版本号和缓存，以便后台数据随时添加一些特殊姓氏和更新百家姓数据库，以便更正有些“特殊姓氏”带来的麻烦。
最后在半自动翻译的情况下，我们保留了手动录入的功能，以补全功能盲点，比如此人叫“欧阳峰”，在复姓中“欧阳”存在顾可以匹配，但若此人姓“欧”，名“阳峰”，我们的匹配便会不对，但对每一个复姓都采取选择性选取的话，又不能方便最大数，所以对此我们保留手动录入。介于用户信息可能与证件采集挂钩，我们的开发针对这些小细节都充分考虑，以确保用户信息的准确性和良好体验。
整个Pinyin4j采用门面设计模式，使用PinyHelper核心帮助类的静态方法，
使用稀疏数组SparseArray代替HashMap数据存储，使用延迟整理数组的方法对SparseArray删除数据进行优化。
当客户端为iOS系统时，英文姓/英文名中获取焦点，把中文姓/名自动补全至英文中；英文姓取姓名中第N个字，数据参考百家姓；复姓时，第一个词条展示复姓，第二个词条展示中文名第一个字的拼音；多音字时：平铺展示所有改字的读音；以上是在用户输入正确的情况下，在用户的输入不为中文的时候，如果输入的是拼音的话，会自动转化成大写的字母，如果为其他不能转化成大写字母的字符或者表情的话，会被忽略，以此来保证用户输入的正确性；在用户的输入没有问题的情况下，app会以弹框的形式展示出转化成的英文，一般会有多个，来供用户选择。具体的中文转英文的实现过程如下：
门店的iOS版本是通过自己开发的LvmmPinYin库来实现的中文转英文，LvmmPinYin是一个准确、完善的字库，中文转英文的速度快，能支持多格式拼音输出，能够识别绝大多数多音字和复姓，支持繁体字转化为英文；
在LvmmPinYin文件中，预定义三个字典文件，包括：
pinyin.json文件定义了汉字和对应拼音的键值对，
multi_pinyin.json定义了多音字、词语，
chinese.json则定义了繁体字和简体字对应的键值对，用于繁体字和简体字的转换，
三个字典文件包含了Unicode编码从4E00-9FA5范围及3007(〇)的20903个汉字中，除46个异体字之外的所有汉字；经过测试，转换Unicode编码从4E00-9FA5范围的20902个汉字，具体的转换过程是：
获得输入的中文之后，从字典文件里面找到相应中文对应的拼音，多音字的话，返回多个让用户自行选择；
繁体字转拼音，是把繁体字先转化成中文，然后再转化成拼音。
客户端页面顶部具有标题栏，长按顶部的标题栏后，显示旅游产品每日的返佣价格，松手后隐藏返佣价格。
本发明的用于旅游产品销售的客户端系统，解决了产品信息分享的快速分享，以及姓名输入时中英文自动输入问题。
具体实施方式
本发明的用于旅游产品销售的客户端系统的产品分享的场景，源于门店的工作人员将产品的内容分享给客户，让客户在即时通讯软件上就可看到产品详情，仔细了解产品信息。
综合考虑使用场景，我们放弃了传统的直接套用H5详情页的展示方式。采用微刊的设计形式，用户只要不断上滑，就可以看到产品的特色、行程、预订政策等信息。如果用户对产品该兴趣，只需要在页面底部输入手机号，提交后，意向的用户就会通过短信推送到相关顾问的手机上，保证了顾问对每个意向人及时跟进，减少丢单。
接口通过dubbo服务框架获取底层封装的业务信息，再与客户端通过HTTP传输协议将返回的数据以JSON形式进行解析。客户端拿到与接口协商定义好的分享名称、分享文案、分享链接等字段数据，再通过第三方SDK，将数据集成分享到各个平台，用户再通过分享链接进入原先预定好的展示页面，让用户能快速了解到当前推荐产品的基本信息。保证了：
1.业务环境的稳定
首先通过DUBBO+NGINX模式，将业务逻辑进行解耦，分布在不同服务上，再通过NGINX反向代理，实现分流和负载均衡，对一些不太变化的业务数据后台进行缓存，保证业务环境的稳定。
2.客户端与后台数据传输
客户端通过HTTP请求，调取后台返回的JSON形式数据，解析约定好的code进行业务状态判断，获得body返回的具体业务数据。
3.客户端分享
客户端通过第三方分享SDK，将获取到的业务数据按照第三方要求进行封装，避免了不同分享平台的对接接口的差异性，节省了维护成本。
通过Swiper滑屏动画并嵌入上下滚动、左右滚动(滑屏)实现旅游产品的展示，包括价格、介绍、行程安排。动动手指即可在音乐中轻松了解旅游产品的详情。可在Swiper中文网了解更多关于Swiper的使用。
整个旅游产品的展示分为四屏动画，首页展示了旅游产品的相关图片并配以产品信息介绍，包括名称及价格；下一页同样是图片展示配以推荐理由说明；第三页为行程介绍页，主要展示了旅游产品的几天几晚的具体安排，由于行程天数大多不止一天，所以此页添加了可左右滑屏查看所有天数行程的功能，并在顶部配以滑至具体某一天的tab导航，轻松切换至想细看的某天行程；最后一页可输入手机号预定自己喜欢的旅游产品，也可根据展示的顾问的联系方式了解更加全面的信息。当然，这些信息的展示是利用Ajax从接口动态读取的，根据旅游产品的标识来找到对应的信息然后放置到相应的位置。关于音乐的播放，根据截取链接后面的音乐索引值来从已准备好的音乐文件夹里加载指定的音乐，但链接拼接的音乐索引值是随机的，以增加音乐的新鲜度。
根据旅游产品的标识从接口里获取到具体的行程，行程是多个的，这里默认取第一个行程。此项目中最重要的接口就是行程结构化接口，它里面的东西比较多，判断逻辑稍微复杂些。举个例子，并不是每天的行程安排接口里都有行驶至目的地的时间、距离或者用餐安排，当接口里没有这些数据时，就要控制这些样式在前端不显示。所以和接口约定好字段的处理逻辑和做各种判空，避免发生展示的错误。
考虑到手机屏幕的多样性，一天的具体行程对于普通手机的屏高来说是远远展示不全的，所以在这个问题的困扰下，决定在滑屏动画里加入滚动条事件，即在一屏展示不完的情况下，可通过向上滚动来查看下面的内容。这里就牵扯出了另一系列的问题，当手指向上滑动时会触发Swiper滑屏动画滚动到下一页，而并不是自己预想的触发滚动条事件。所以难点问题就来了，如何在有滚动条存在的情况下，把内容都展示出来才让当前页滑动到下一页呢？最终决定用诸多判断来尝试解决：若当前页有滚动条存在，就阻止默认事件滑向上一页或下一页，然后运用touch事件不断监听手势，根据当前手势来触发滑向上一页或下一页的指令。如果滚动条在顶部时，当前手势向上，就触发滚动到上一页的指令，手势向下就触发滚动条事件；如果滚动条滚动到底部，手势向上就触发滚动到下一页的指令，手势向下就触发滚动条事件。虽然在Swiper里可以同时套用上下和左右的滑屏结构，但是这样会造成在手机上操作时不够流畅，所以在我的项目中采用了另一种方式即用css样式来实现左右的滑动，给装行程信息的最外面的盒子加上这些属性：
(white-space:nowrap；overflow-x:scroll；-webkit-overflow-scrolling:touch；overflow-scrolling:touch；)。
用户填写完手机号提交后，H5通过http请求访问接口内容里面的发送短信的接口，传入参数分享页面的分享用户名、客户的手机号、以及分享页面的地址，接口通过分享用户名远程dubbo调用数据层的方法来获取要发送到的手机号，通过封装将客户的手机号、分享的页面地址以及要发送的顾问手机号当作参数传入spring-dubbo-consumer.xml配置的远程调用的发送短信接口，调用成功时返回true传给客户端，调用失败时返回false给客户端。客户端通过判断接口返回的值来进行相对应的提示。
本发明的中英文输入转换的产品设计是，手机上使用APP，痛点在于输入的不便。在中文名转换成拼音姓名的时候，还存在不同地方口音拿捏不准，多音字等易填错，可能导致用户出行受阻。从帮助用户输入的角度考虑，店店赢客户端在用户输入过中文姓名后，点击英文姓/英文名时，会根据输入的汉字，自动帮用户转换成拼音名。针对多音字，还可以让用户选择读音。并与百家姓库匹配，精准识别单姓和复姓。做到了降低用户的输错概率，提升了输入的操作体验。
用户输入中文后，自动补全对应的英文；在英文姓/英文名中获取焦点时，把中文姓/名自动补全至英文中；英文姓取姓名中第一-第N个字，数据参考百家姓；复姓时，第一个词条展示复姓，第二个词条展示中文名第一个字的拼音；多音字时：平铺展示所有改字的读音
对于Android的实现是，在旅游产品下单页,需要填写游玩人信息时,出境之类的护照等姓名需要国际标准,针对后台需要的英文格式,我们开发出此输入中文姓名,可以自动转化为英文名的功能模块,并区分多音字,提示框选择填入。
在o2o下单后填写我们需要填写证件信息，需要将汉字编程对应的拼音，以方便数据的处理。比如在Android手机应用的开发上，要查询联系人的姓名，通常都是用拼音进行查询的。比如要查询“驴妈妈”，就可以输入“lmm”，即“驴妈妈”三个汉字的拼音“lvmama”各字的首字母。但是怎样才能将“驴妈妈”翻译成“lvmama”呢？很简单的办法就是建立一个大的对照表(比如用关联容器Map)，比如<”驴”，”lv”>，<”妈”，”ma”>…但这样的做法，需要维护好一个比较大的对照表，同时一个汉字可能有多个发音，也就是说Map这样的容器时不行的，因为其<key,value>必须是一一对应的。在C++中可以用STL里面的multimap来解决这个问题，但Java中没有类似multimap这样的东西，除非自己实现一个。
Pinyin4j就是为了解决类似这样的问题的。它是sourceforge.NET上的一个开源项目，功能非常强大：支持同一汉字有多个发音,还支持拼音的格式化输出，比如第几声之类的，同时支持简体中文、繁体中文转换为拼音。我们以此为核心实现，封装了自己的翻译模块，并支持多音字选择框。
在获得用户中文名一栏输入的字符串后，对字符串的首字母进行截取判断，如果是汉字，就截取和转译,如果是英文开头,不作处理。整个功能通过单独的自定义Dialog模块完成。由于转译要给予庞大的汉字数据库去匹配，时间效率就是表查询，空间效率有点差，需要载入整个对应表。
首先为你要转译的内容设置格式，这里需要一个名为HnayuPinyingOutFormat的实体类，他包含几种常用的Type：大小写，声调，编码标准。
整个Pinyin4j采用了门面设计模式，PinyHelper是核心帮助类，使用它的静态方法可以轻松实现功能。但是Pinyin4j是单纯的转移汉字，如果想要实现区分复姓，我们需要在此基础上进行二次匹配，设计思路是在名字长度大于3时，去截取前两个汉字或者更多去匹配我们本地录入的常见复姓，匹配规则是截取输入的排头且连续的汉字(从2开始到N)，复姓的数据，和匹配字数N都是后台给予，本地设置版本号和缓存，以便后台数据随时添加一些特殊姓氏，由于现代人起名多变，我们对此需求的设计和数据采取定会不完整，于是一直保留手动输入功能。
数据存储的细节方面我们使用了SparseArray(稀疏数组)代替HashMap，在这种数据查找存在检索的下标时更加高效。Android这种内存比CPU更金贵的系统中，能经济地使用内存还是上策，何况SparseArray在其他方面的表现也不算差(另外，SparseArray删除数据的时候也做了优化——使用了延迟整理数组的方法，使得在数据在高频率活动时优势非常明显)。
对于iOS的实现过程是，为了完成中文名称自动转英文的需求，需要一个中文转化拼音的工具，由于iOS框架没有很好的支持中文转英文，这个工作也就成为了我们开发任务的一部分。
在开发这个库文件的时候，对该库有以下几个要求：
1、必须是一个准确、完善的字库
2、要能保证转化速度
3、要能支持多拼音格式输出
4、能够识别出常见的多音字
5、能够识别复姓
6、能够实现繁体字转化拼音。
采用LvmmPinYin对汉字转拼音的支持，主要是通过预定的字典文件实现的；LvmmPinYin预定义了三个字典文件：
1、pinyin.json文件定义了汉字和对应拼音的键值对，部分内容如下：
″与″：″yǔ，yù，yú″，
″丐″：″miǎn″，
″丐″：″gài″，
″丑″：″chǒu″，
″丒″：″chǒu″，
″专″：″zhuān″，
″且″：″qiě，jū″，
″丕″：″pī″
2、multi_pinyin.json定义了多音字、词语等，部分内容如下：
″声调″：″shēng，diào″，
″音乐″：″yīn，yuè″，
″乐曲″：″yuè，qǔ″，
″乐器″：″yuè，qì″，
″乐谱″：″yuè，pǔ″，
″缝隙″：″fèng，xì″，
″胸脯″：″xiōng，pú″
3、chinese.json则定义了繁体字和简体字对应的键值对，用于繁体字和简体字的转换，部分内容如下：
LvmmPinYin为了实现较准确的转换，三个字典文件包含了Unicode编码从4E00-9FA5范围及3007(〇)的20903个汉字中，除46个异体字(异体字不存在标准拼音)之外的所有汉字；经过测试，转换Unicode编码从4E00-9FA5范围的20902个汉字，LvmmPinYin耗时约100毫秒。
具体的转换过程是：拿到输入的中文之后，从字典里面找到相应中文对应的拼音，多音字的话，返回多个让用户自行选择；繁体字转拼音的话，是把繁体字先转化成中文，然后再转化成拼音。
因为采用顾问+门店的销售模式，所以需要每单给各级分销对象相应的利润回报。在门店体系中，我们设计了子公司、分社、门店、顾问4级的利润回报体系。实际销售中，会根据账号所在的不同体系，抽取对应的分成。
手机APP使用的场景，存在与顾客交流的即使性。当与顾客交流产品时，我们不希望把所得利润直接展示给顾客，在设计上，综合考虑了滑动开关、点击开关等各种方式展示返佣价格。因需要操作的隐蔽性和即使性，又要防止用户误操作而看到返佣价格，最后选择长按顶部的标题栏，因为此区域是手机屏幕点击的非热点区域。长按后，显示每条线路每日的返佣价格。松手后隐藏返佣价格。足了顾问快速查看返佣价格又可不展示给用户的场景。
操作用例：
1、页面默认不显示返佣价格
2、手指长按1.5秒钟当前页面的标题，显示当前页面上的返佣价格；
3、手指松开，返佣价格消失；
4、当前页面上没有返佣价格时，如果检测到用户长按标题1.5秒钟：
展示文案：这页没有积分显示哦～。
显示2秒后，消失。
返佣价格政策实现方案
从业务要求上来看要求返佣价格政策主要是按照不同品类产品给出不同的返佣价格政策：细分为保底返佣价格和原始返佣价格
在技术实现方案上使用spring+springmvc+mybatis+oracle/mysql经典架构。基于分布式开发集群部署，采用多数据源，根据业务能快速扩展服务器。
1、系统扩展性：考虑模板设计模式，跟进不同品类实现不同的返佣价格计算细则，方便根据不同的品类灵活调整，以及新接入品类的扩展性
2、系统性能：考虑不同的应用场景，如搜索页，详情页，下单页以及创建订单后，采用多实现方法灵活控制是否走缓存
3.主要业务需求
(1)根据返佣设置计算成人价子公司的原始返佣价格；计算公式：成人价子公司返佣价格金额＝(驴妈妈销售价-驴妈妈结算价)*子公司返佣设置比例；
(2)计算产品成人价的原始毛利率；计算公式：成人价原始毛利率＝(驴妈妈成人价销售价-驴妈妈成人价结算价)/驴妈妈成人价销售价；
(3)对比成人价原始毛利率和成人价保底毛利率的大小：
case1：成人价原始毛利率<成人价保底毛利率时；
1.1step1：使用成人价保底毛利率计算保底毛利；计算公式：成人价保底毛利＝驴妈妈成人价销售价*保底毛利率；
1.2step2：使用保底毛利计算子公司返佣价格，后续我们对该值定义为保底毛利率返佣价格；
计算公式：子公司保底毛利率返佣价格金额＝保底毛利*子公司返佣设置比例；
1.3step3：使用子公司保底毛利率返佣价格金额，对比保底返佣价格；
case1：子公司保底毛利率返佣价格金额<保底返佣价格；使用保底返佣价格；case2：子公司保底毛利率返佣价格金额>保底返佣价格；使用子公司保底毛利率返佣价格金额；
case2：原始毛利率>保底毛利率时；使用原始返佣价格，对比保底返佣价格；
case1：原始返佣价格<保底返佣价格；使用保底返佣价格；
case2：原始返佣价格>保底返佣价格；使用原始返佣价格；
(4)一旦使用保底毛利率返佣价格或保底返佣价格；分社、门店的返佣价格同子公司返佣价格；不再使用之前的层级返佣比例计算；
(5)当儿童价或其他附加类商品出现零负毛利时，返佣价格为0，不为负值；
(6)订单总返佣价格＝成人价返佣价格单价*人数+儿童价返佣价格单价*人数+附加类商品返佣价格单价*人数；
4、代码实现思路：
1.入参要求传入当前登录用户的归属层级信息(如：：归属门店、归属分社子公司信息等)、用户是否为旅游顾问、需要计算产品的价格信息、品类信息，以及当前调用场景等
2.循环处理传入需要计算的返佣价格数据，判断不同品类，调用不同的模板方法，在模板方法内对该模板要求数据进行校验，校验通过后获取该品类配置每一层级的原始返佣价格和保底返佣价格信息，对满足计算要求的价格类型(成人价，儿童价等)循环计算该对象的每一个价格的返佣价格信息(主要考虑不同价格的返佣价格政策不同)，分别计算出保底返佣价格和原始返佣价格进行对比，采用返佣价格计算值最高的计算方法
3.根据不同使用场景判断是否返回所有层级返佣价格信息还是返回该用户当前所属返佣价格信息
驴妈妈店店赢app通过客户端http发送登录请求，发送请求到接口，接口通过dubbo远程调用数据层登录的方法，返回登录的json实体对象，通过客户端接受到的对象来传递参数访问返佣价格接口，接口获取到参数通过dubbo远程调用数据层获取返佣价格的方法获取返佣价格的对象集合转化为json数据给app端用于展示。
返佣价格从接口的调取的具体实现：
a、驴妈妈店店赢app支持不同角色用户的登录，不同用户登录展示不同的返佣价格，客户端通过发送http登录请求传入用户名、密码通过rsa的公钥加密方法传递给接口，接口获取到参数之后通过rsa的私密进行解析，将解析之后的用户名和密码封装成登录用户的对象通过dubbo远程调用数据层的方法，获取到登录实体对象、使用redis缓存技术通过key-value的存储方式来存放用户的层级。将登录的实体对象转换为json的数据格式返回给客户端。
b、在访问返佣价格的接口的时候，使用redis的键来取出所属用户的角色，在程序代码中通过配置dubbo.properties来配置dubbo的注册者地址和服务调用者的地址。
再通过配置文件spring-dubbo-consumer.xml来配置服务远程调用的接口地址和本地调用的接口名称。
来调用dubbo的远程接口的方法通过传入的角色信息来得到不懂层级的返佣价格的返佣价格对象，通过转化为json的形式返回给客户端展示。
Android的实现
本APP是面向驴妈妈门店人员进行对客推广和及时数据统计而开发的,所以针对对客解释和自留统计之间切换的场景进行分类显示。在对客上是常态,在自留统计上要保持隐蔽,因此针对这个需求,我们选择了这种不明显的触碰长按来实现这个”隐蔽”的功能。
要实现的是通过长按Action Bar的区域来控制报价后隐藏积分的展示,还要在触控的时候还要不影响其他ScrollView的滑动或者ViewPager的切换,我们的第一方案是在通过对OnLongClick()和OnTouch()中的ACTION_UP事件监控,因为长按事件可以触发显示,但并没有对应的长按抬起监听,所以我们通过对OnTouch()中的ACTION_UP进行判断,用在OnLongClick()事件中进行Tag标记,以此作为前置事件的判断,用以区分前置事件是LongClick或者ShortClick。为了防止影响ScrollView或者ViewPager的touch事件,我们一律处理但不拦截,所以在这两个事件的返回中我们返回false,于是我们把这个这个ActionBar从新自定义,并加入监听,暴露出来了长按,和长按释放的接口方法.这样貌似是解决了基本的需求。
但是不难发现，对于整个fragment的onTouch()事件没有做更好的处理,比如这样的一个场景,我在触发这个TopBar的长按后,Page1显示,如果在ViewPager切换,在另外Page2抬起,前者的显示效果在切回后并不会隐藏,由于在Fragment切换时,Page1并不会监听到Page2中的变化,当然也跟Viewpage设置加载项有关,我们需要在ViewPager的setCurrentItem()中对Tag进行设置,确保切换时积分全部隐藏,或者使用Static变量(当然这个是极不推荐的)进行处理,这些处理都是手动控制逻辑，在事件分发和处理上必须在二级封装中进行完善。而且功能单一，外大里小，需要在下级代码逻辑中处理分发逻辑。总体来说，第一级封装不够完善，只是“按需添加”，要随时跟进变动去更改分发逻辑和实际场景应用，在冲突中也是各个模块处理。对于这个问题，需要对onTouch()和click()进行更充分的处理。于是考虑到多种情景下的引用,(包括搜索,详情,主页)都有这个需求,加上一些其他点击事件,比如多触控下造成的多点击事件响应，加入了GestureDetector手势监听类对MotionEvent的动作进行处理，点开GestureDetector的源码,在GestureDetector的众多手势监听方法中有这么一个方法。
并且在ACTION_DOWN中进行了判断处理,onLongPress在ACTION_DOWN时发生，handled变量记录onTouch事件中的处理结果,用handler移除发送保证了消息的传递唯一性,onLongPress发生后在up之前不会用其他事件触发，可以在onShowPress处理状态的改变，比如按钮的按下状态。
了解了GestureDetector,我们对Topbar进行统一的封装处理,实现GestureDetector中的SimpleOnGestureListener接口并重写onLingPress方法,再对onTouchEvent的ACTION_UP事件暴露出来,即可轻松实现不被各种点击冲突打扰的长按监听。
在返佣价格数据调取方面,我们使用的Todo-MVP+状态设计模式,在契约接口Contract内对View,Present,Model进行v-p,p-m的双向绑定,并在P层根据返佣价格显示与否的权限控制是否开启显示功能。
iOS的实现
1、为了使app代码有较好的复用性，我们需要把这部分代码单独封装起来，以方便在各个有需要的地方调用；
2、需要长按手势支持，这个iOS的SDK已经给予了很好的支持，我们只需要调用系统的方法即可；
3、需要提示弹框来展示无返佣价格提示文字，这个我们可以采用我们iOS团队已经封装好的提示弹框。
根据分析，再结合iOS框架的特性，我们最终准备采用的方案可以分为以下几个步骤：
1、iOS应用的界面切换，基本上都是通过UINavigationController来完成的，我们的应用也不例外；根据需求，要求点击当前页面的标题，来响应长按手势。由于UINavigationController属于容器类，我们所有的页面标题基本上都在UINavigationController的NavigationBar上，所以我们把长按手势加到NavigationBar上，然后给NavigationBar添加一个代理，写一套代理方法，这样就可以做到让各个需要实现返佣价格展示操作的类去自己实现代理方法，完成相应的操作。
2、返佣价格数据都是从后台接口取到的，返佣价格数据都是从属于商品的，不同的商品，返佣价格数据是不一样的，这样的话，所有返回有商品信息的接口，需要展示返佣价格的，都需要在这些接口里面，把返佣价格数据返回回来；我们从服务器获取数据，是通过我们自己基于AFNetWorking封装的网络库，LvmmNetwork来完成的。
3、为了实现长按返佣价格展示，手指离开消失，我们需要在各个需要展示返佣价格的页面实现第一步给NavigationBar添加的代理，然后通过判断手势响应状态，在状态为开始长按的时候，刷新界面，展示返佣价格，如果没有返佣价格，就会以弹框的形式告知用户，当前页面无返佣价格，当状态变为长按结束的时候，再次刷新界面，隐藏返佣价格的展示。