技术控

    今日:91| 主题:49531
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] 客户端动态化系列之——Weex

[复制链接]
狗活于世︺ 发表于 2016-10-3 23:59:00
143 1

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
在前端越来越火的年代,逐渐衍生出类似React Native、Weex等开发套件。所达到的目的挺简单的,达到在多个平台下共用一份代码,节省开发成本,提高开发效率。其次,由于JavaScript语言的特殊性,能动态更新页面而不需要发版。基于这两点,越来越多的个人开发者&公司开始尝试它们。
  
客户端动态化系列之——Weex-1 (Android,Google,hidden,开发者,客户端)
  本文将从个人开发实践项目出发,发表一些对于Weex的看法和在项目中的实战经历。不涉及具体原理和概念性的东西,读者可以自行去Weex官网查阅。
  Weex原理

   大体上和React Native一致,都是一个“放大版”的 JSBrdige 。其核心无非就是自定义了一套DSL(.we),配合vue实现数据绑定、vdom等等功能。再通过native端与JS端的数据、API交互使得最终体现为native的调用过程。
   而在这过程中, iOS用了自带的引擎JavaScriptCore & Android则是Google V8 。在这过程中有个坑,iOS版本Weex有 内存泄漏 的情况(Android没有),原因是JS Framework(Weex JS端的主程)并没有像V8一样hidden class的行为,GC回收不是很及时。Weex开发团队的同事发现了此bug,并在后续的版本中修复。
   OK,我认为对于“应用框架者”来说,不用去care具体实现的原理。只需要了解怎么使用即可,毕竟这只是一个工具。如果是为了学习,可以去阅读,而对于“使用者”来说, 快速地入门则是王道
   而Weex的使用,对于native来说,无非就是针对具体的业务场景实现 Handler、Module、Component
  Handler

   我们可以把Weex看做是一个提供了基础套件的UI渲染库。 核心功能还是需要开发者自己来实现 ,比如:图片下载逻辑、网络请求、导航跳转等等。
  所以开发者首先要关注的就是需要静态分析自己当前工程所需的功能,看看Weex需要你实现的handler中有哪些你要用到的,并实现它们。
  比如在我的项目中,我就需要实现图片下载逻辑,于是实现并注册。
  [WXSDKEngine registerHandler:[CNCWeexImageLoaderImplement new] withProtocol:@protocol(WXImgLoaderProtocol)];
  Module

   Module可以理解为 JS端需要调用native才能处理的逻辑,并且在JS<->native进行交互 。这么说有点抽象,举个具体的例子:比如在JS端想访问native端的数据库(coredata、realm等),就需要实现一个module来满足JS调用native写好的module以实现native的逻辑。
     在我的实战项目中,我选择用module的方式实现网络请求与导航跳转。
   [WXSDKEngine registerModule:@"urlRoute" withClass:[CNCWeexURLRouteModule class]];   
   [WXSDKEngine registerModule:@"networkRequest" withClass:[CNCWeexURLRouteModule class]];    Component

   Component很好理解,要实现一个跑马灯UI的效果,在native端实现,并且注册到JS。JS端调用,即可展示出跑马灯。这就是Component, 在JS满足不了或者实现成本很高的时候,则可以在native端实现Component供JS调用 。
  由于第一次试水Weex,并没有采取很复杂的UI,就没有用Component。
  踩过的坑

   JS中this关键字的用法与Objc不同, this的作用域仅在当前对象 。而在JS中函数也算一个对象。如果在函数中套一个函数,此时用this,只能代表外层函数。而非Objc一样代表整个最外层对象,需要注意!
   业务中碰到一个场景,需要在某个场景, native端主动调用JS 。而Weex提供给外部的API并没有提供这样的能力,仅仅是在JS主动调native方法时传一个callback,并且在native方法执行完成时,callback销毁。而业务场景却需要在将来执行回传下来的callback。翻看源码,只能自己实现了。这里给个思路:
   其实在Weex的实现中(不贴源码了),会判断native实现的方法(即给JS调用的方法,比如module实现的方法)的入参类型。如果是声明成WXModuleCallback,则Weex内部会进行处理,并转成block给iOS(Android同理)。而如果不是WXModuleCallback,则会透传一个String(weex标记的方法ID)下来, 这很关键。于是我们可以投机取巧地把入参改成String,记录下这个String。在后期想调这个JS方法时,写如下代码即可
  [[WXSDKManager bridgeMgr] callBack:weexInstance.instanceId funcId:aliveCallBackID params:params keepAlive:YES];  看法

  Weex相比React Native,坑还是比较多的。但是从“使用者”角度来说,Weex方便很多。但是对于存在很多复杂业务场景的开发者来说,必然会去学习其原理,而此时Weex相比RN就没那么友善了。
  笔者因为在阿里,更加支持Weex,也希望它变得越来越好。
  无论采用哪种方式,两者都能实现客户端的动态化。而这对于一些多变的页面来说,是一种新的选择方式。
   这是客户端动态化系列的第二篇文章,读者可以看前篇 客户端动态化系列之——URLRoute ,相信你对动态化有更深的理解。
友荐云推荐




上一篇:The biggest news at Microsoft Ignite was all about Azure
下一篇:[ Laravel 5.3 文档 ] 数据库 —— 迁移
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

冯颢 发表于 2016-10-14 12:37:49
高手在民间
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表