weex实现类微信图片预览需求

需求说起来很简单，就是用weex实现类似微信图片浏览，以手指中心放缩，到了边缘可以切换图片，放缩或者移动出了边界要回弹。自己最开始对weex的认识还是以展示为主，复杂交互直接交给native，如果我来评估就直接砍掉的，所以感谢宋五与仟任当时的决定，以给homeAI团队前端经验积累为理由说服了我，并且画了一张饼，说能做出来是集团第一个weex图片浏览组件，可以给集团贡献代码。

项目中遇到了很多问题：

1.手指中心点放缩：这个是最大的困难点，花了很多时间解决，最开始由于时间的问题，做出来的结果并不是以手指中心点放缩，只能说近似手指中心点，没有再仔细研究，导致后期很被动，这是第一个学到的点：产品最终上线要是一个精致的东西，不允许这种近似的事情发生。其次，最开始没搞明白最底层的原理，导致走了很多弯路，后来通了两个宵来搞底层算法，最开始通过自己的想法去实践原理，但是都还是失败了，最终解决问题的方式是通过看开源的项目，但是weex的放缩渲染机制与web不一样，没法直接用，不过提供了舍弃计算变换中心与移动中心这种坑死我的复杂关系，转而一直以中心点放缩继而移动元素的思路，有了这个参考，很快就写出了weex以手指中心点放缩的算法，没有了缩放中心的问题，到了边界碰撞判断条件也变得简单了很多。学到的第二个点：学会站在巨人的肩膀上，但也不要一开始就想着去站。

2.weex安卓渲染卡顿问题：技术调研阶段由于比较想做，简单实践了一下安卓，觉得还可以就下结论可以做，到了后面坑飞了，复杂了以后渲染效率不行了，还是因为时间原因，实在没时间再去研究原因，直接上楼去找weex团队的同事，安卓同事直接拍死了，说不用bindingx就完全做不了，js和native的通信效率再加上UI线程的更新完全没法做，bindingx不支持双指，所以需求只能砍了，这个时候再去找产品砍需求的压力，差点没跪下。。。学到的第三点：技术调研一定要完整，不要慌，避免后续坑。但是又想想如果一开始就去问weex的同学，这个需求可能就直接砍了，所以也不知道对还是不对。

3.图片放缩的时候上面的tag保持原状不放缩，最开始的想法图片放缩移动的时候不断更新tag的位置，以保证tag一直在图片上对应的 点位，这个又涉及到一堆数学计算，特别是四个不同象限的tag的计算公式不一样，当时还有三天就提测，太累了，不想算了，就先对接口，做其他交互，结果突然想到可以让tag随图片放缩，只不过在图片放缩的时候，以图片放缩的反比例更新tag的大小，这样完全省去了计算的问题，也保证了tag的大小不变，并一直在图片对应点位。学到的第四点：眼前解决不了的，可以稍微放一放，平时多做点好事，说不定就会灵感一闪。

新团队的开发流程很不规范，都是拍下上线时间，中间不管发生什么都是那个时间点上线，所以经常会碰到技术难度大，但是时间短的问题，这回也是因为时间短的原因导致最开始心态比较燥，无论是效果的精确实现，技术调研的完整性还是对底层原理的研究都做的不够好，导致后期很被动。压力越大，时间越短，心态越要平和，慢慢来才比较快。实在不行就想想我可以通宵啊，又多了8个小时，说不定再遇到个周末，又多了48个小时，这样一想心态立马能平下来，效率就高了。

这次贡献代码的期望失败了，希望后面可以更准确的把握技术，做一些能产出结果的事情，加油！！

转载于:https://juejin.im/post/5c421c82e51d457d105cfab7