平常在使用应用的过程中，用大拇指左右滑动时，有时候并没有实现左右滑动，而是上下滑动。次数多了之后，逐渐发现，有些应用，只有在手指严格横向移动时，才能实现左右滑动，否则，统一视为上下滑动。
这可能和用户想要的效果不一样。当手指斜向下移动时，虽然有上下移动的分量，但可能用户想要的只是左右滑动。
具体看一下用户从左右滑动的想法到执行左右滑动动作的过程。
以左手大拇指的右滑为例。当用户想要右滑，由于大拇指的关节、肌肉结构的原因，最自然、最不费力的滑动时，手指的移动轨迹是这样的。
因为大拇指并不是在一个横向轨道上做平移运动，而是由多项运动组合而成，包括大拇指两个关节的伸展运动、绕大拇指根部关节的圆弧运动等。这个圆弧运动，除了产生横向移动分量外，还会附带产生纵向移动分量。横向移动是用户想要的效果，纵向移动是用户不想要但由于关节结构附带产生的。正确的做法应该是，识别用户想要的效果，剔除掉用户不想要的效果，即不随用户手指的纵向移动而实际产生纵向移动。但实际情况是，在一些应用中，却十分“灵敏”的捕捉到了手指的纵向移动，甚至在横向和纵向产生冲突时，优先满足纵向移动。
总而言之，由于手指结构的原因，用户通过指尖移动来表达横向移动需求时，“表达”出来的信息有偏差（想要表达横向移动的需求，但却同时表达出了纵向移动的需求）；App在理解用户表达的信息时，不够智能，没有智能地识别出用户想要表达的信息，甚至把用户的附加信息（纵向移动）当做主要信息。
确定了问题之后，接下来只要建立横向移动需求和手指移动轨迹的对应关系，然后根据对应关系，还原出横向移动需求，然后根据还原出的需求执行对应的动作即可。
需要注意的是，在追求横向移动的效果时，还要注意不要影响纵向移动的效果。再来看一下，当用户想要纵向移动时，在轻松自然、不费力的滑动时，手指的移动轨迹。以左手为例。
当用户想要纵向移动时，手指可以轻松做到对纵向线的较好逼近，由大拇指根部关节旋转带来的圆弧运动影响较小。
综合用户对横向移动和纵向移动的表达（指尖移动轨迹）可以看到，横向移动和纵向移动的轨迹基本没有重叠，即我们对横向移动效果的优化，不会影响到纵向移动的效果。
一种供考虑的做法是，将和水平线成一定角度的斜向下的滑动，也认定是横向滑动。即，把横向滑动的角度范围，根据实际轨迹，调得大一些。注意，并不是在整个滑动轨迹中检测，而是检测起始滑动阶段的角度。当认定为横向滑动后，即使后面有很大的纵向移动，也忽略其纵向需求，只读取其横向移动的距离。
再加上右手大拇指的使用情况，可以对称地增加角度范围。
还有一个类似的问题是右滑返回。为了避免和在界面中的上下滑动产生冲突，通常设定为，只有当滑动起始位置在左边缘时，才会去检测是否是右滑返回。这没有什么问题，比较自然。
但有些App，在滑动起始区域是左边缘位置外，还增加检测了起始滑动方向是否严格的逼近横向。在上面的分析中，可以看到，自然的不费力的右滑轨迹是斜向下方向的。在这种严格逼近横向的设定中，就会将这种斜向下的滑动轨迹排除在右滑返回的动作之外。同样是没有智能识别出用户的需求。这么做是出于什么考虑？是为了防止误操作？防止到用户想要上下滑动时，App的响应却是右滑返回？
用户在上下滑动时，通常的操作区域是页面中间区域，在边缘的操作频次很低。因为这频次很低的上下滑动操作，去影响右滑返回的体验，显然是得不偿失的。
所以不妨将左边缘的区域，设定为右滑返回操作区域，在此区域，不考虑上下滑动，只看横向移动的分量。这样可以极大提高右滑返回的成功率。
还有一种情况是，当上下翻动页面，手指离开页面后，页面由于惯性，还在移动，此时右滑返回，很多App的做法也是不识别这种右滑返回的操作，只有在页面完全停止移动后，才开始检测右滑返回的需求。要判断应该怎么做，只需要搞清楚两点：
在界面上下滑动、还没有停止时，用户右滑的实际需求是什么？
当满足了用户的上述需求后，会不会对其他功能产生负面影响，比如上下滑动？
1，绝大多数情况下，都是用户都是想要右滑返回，误操作的概率较低。
2，上下滑动的操作区域主要在页面中间区域，在左边缘的右滑返回对上下滑动功能影响很小。
结论自然出来了，在页面上下移动时，接收用户的右滑操作。
待完善部分
1，加入对已养成严格逼近横向线习惯的情况、两只手操作的情况
ps：简书的编辑器里不能改变图片大小吗？
