像投奔移动互联网一样投奔大前端

作者: 六彩开奖结果直播  发布:2019-12-22

原标题:Taro、Weex、Hippy 齐聚 IMWebConf 2018!

大前端一定是可以预见到的未来的趋势之一(我能怎么办呢)

1、Native与Web之争的融合

在客户端开发,不管是PC还是移动端,Native与Web之争持续了近十年。二者的优劣也很明显:

  • Native开发性能更好;但不具备动态性,界面固定;
  • Web性能差;但天然支持动态变化。

一直以来,二者都想占据对方的疆界,但是从结果来看并没有谁要取代谁的势头,而是相互融合:

  • 大多数团队的移动端都会采用Native+H5的方式来做开发,重要的落地页采用Native开发,较多变化的运营页采用H5的方式实现动态变化,并且使用Hybrid来提升H5的性能。
  • 而在16年,ReactNative、Weex等跨平台技术的逐渐发酵、成熟,大家看到了Native与Web结合的新方式:写的是前端代码,运行在客户端却是Native组件,二者完美融合,做到了性能与动态性的兼得:既具备Native的高性能又具备了Web的动态性。

IMWeb Conf 2018 Native 跨端融合分会场

现在主流的ReactNative还是Weex,参考这篇还有那篇

2、崛起的大前端技术

开发中我们经常使用Json作为数据交互的格式,但只适合界面展示或者小部分的配置管理,没有办法对逻辑部分做控制,也是客户端UI固定、逻辑固定的原因之一。而Facebook推出的React则独创了Virtual DOM 机制,Virtual DOM是一个存在于内存中的 JavaScript对象,它与DOM是一一对应的关系,也就是说只要有Virtual DOM,我们就能渲染出DOM。

了解更多:《IMWeb Conf 2018 Native 跨端融合分会场》

不过最近fb的开源协议搞得沸沸扬扬,据说大公司都禁止react了,生怕出什么事。不过我觉得大公司怕是应该的嘛,地主有余粮。小公司其实无所谓,怎么方便怎么来,光脚的害怕穿鞋的吗?在我大天朝这么多人用盗版都不怕,就一个开源协议没必要(个人见解哈)

2.1 ReactNative

React 在前端取得突破性成功以后,JavaScript 布道者们开始试图一统三端。他们利用了移动平台能够运行 JavaScript 代码的能力,并且发挥了 JavaScript 不仅仅可以传递配置信息,还可以表达逻辑信息的优点。

当痛点遇上特点,两者一拍即合,于是乎:

一个基于 JavaScript,具备动态配置能力,面向前端开发者的移动端开发框架,React Native,诞生了!

背景

weex是什么?

weex是一种跨平台的开发方案,简单的说就是把iOS,Android,H5的开发合并到一起,可以写一套代码,分别运行在这3个平台,最重要的是用户体验和原生语言开发的时候基本一样。

2.2 Weex

Weex站在了ReactNative的肩膀上,借鉴了ReactNative的思路,基于Vue,并对很多开发、调试工具进行了优化补强。

这样的跨平台技术,我就问移动开发者怕了吗?

注:传统的Native开发周期较长且不具备灵活性,Android与IOS开发人员需要写两套UI及逻辑代码。而使用RN或者Weex等跨平台技术,不仅具备随时上线、更改的灵活性,还可以实现一端编写,三端运行。无论从灵活性还是节省人力成本的方面考虑,相信技术走向一定会逐渐偏向大前端。

Write once, Run anywhere. 一次编写,到处运行。

React Native App

Facebook发现Hybrid App存在很多缺陷和不足,于是发起开源的一套新的App开发方案RN。使用JSX语言写原生界面,js通过JSBridge调用原生API渲染UI交互通信。

优点:效率体验接近Native App,发布和开发成本低于Native App

缺点:学习有一定成本,且文档较少,免不了踩坑

举个栗子:Facebook、Youtube、Discord、QQ、百度等等

3、如何落地大前端

这句程序员圈子里十分著名的话,也许你早已听过。事实上,这是 JAVA 语言的 slogan,诞生于 1991 年。语言与平台,天生有着鸿沟,想要逾越,是当时美好的愿景;但如何逾越,确实是一个难题。

Weex App

阿里巴巴开发团队在RN的成功案例上,重新设计出的一套开发模式,站在了巨人肩膀上并有淘宝团队项目做养料,广受关注,2016年4月正式开源,并在v2.0版本官方支持Vue.js,与RN分庭抗礼。

优点:单页开发模式效率极高,热更新发包体积小,并且跨平台性更强

缺点:刚刚起步,文档欠缺;社区没有RN活跃,功能尚不健全,暂不适合完全使用Weex开发App

举个栗子:淘宝、天猫、阿里云、优酷、闲鱼、饿了么等

一统三端这个对我还是比较有吸引力的,rn虽然现在用的人较多,社区活跃,但毕竟是两端。之前在上一家公司有时候还是要写hybird页面,作为一个native开发者,以后用这个写单页面还是不错的哈。

下回就开始weex之旅了~~~~

3.1 像投奔移动互联网一样投奔大前端

认识到大前端的趋势,认识到形势的严峻性。技术人员的职业走向不仅仅取决于技术的深度同样也取决于技术方向,假使你很精通.net但是在国内我相信用武之地一定不会比Java大。而我在职业生涯的开端选择了当时并不火但是属于未来趋势的移动开发,做了先驱者,随着移动互联网的发酵,自己也迎来了职业生涯的甜蜜期,当大批开发人员涌入移动端开发之时,我已经是有经验的移动端开发了。

互联网的行业特点决定了知识更新比较快,某项技术可能刚成熟就会被别的技术所替代,因此开发同学在钻研那些不变的原理的同时也需要注意行业技术的变化,以免被时代所拉下。因此对移动端同学,我强烈建议想当年投奔移动互联网一样投奔大前端,未来一定时间之内的研发体系一定会围绕大前端,如果固步自封,迟早会遭遇困境。

虽然几代的程序员,前赴后继地为这个梦想而努力,但遗憾的是,到 2018 年的今天,世界上还没有一个完美的方案。反而,因为程序在不同虚拟机或系统上执行的差别,很难确保正确性和稳定性,甚至造成了一个坊间笑话:

3.2 前端基础:Html+CSS+Js

大前端技术需要前端的基础,作为移动端同学,学习前端不会是很困难的事情。不需要很精通,但是基础的语法需要懂。

Write Once, Debug Everywhere. 一次编写,到处调试。

3.3 RN Or Weex

在落地大前端技术时,选择RN还是Weex?

  • RN出自Facebook,基于React,开源较早,有一点的社区规模;
  • Weex出自阿里,基于Vue,上手简单,站在了RN的肩膀之上。

其实二者很相似,毕竟Weex是站在RN的肩膀上,而Weex更像是RN的增强版,针对使用RN过程中的问题(例如JsBundle体积、发布流程、性能等)进行了补强。

根据我自己使用Weex做开发的体验来看,上手容易,且十分顺手。基础组件、模块完善;调试、发布方便;性能监控、降级方案完善;扩展性较好。

我目前没有使用过RN,但据使用过RN的朋友说,很多组件RN做了针对Android与IOS的区分,因此很多地方仍然需要写两次代码。(如若不实,欢迎指正)

庆幸的是,玩笑的背后,我们从不缺少砥砺前行的开创者。

3.4 趟坑之路——技术组件的积累

而对于新技术,不管多么令人激动,在实际落地的时候一定会遇到各种坑。对于大前端的坑:

  • 文档相比纯Native较少,遇到问题需要去扒文档、提issue;
  • 部分自有功能Android与IOS的纯Native实现可能不一样,因而在调用的时候需要配合一致。(这个不算大前端的坑)
  • 自有技术组件的积累。

在实践一段时间之后,相信大家一定会体会到跨平台的优势以及人力成本的节省。

欢迎关注微信公众号:定期分享Java、Android干货!

图片 1

欢迎关注

最近这两年,在移动端各种跨平台的开发方案如雨后春笋般涌现,一方面是因为,随着移动互联网的普及和快速发展,移动终端设备的软硬件、操作系统、开发工具链和技术社区等日趋成熟完善;另一方面,近几年传统 PC 端的技术、资源也逐步迁移到移动端上来,大家都想造轮子,然后一统天下。 特别是今年,随着微信小程序的流行,让本来 Web、iOS、Android 的三足鼎立之势,又加入了新的玩家。如何统筹兼顾,收归开发成本,跨端技术势在必行。

所以,“跨端融合”——这是每一个追求新技术的开发者的向往,同时也是守旧者的噩梦。

即将于 10月14日在 深圳举办的 IMWeb Conf 2018 中, 《Native 跨端融合分会场》将带你领略“天下大势,分久必合”前的腥风血雨。

分享主题

本次腾讯 IMWeb 团队,邀请到了业内各大公司的著名前端布道者,围绕“跨端融合”这一主题,为您带来全新的核心理念、设计思路专场剖析。

主题有:

  • 多端统一开发框架:Taro 深度剖析 - 李伟涛(京东)
  • Hippy - 过亿量级动态运营解决方案介绍与应用 - 赵宏罡(腾讯)
  • Hippy - 终端架构设计与核心优化 - 盛波(腾讯)
  • Weex 内核的原理和演进方向 - 张翰、申远(阿里)

亲临现场,你将收获:

  • 与前端大咖面对面交流
  • 了解跨端技术的发展史和最新动态
  • 深入挖掘跨端技术的原理
  • 了解方案之间的异同
  • 认知哪种方案最适合自己业务

10月14日,我们与您不见不散!

会前问答

IMWeb Conf 2018 是诚意满满的一次前端嘉年华。

为了让大家提前感受到大会的氛围,我们准备了干货满满的分会场提前问答。

采访的对象,是分别来自阿里与腾讯的赵宏罡张翰两位前端技术专家,我们来看下他们对“跨端融合”的一些看法吧。

问题1:最近有少量国外企业在放弃 RN,重新回到 native 开发,让业界对RN的信心有所动摇,那在技术选型的时候,是否有必要继续在 RN上面投入?新项目是否依然应该选择RN?

赵宏罡:技术选型没有“银弹”。没有一种技术方案可以完美的解决所有业务场景的所有问题。在 Airbnb 这类开发资源充足,且对动态化需求并不是那么强烈的业务场景,RN 的优势并不突出。因为一些坑选择放弃 RN 可以理解。

但是对于追求更高开发效率,以及对动态化运营需求很大的业务场景。RN 依然是一个不错的选择。因为原生 Native 开发,H5 开发各自都有很大的痛点。而 RN 这类大前端框架,通过结合二者的优势真正的抹平了这些痛点。只是目前的大前端框架都还不够完善,本身又引入了一些新的坑。 但是在我们长期的实践中,发现其实很多坑都是有解决方案的。腾讯的 Hippy 框架就是站在巨人的肩膀上,不断优化,让大前端框架成为“不坑”的选择。 因为大前端方向本身很好的解决了 Naitve 和 H5 原生的问题,而它自身的问题也是可以解的,所以我们有理由相信它就是移动开发的未来。

问题2:facebook 最近在重写 RN,是否意味着当前 facebook 也意识到了 RN 的部分性能问题;未来如果 RN 新的版本出来,且明显高于一些类似的框架,在协议允许的情况下,如何可以快速切回RN?

赵宏罡:其实RN的诞生并非考虑周全的系统架构下的产物。先诞生了 Android 版,之后才有了 iOS 版,而且也不是一个团队在统一维护。所以它的一些问题是可以预见的。仔细看过 RN 的代码也会发现,有些性能瓶颈,就是底层设计不合理带来的。从一直没有1.0版本的出现,也可以看出 Facebook 显然对 RN 的现状是不满意的。想要真正被大众接受,重构势在必行。

其实也很期待RN的重构版。他们重构声明里提到对前终端通信机制的重新设计还挺令人振奋。不过他们也说明了本次重构只是在底层“大刀阔斧”,对上层API是保持了兼容的。而腾讯的 Hippy 框架,也是在上层兼容了 RN 的API。这意味着,如果你用 Hippy 构建了应用,又想要切回 RN 的时候,业务层的工作量是非常小的,几乎0成本。

问题3:JSBridge是前端和 native 进行通讯的桥梁,多次频繁的调用,会导致整个渲染和通讯效率很低,所以对于渲染和动画,常见的优化方案是降低传输字节数,降低调用的频次;那除了这些常规的手段,还有那些深入的通用优化方案,可以进一步优化整个解决方案的性能?

赵宏罡:当前的经验还有2个:

  1. 大部分 JSBridge 都是基于 JSON 来通信的。在设计协议时,应该尽量减少数据的层级。用平铺的方式是最好的。对于层级很深的情况,序列化和反序列化会更加耗时。
  2. 对于大前端框架自身而言,不一定非用 JSON。还可以设计更轻量的定制化通信协议。比如 Weex 有 wson,Hippy 有 hippy buffer。用描述式的协议设计让编解码更小更快。

还有更加面向未来的方式:

把尽量多的工作直接交由JS引擎来完成。比如 vdom 的 diff、排版,渲染计算等。在C层做更多的事情,JSBridge的负担自然就降下来了。这是也是腾讯的 Hippy 团队正在预研的方向。

问题4:很多大企业都推出了一套自己的解决方案,比如阿里的 weex,京东的 taro,腾讯有 hippy、plato,携程深度定制了 RN 等;业界有很多方案以供选择,选择困难症如何破?如果碰到不在持续维护和更新的技术方案,如何处理?

张翰:选择困难可能来自于对自身技术需求和对大厂开源框架能力没有精确的把握。解决好这两点应该就不会选择困难了。

第二个问题,如果从开源社区的角度看,任何一个开源项目的成功只依靠一家公司的力量是远远不够的,需要社区开发者和企业的共同参与才能带来持久生命力和繁荣。所以“不持续维护和更新”在我看来是个伪命题,个人更呼吁业界开发者和团队破除用户思维,真正参与到项目的建设中来,成为开源项目的贡献者,亲手赋予这个项目持久生命力,让自己的思路在开源项目里得到体现。

另外如果真的不想贡献开源又想要保证框架的稳定性和持续维护,那么也可以考虑购买大厂推出的移动研发商业服务产品(如阿里巴巴的 EMAS 产品线)。

问题5:大前端时代,无论是哪种框架;native都在和前端逐步融合。从最初的H5,到hybrid App,再到RN跨端融合,都是想让用户体验更好,所以很多组件都直接使用 native 组件进行渲染,但是又不缺失前端的灵活性;那从前端的角度来看,除了可以在构建打包,dom-diff,vdom处理外,还有哪些方面可以进一步挖掘前端的价值?

张翰:“向Native要性能”是我们持续在探索的一个重要方向,如用 binding 取代 bridge、TS 强类型等 JS 引擎层优化,vdom、dom-diff、布局能力 native 化,以及用直接绘制方式取代系统 UI 组件以增强特定场景性能表现等方案,均是可以挖掘的地方。

以上是前端专家们的部分精彩问答,如果你想了解更多问题,或者有疑问想进行面对面交流,一定不要错过参加 IMWeb Conf 2018 的机会!

参会信息

大会提供线下票和线上票两种票型。

线下票(现场)

购买现场票的观众将可以前往现场,获得与讲师近距离接触以及面对面提问的机会。购买链接:

线上票(网络直播)(

本文由今晚六会彩开奖结果发布于六彩开奖结果直播,转载请注明出处:像投奔移动互联网一样投奔大前端

关键词: