跨端方案的三大困境( 二 ) _跨端方案

由于每个团队都看不到全景，每一个原因不那么显而易见的问题就都要一层层向下排查，甚至涉及特定业务领域能力的部分又分为许多层……
另一方面，如此繁多的层次也造成了复杂度堆积，越往下层复杂度越高，因为不确定的可变输入越多，越难弄明白来龙去脉，排查问题的成本也越高
理想情况下，按漏斗模型逐层过滤，每一层只需要检查自己的输入输出，但滞后的配套能力让表层业务难以识别出问题所在的范围，于是容器团队成为了问题流转的过滤阀，上接纷繁的 JavaScript 业务，下连复杂的特定领域能力，大量的时间耗费在了弄清楚来龙去脉上，容器能力扩展被迫降速，反复排查已知问题……
业务视角下，对业务之下的层次职责划分并不十分清楚，因此很容易找错层/人，产生无效的“重定向” 。而容器层同样也不具备全景视图，问题流转轨迹变得相当曲折，沟通成本充斥在各个环节中，制约着开发效率
三.个体困境对个体而言，面临的最大困难是跨端方案与 Web 标准存在些许差异，并且这些许差异不像 W3C 标准一样能写得清清楚楚：

Weex enables developers to use modern web development skills to build Android, IOS, and Web apps with a single codebase.

也就是说，通用的 Web 经验不完全适用，学习曲线并不十分友好，例如：

rem、媒体查询、scale/zoom等适配经验都不一定适用
减少 DOM 操作、合并 JavaScript 文件、开启硬件加速等常规优化措施也不一定能产生明显的性能优化效果
（像学习 Web 一样）只了解浏览器之上的标准能力是不够的，想要真正高效地完成业务开发工作，容器原理甚至部分实现细节都要理解

就像有 Native 背景的开发者学习TypeScript一样，初接触无师自通，熟悉的Class、Interface、静态类型用起来游刃有余……然而，熟知 TypeScript 的开发者一定知道个中细节存在着多少奇怪的地方
四.跨端的真正意义是什么？React Native 最初的出发点是：

希望 Native 开发也能像 Web 一样 Move fast
快速迭代（Rapid iteration cycle）：Web 一天两版，产品迭代周期更短
【跨端方案的三大困境】快速反馈（Immediate testing feedback）：Web 发布立即触达用户，A/B test 等实验结果立等可取，产品演进更快
快速开发（Rapid development velocity）：刷新浏览器即可生效，不必等待重新编译 App
黯羽轻扬，公众号：前端向后React Native 从诞生到现在

因此，从需求角度来看，开发效率是次要的，动态化的灵活性、快速迭代助业务先赢才是其跨端的主要意义，或者说追求的是生产效率，而不仅是开发效率，更短的迭代周期，更快速的触达用户都是直接的生产效率进步
然而，在三大困境之下，开发效率实际上也严重影响着生产效率，但还不足以抵消快速迭代、动态发布的重大进步，此消彼长也算是一种平衡，一种可接受的妥协
五.在困境中寻找生门

文章插图

理想情况下，容器应该是趋于标准化的，提供多端一致、丰富稳定的能力支持，之上的业务栈极少触及容器能力边界，从而使得容器层能够不断优化探索，更好地满足业务发展的需要
另一方面，跨端方案只是将多端不一致性带来的复杂度下沉到了容器层，独立于平台的语言环境（JavaScript 引擎、Dart 虚拟机等）能够保证上层业务逻辑的一致性，但容器层仍然需要在多端各自实现一套，如何保证容器能力的多端一致性，仍然是个大问题，也并不比非跨端方案下容易多少
因此，首先要解决容器能力丰富度的问题，将边界拓宽，从根源上减少问题。转而集中火力到真正的难题上，攻下最有价值的难点部分。同时通过虚拟架构等方式建立全职能的业务支撑团队，降低沟通成本：