跨页面消息通知机制
大多数的应用都会在一个weex容器中进行页面跳转，这种场景下使用navigator就能比较好地实现（页面切换）。但是在实际混合开发场景中，会碰到更为复杂的跳转逻辑，如原生页面A跳转Weex页面，再从B跳转远程页面C，继而再从C跳转Weex页面D……再加上还会有跳转H5页面等等，这样对于后退栈的管理就会比较复杂。目前我们采用的解决方案是：为每一个weex页面单独使用一个容器（对于H5也是一样），这样页面的跳转就能交给原生系统的后退栈来管理。当然这么做也会有性能开销，但是综合来说，这种场景不多，因此从性价比考虑这么做是目前最合适的。
然而这么做又会来带新的问题，那就是weex所提供的消息机制只能是在单容器内使用，按照官方的说法即这是一个实例级别的事件而不是应用级别的。那么就需要我们自己来做一套消息通知机制供应用级别使用，来解决多weex容器实例以及连通weex、native以及H5。其实这套机制并不复杂，因为原生已经有很多消息机制可以供我们选择了，包括EventBus、LocalBroadcast等等。这里可以详见我的之前有关消息机制实现的文章（传送门：https://www.jianshu.com/p/774b77ddde52）
View级别的应用
之前说到大多数的weex使用场景是单容器（或者说是单实例）的，因此一般的实现也都是在一个Activity中（以安卓为例，下同）只有一个WXSDKInstance。然后有时候需求就是这么坑爹，在某些原生页面中希望可以内嵌一个甚至多个Weex的容器，那么这时候用来实现Weex容器的就不能再是Activity而是View了。我们需要自定义一个View来实现IWXRenderListener接口，并且在该View内部来维护一个WXSDKInstance，虽然初始化WXSDKInstance时候传入的Context还是Activity，但是好在instanceId是自增的，因此在一个Activity中有多个Weex的View，它们还是可以通过id来区分的。另外在使用View做容器的时候，也需要自己hook Activity的生命周期，来与WXSDKInstance中相应的方法绑定，不然在自定义Module等应用场景中将无法正确拿到Activity的生命周期回调。
复用供H5使用的Bridge能力
想必很多团队在接触或者决定使用weex的时候，所在的项目已经是开发甚至是上线一段时间了，并且大多项目一定会用到WebView承载的H5页面，那么在开发H5相关页面时自然而然会定义很多通用的Bridge能力，比如账号登录机制、通用的loading组件、网络请求代理等等。然而我们在开发weex页面时候则不希望再重复实现这套Bridge，因此我们就需要实现一个适配器，通俗地说就是通过定义一个weex的Module去实例化H5的Bridge并且调用实例的方法。这套机制核心需要关注的是H5的Bridge需要怎么样的环境，我们通过哪种方法来实例化H5的Bridge（大多数情况下会需要用到反射）。此外，这种做法由于无法完全在weex容器中还原一个H5的环境，因此也并不是能100%复用H5的Bridge能力，对于无法复用的，我们还是需要基于weex重新开发一套。
自定义组件扩展
在深度使用weex的时候，weex官方提供的组件会逐渐变得无法满足当前需求，这时就需要我们来做一些自定义的组件。当然这块并不需要用到什么黑科技，weex官方就提供了这类扩展，也就是WXComponent以及WXVContainer。常规的独立组件继承WXComponent即可，类似写一个原生的自定义View，具体的属性以及方法定义也可以参考官方文档（http://weex.apache.org/cn/guide/extend-android.html）。对于View的容器组件则需要继承WXVContainer，然后你就可以自定义各种cell，并且通过addSubView方法拿到加进去的cell。
调试工具
weex官方提供了playground app，帮助你在设备上调试。但对于依赖自己项目环境的功能，就必须在项目内提供一个调试工具了，核心类似playground app，即提供一个扫码功能，能进入weex页面进行调试，对于调试这块功能，我会在后续的文章中详细讲解。
与小程序打通
小程序平台现在已经成为一款应用不可或缺的阵地，因此跨端方案自然不能少了小程序这个平台。目前核心做法还是依赖于babel，并且需要在小程序端预先实现一套相对应的组件。详细的内容也将在后续文章中详细展开。
数据统计
跨端方案既然是以提高效率为目的，那么自然需要有足够的数据来做支撑，因此我们需要在weex的几个生命周期内做好埋点，来统计各种耗时。另外在业务上也会有数据需求，一般也是通过埋点的形式来做统计
小结
多端融合一定是未来移动端开发的一个方向，它除了解决一部分体验问题之外还能提高人效，因此未来各大企业也会越来越多地依赖这项技术。至于具体的方案选型，诸如weex、rn或者flutter，还是需要根据具体的业务场景来选择，目前并没有完美的方案，当然基于这些开源方案来二次开发，从而补足这些方案存在的不足则是更好的了。
对于我个人而言，自身的技术规划加上公司业务需求，有幸在这个时间点能学习到前端知识并且落地这套方案。因此我打算开一个文章系列，记录一下这套方案不断演进过程中的点点滴滴。
这段时间经历了很多事情，说是一夜长大也不为过吧。但是没有时间再自怨自艾了，找对方向，就算再难受爬着也要向前。失去的东西总会回到我们身边，虽然有时并不是以我们希望的方式。
网友评论