Weex线上踩坑实录

关于weex的基础集成网上有不少博客，我就不重点介绍，今天主要分享一下weex文档中并无的，在实际项目集成中的碰到的注意点和坑。满满的经验和干货，但愿能对你们有所帮助。

1.如何集成到fragment中

集成到fragment的状况仍是很广泛的，由于如今不少app都是采用activity内嵌fragment的开发方式，把实际功能都放到fragment中。再好比在tab上通常是tablayout(bottomNavigationView)+fragment的布局，tab上内容也须要使用weex来开发。

在weex文档中只说明了怎么集成到activity中，网上也有不少人在问如何将weex集成到fragment。其实答案很简单，weex渲染出来的内容其实只是在一个控件中，因此只须要和普通的fragment开发同样，将weex sdk嵌入便可。根据weex官方描述，在回调IWXRenderListener的onViewCreated返回建立的view。因此咱们只须要让fragment实现IWXRenderListener，而后在onViewCreated中将渲染出来的view添加到整个视图容器中便可。

最后提一点优化，除了考虑到weex使用到fragment中，固然也要考虑到有些页面不是内嵌fragment的状况。这里能够不用从新写一套weex sdk的集成，直接让activity使用已经集成了weex的fragment便可。

2.加载方式选择

在weex文档中提供了2种经常使用的加载js方式，本地加载和远程加载。笔者在weex开发者大会上问过手淘官方的人员，他们表示手淘首页入口9成都是weex的页面，而且这2中加载方式都有用到，根据实际业务团队本身来灵活选择。

咱们是使用的打开app或者先后台切换时下载js，而后直接加载本地js的方式。该方式因为不用每次从网上下载，因此加载效率会高一些，可是也有缺点，就是每次线上发布之后须要一段时间用户才能下载到代码并生效，并不能及时的达到更新效果。

注意：不要采用在上一个页面点击时去判断本地js版本，而后下载运行的方式。该方式看起来很美好，又能实时更新效率又高，可是其实并否则。问题在于该方式须要去请求服务器获取js更新状态，万一网络差的时候就一直不会初始化容器，此时用户点击屡次就会打开多个页面，很是的不友好，并且会给服务器带来无所谓的压力。

3.不一样的业务模块中如何进行业务交互

weex和rn不同，在rn中全部的业务默认都是放到一个模块中的，因此rn帮咱们处理了通讯这一块内容。可是weex不同，weex中不一样业务是不一样的js文件，致使通讯困难。

网上有说使用storage的方式，可是这个方式其实不太好，通过和前端协商，咱们决定本身写一套业务模块中通讯方式。咱们自定义了一个仓库类，提供set方法保存业务模块通讯中要传的值的key和value，前端调用set方法能够将值保存到客户端，而后加载B模块时由咱们客户端将值给B模块，也就是经过fireGlobalEventCallback推送给前端使用。

4.如何构造一个前端调用体系

这里的前端调用体系是指在vue代码中调用到客户端的方法，包括自定义控件、客户端功能等。官方告诉咱们是经过JScallback的方式，可是咱们总不能在客户端写不少个方法一一对应吧，这里咱们写的比较简单，让前端传入一个约定好的伪协议过来，其中包括须要调用的方法、传的参数等内容，接下来在客户端中解析该协议对应到实际的方法。固然这里其实能够考虑用设计模式优化一下，面向修改关闭，会更加符合solid原则。

5.关于网络框架、图片框架

weex的sample中是使用最简单的httpurlconnection来请求数据，可是这个是没有任何优化的基础访问。可是也提供给了咱们自行修改的方式，那就是setHttpAdapter()，经过该方法可使用适合本身公司的网络框架，好比OkHttp、Retrofit等等，weex官方也是建议修改一下网络框架，可以提升访问效率。

weex并无提供图片加载的方式，用官方的解释来讲就是你们的方式都不同，加进去会让sdk很臃肿，并且不必定能符合各个公司的实际业务场景。因此weex官方只提供了一个setImageAdapter()来让咱们自定义适合本身的图片框架，咱们必须实现IWXImgLoaderAdapter，否则图片是没办法加载出来的。

注意：图片加载框架须要考虑到gif等其余格式，作好兼容性测试，咱们当时ios就出现过问题。

6.关于降级措施

因为咱们是使用先下载到本地，而后加载本地js的方式，因此不能避免的一个问题是在打开weex页面的时候实际的业务代码还没下载。针对这种状况，咱们使用了降级策略，在打开weex页面以前首先判断一下本地是否有该业务代码，若是没有就打开入口上已配置的h5连接

7.有关打点方面

这里只分享客户端这边的打点，咱们在下载js的流程中都有好几个打点，分别是下载成功（失败及缘由）、解压成功（失败及缘由）、增量更新成功（失败及缘由），除此以外，还有进入weex页面信息、weex渲染成功与否、是否进入降级以及降级缘由等基本打点。

8.其余weex文档没有说起的要点

weex文档很不全面，致使实际运用到项目中的时候坑点多多，weex上线之后最初基本每一个版本都要上一些代码去填坑。固然weex官方是提早知道这些的，只是没有及时分享出来而已。举几个例子，好比ua、cookie等的支持都须要客户端进行支持。

ua：weex sdk中有带一个默认ua，但那确定不是咱们想要的，通常服务端须要的是带app信息的ua。

cookie：cookie的话是在请求时须要带上的，因此咱们须要让weex的网络请求框架带上。这些在第一次上线时不必定能考虑到，可是客户端发版问题一直都是老大难，这里分享出来但愿能对你们有所帮助。除此以外，咱们须要赋予前端保存和修改cookie的能力，因此咱们在客户端提供好了相关的set和get方法。

9.线上已知weex的未解决bug

咱们上线以来碰到了不少的问题，其中大部分weex团队获得了解决，笔者在此对weex团队表示感谢，好比只支持aremabi，致使和项目中其余功能冲突的问题、还有线上崩溃也愈来愈少，说明weex已经逐步愈来愈成熟。可是不能否认的是，目前weex仍然有一些问题，好比weex sdk中有framework层初始化失败的问题，发生的几率大概在千分之三左右，weex官方的建议是这个问题没法在sdk中修复，须要本身去判断是否初始化，万一没有初始化便进入降级策略，他们在最新的weex sdk中是已提供了是否初始化的接口的。还有一个线上已知问题是部分三星手机上会crash问题，该问题只出如今三星手机上，目前weex官方没有获得解决。另外，weex对recyclerview的支持不是很好，致使有些列表的效果实现不了，相信这个在之后应该会解决。另外还有些莫名其妙的问题，不知道该怎么说，也不是很重要，这里就不一一描述了，不过相信weex的逐步成熟，这些问题都会迎刃而解的。

10.其余建议

因为weex目前自己就不大稳定，加上第一次使用，避免不了会碰到不少的坑，因此可使用灰度发布的方式，根据设备号或者id分流只发布一部分的用户使用weex页面，这样万一出现问题影响范围较小，若是一段时间之后没问题再大批量上线。集成weex的客户端开发人员也要学习一下vue，这样本身就能够测试weex的集成代码，提高和前端人员的沟通效率。多关注weex的社区以及github、jira、钉钉群等weex官方平台，有问题能够在里面提issue，笔者亲自体验仍是会回复的，包括如今weex官方已经提供了一个专用weex讨论群，有阿里人员在里面解答问题。有空能够研究一下weex底层的代码和核心原理，提高技术的深度和看源码的能力。

最后：以上经验都是笔者做为在线上项目中实际使用过weex，而后分享的在使用过程当中的感觉。绝对不是网上随便搬抄的，但愿能对你们实际应用weex到项目中有所帮助。也欢迎使用过weex的同窗探讨相关的技术，一块儿进步。