做移动应用开发,12306最近修改手机号需要用户自

作者: 前端  发布:2019-11-08

前端组件化开发方案及其在React Native中的运用

2017/02/18 · 基础技术 · React, 前端, 组件化

本文作者: 伯乐在线 - ThoughtWorks 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

文/刘先宁

随着SPA,前后端分离的技术架构在业界越来越流行,前端(注:本文中的前端泛指所有的用户可接触的界面,包括桌面,移动端)需要管理的内容,承担的职责也越来越多。再加上移动互联网的火爆,及其带动的Mobile First风潮,各大公司也开始在前端投入更多的资源。

图片 1

这一切,使得业界对前端开发方案的思考上多了很多,以React框架为代表推动的组件化开发方案就是目前业界比较认可的方案,本文将和大家一起探讨一下组件化开发方案能给我们带来什么,以及如何在React Native项目的运用组件化开发方案

从“敏捷”下手

“今天,客户的UX又给我邮件了一版新的设计(PDF文件),改动不大,无非就是这个高度再调高点、那个宽度再调小些、这里用粗体、那边用18px的字体,可以参考以前做的手风琴组件的body部分,还有就是,顺便把手机版的样式截个图发过来?”

我:“能告诉我宽度和高度的具体值吗?那个手风琴组件可以在哪个页面找到?”

另一个开发告诉我:”先凭感觉做,然后再找UX面对面的按照要求一个个过。“

我:”好,面对面谈,总比邮件来回要快些。“

UX答复我:”面对面谈可能没有时间,你能先做一个粗略的版本吗?我先看看,然后给你反馈。等你做完所有的部分,我们再约个时间一起过”

即便心里在暗骂(等我做完了,你又跟我说这个不对,那个不对?)嘴上还是说了,“可以。”

然后,我问QA:“有测试环境可以部署我的新代码吗?没有完全做完,但是要给UX看效果。”

QA说:“有,但是部署完估计要1个多小时。”

我看了下时间,再过一个小时,客户UX就下班了,要得到他/她的反馈,估计得明天了!

当我把这个故事讲给别人听的时候,一般会得到两个回复:

  1. 哎呀,跟我们一样,痛苦的很
  2. 你们怎么这么不敏捷?

我无法否认这两个说法,很痛苦,也确实不够敏捷。但为我们提供了一点点线索——敏捷。

图片 2

敏捷宣言中强调:个体和互动高于流程和工具,工作的软件高于详尽的文档。

上面的故事很明显并不满足敏捷的价值观,邮件和截图绝对不可能代表“个体和互动”,一个需要部署一个小时才能看到页面效果的应用也谈不上“可工作的软件”。

在这个巨变的时代,技术选型是个很难做决定的事情,而移动应用技术领域在几个巨头(Google,Facebook,Apple etc.)的带动下更是日新月异。所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情。我也只是在移动开发上做过一点微小的工作,此处仅能抛个砖,希望各位有玉的大神尽管砸过来。

 

一、为什么要采用组件化开发方案?

在讲怎么做之前,需要先看看为什么前端要采用组件化开发方案,作为一名程序员和咨询师,我清楚地知道凡是抛开问题谈方案都是耍流氓。那么在面对随着业务规模的增加,更多的业务功能推向前端,以及随之而来的开发团队扩张时,前端开发会遇到些什么样的问题呢?

怎么破?引入“在线风格指南”

针对当前的痛点,想要破,需要做到至少下面三点:

  • 独立前端开发工作,让它与后端逻辑解耦(俗称“前后端分离”)
  • 建立“可工作的软件”来展示前端开发结果
  • 组件化的设计和开发流程

看到这三点,明白人可能会立刻联想到一个大家耳熟能详的前端开发框架:Bootstrap。没错,它作为一个优秀的前端开发框架,确实满足上面的要求,有许多不错的网站都将Bootstrap作为网站的前端骨架。

Bootstrap有两个特质非常吸引人,优秀的特性和组件和漂亮的开发文档

不过,今天我们不谈Bootstrap框架,我想来聊聊这个漂亮的开发文档,俗称“在线风格指南”。

相信大家对“风格指南”都不陌生,主要分两类:静态风格指南和动态风格指南。

静态风格指南也就是我们常见的静态设计文档,比如,由设计师提供的PSD/PDF等文件,文档中包含:调色板,字体,按钮,链接等等。

图片 3

(medialoot上的一个样例)

动态风格指南,也称为Living Style Guide(“活的”风格指南或者在线风格指南),它是一个包含风格指南的Web站点,就像Bootstrap开发文档一样。

图片 4

在这里,我们需要引入的是“在线风格指南”,而不是Bootstrap,这里的不同点在于:

  • 角色变化,我们从“风格指南”的使用者,变成了是它的拥有者、开发者和使用者。
  • 用户变化,它不再是开发文档,现在用户是UX、前端开发和BA(业务分析),在UX和BA的眼中看到的文档即最新实现结果,在前端开发眼中看到的代码即设计。
  • 侧重不同,不仅仅是基础组件,也具有更加偏业务的大型组件。

做移动应用开发,说起来技术方案不外乎HTML5(没错,做Mobile Web其实也算是一种移动应用)、Native(在Android上不管是用Java、Kotlin还是Scala,iOS上不管是用Objective-C还是Swift)和使用原生UI,用JavaScript来实现逻辑的诸如React Native一类的方案。除此之外,还有结合HTML5和Native的Hybird混合方案。不同的技术方案有着不同的适应场景,至于具体如何选择,接下来我简单地谈谈自己的理解。

目录(?)[-]

1. 前端开发面临的问题

  1. 资源冗余:页面变得越来越多,页面的交互变得越来越复杂。在这种情况下,有些团队成员会根据功能写自己的CSS、JS,这会产生大量的新的CSS或JS文件,而这些文件中可能出现大量的重复逻辑;有些团队成员则会重用别人的逻辑,但是由于逻辑拆分的粒度差异,可能会为了依赖某个JS中的一个函数,需要加载整个模块,或者为了使用某个CSS中的部分样式依赖整个CSS文件,这导致了大量的资源冗余。
  2. 依赖关系不直观:当修改一个JS函数,或者某个CSS属性时,很多时候只能靠人力全局搜索来判断影响范围,这种做法不但慢,而且很容易出错。
  3. 项目的灵活性和可维护性差:因为项目中的交叉依赖太多,当出现技术方案变化时,无法做到渐进式的、有节奏地替换掉老的代码,只能一次性替换掉所有老代码,这极大地提升了技术方案升级的成本和风险。
  4. 新人进组上手难度大:新人进入项目后,需要了解整个项目的背景、技术栈等,才能或者说才敢开始工作。这在小项目中也许不是问题,但是在大型项目中,尤其是人员流动比较频繁的项目,则会对项目进度产生非常大的影响。
  5. 团队协同度不高:用户流程上页面间的依赖(比方说一个页面强依赖前一个页面的工作结果),以及技术方案上的一些相互依赖(比方说某个文件只能由某个团队修改)会导致无法发挥一个团队的全部效能,部分成员会出现等待空窗期,浪费团队效率。
  6. 测试难度大:整个项目中的逻辑拆分不清晰,过多且杂乱的相互依赖都显著拉升了自动化测试的难度。
  7. 沟通反馈慢:业务的要求,UX的设计都需要等到开发人员写完代码,整个项目编译部署后才能看到实际的效果,这个反馈周期太长,并且未来的任何一个小修改又需要重复这一整个流程。

为什么还要组件化的设计和开发?

组件化的做法在当前的场景下,似乎有点顺其自然,特别是有Bootstrap作为前车之鉴。

我想大家都知道,前端开发其实有一个通病,即大量的JS、CSS和其他资源文件(字体文件、图标、图片),在没有很好的管理控制下,很容易导致资源的冗余,依赖关系复杂度增加、维护性降低、导致之后的开发难度变大。

和后端语言开发不同,比如,Java有包管理和类的支持,有一些常见(或者约定俗成)的实现层次,如:Controller、Service、Repository等;有框架和语言特性带来的优势,比如IOC、AOP、注解、继承、接口等,合理利用能够让代码职责单一,模块高内聚低耦合,接口化,可重用,易于测试等等。

而Web前端开发,由于涉及到的内容较广,又不太可能完全具备后端语言的优秀特性。所以,更加需要开发人员具有优秀的设计和管理思想,比如:CSS的合理命名和管理、有效利用CSS预处理器、JavaScript的模块化、框架的特性(比如AngularJS的依赖注入,指令)、以及组件化等等。

组件化其实是大型软件开发中的一个共识,特别是前端,在没有统一标准的前提下,大家都在不断的造轮子,有无数的人倒了下去,又有无数勇士踩着前者的尸体冲上来。也许是因为它确实能够具有一些非常优秀的特性:单一的职责、资源的高内聚、独立的作用域、可独立的测试、接口的规范化、可重用、可组合等。

图片 5

1、HTML5

也就是Web App的方案。这种方案最大的优点在于“Write Once, Run Everywhere”,不管你是Android还是iOS,都可以用一套代码搞定,在国内的话还能对接微信公众号,给用户提供一个方便快捷的入口,并且还有版本升级容易的优势(毕竟服务器是受自己控制的)。但是这种方案的缺点也很明显——无法使用系统级API,只能做为一个临时的入口,用户很难留存,并且因为浏览器性能的原因,很难带来很好的用户体验。

所以说Web App的主要适用场景还是在于作为对非核心业务在移动端的入口补足,或者是作为用户轻量、低频使用的体验增强。

图片 6

美团移动网站引导页

图片 7

美团移动网站首页

美团的移动网页就是很典型的例子,主要还是提供给不经常使用的用户一个入口,网站内部还是在尽量引导用户下载使用客户端。

一React Native的出现

2.组件化开发带来的好处

组件化开发的核心是“业务的归业务,组件的归组件”。即组件是一个个独立存在的模块,它需要具备如下的特征:

图片 8

(图片来自:

  • 职责单一而清晰:开发人员可以很容易了解该组件提供的能力。
  • 资源高内聚: 组件资源内部高内聚,组件资源完全由自身加载控制。
  • 作用域独立: 内部结构密封,不与全局或其他组件产生影响。
  • 接口规范化: 组件接口有统一规范。
  • 可相互组合: 组装整合成复杂组件,高阶组件等。
  • 独立清晰的生命周期管理:组件的加载、渲染、更新必须有清晰的、可控的路径。

而业务就是通过组合这一堆组件完成User Journey。下一节中,会详细描述采用组件化开发方案的团队是如何运作的。

在项目中分清楚组件和业务的关系,把系统的构建架构在组件化思想上可以:

  1. 降低整个系统的耦合度:在保持接口不变的情况下,我们可以把当前组件替换成不同的组件实现业务功能升级,比如把一个搜索框,换成一个日历组件。
  2. 提高可维护性:由于每个组件的职责单一,在系统中更容易被复用,所以对某个职责的修改只需要修改一处,就可获得系统的整体升级。独立的,小的组件代码的更易理解,维护起来也更容易。
  3. 降低上手难度:新成员只需要理解接口和职责即可开发组件代码,在不断的开发过程中再进一步理解和学习项目知识。另外,由于代码的影响范围仅限于组件内部,对项目的风险控制也非常有帮助,不会因为一次修改导致雪崩效应,影响整个团队的工作。
  4. 提升团队协同开发效率:通过对组件的拆分粒度控制来合理分配团队成员任务,让团队中每个人都能发挥所长,维护对应的组件,最大化团队开发效率。
  5. 便于自动化测试:由于组件除了接口外,完全是自治王国,甚至概念上,可以把组件当成一个函数,输入对应着输出,这让自动化测试变得简单。
  6. 更容易的自文档化:在组件之上,可以采用Living Style Guide的方式为项目的所有UI组件建立一个‘活’的文档,这个文档还可以成为业务,开发,UX之间的沟通桥梁。这是对‘代码即文档’的另一种诠释,巧妙的解决了程序员不爱写文档的问题。
  7. 方便调试:由于整个系统是通过组件组合起来的,在出现问题的时候,可以用排除法直接移除组件,或者根据报错的组件快速定位问题。另外,Living Style Guide除了作为沟通工具,还可以作为调试工具,帮助开发者调试UI组件。

我们项目的代码组织结构

从“风格指南”到“驱动开发”

总结一下前面的内容,“前后端分离”,“在线风格指南”,“组件化开发”,似乎我们只说到一些与开发相关的事情,其实不然。

“在线风格指南”被开发,UX、BA共享,合理的组件划分可以合理控制开发闭环,UX可以更快的看到设计实现的原型,提升团队成员沟通频率,BA可以方便的根据组件合理的编写Story(故事卡)。

当这三个角色都参与到这个过程当中时,我们就真正回到今天的正题“风格指南驱动开发”。

这是一个相当新的术语,但不是我发明的,如果要追溯的话,最早在公开场合中谈到这个概念的人应该是Nicole Sullivan,她在2014年9月的一次演讲《Components & SGDD》中提出(Nicole Sullivan目前在NPM这家公司,没错,就是那个NPM,做Product Manager & Design Manager)。

“风格指南驱动开发”尝试着:

  1. 让UX和前端开发更紧密的工作在一起,将设计与前端开发的工作闭环缩小,更快速的迭代产品原型。
  2. 将UI开发和业务系统分离开,业务系统不仅仅是指后端系统(不仅仅是前后端分离),也包括业务的Web系统。
  3. 让设计文档更加“灵活”,更加及时(up to date),更加一致(single source of truth)。
  4. 让前端资源管理更加规范,开发模式更加清晰。
  5. 让整个Web开发周期更加敏捷(Agile)。

它是一种前端开发和团队工作方式的实践。

2、Hybird

Hybird是一种兼顾Native与HTML的开发模式,但根据实现的不同,还可以再细分为两种实现方案:

  • 在Native App中使用WebView加载远端Web资源
  • 使用Cordova/PhoneGap等框架通过WebView加载本地资源进行页面渲染

第一种方案其实已经应用得非常普遍了,很多应用的展示页面都是通过这种方式实现的。因为展示页面需要的正是能够轻易更换内容及布局的格式,并且这种纯展示的页面也并不需要复杂的动画与特效,使用Web页面是一个非常合适的解决方案。

而第二种方案前一段时间非常火,因为它在跨平台,在高效开发以及快速发布上有着明显的优势,毕竟Web内容只需要开发一次就可以在各个平台使用。而且将资源打包到本地也可以在一定程度上缓解从远端加载静态资源导致UI展示延迟的问题,并且还可以通过桥接Native和Web来调用一些Device的API。但其劣势也很明显,一是通过WebView执行代码效率较低,很难实现一些炫酷的效果,并且还存在不同设备的兼容性问题;二是如果想调用相关平台的API,需要针对平台单独进行开发,如果在应用中用到了大量的Device API,那么开发的效率将大大降低;三是很难应用到平台相关的新特性,比较难做出有特色的产品。

使用HTML页面来实现纯展示页面是非常推荐的一种方案。而Cordova/PhoneGap则更适用于对Mobile预算有限的公司、创业团队,或者对App进行快速的上线验证。

正好之前有个项目就用到了这种方案,为一家业务转型的零售商提供了使用一套基本代码来完成Android和iOS两个平台的App和微信公众号的相关页面的技术方案。

图片 9

图片 10

零售商Android应用零售商微信端

二3款应用效果

二、组件化开发方案下,团队如何运作?

前面大致讲了下组件化开发可以给项目带来的好处,接下来聊一聊采用组件化开发方案的团队是应该如何运作?

在ThoughtWorks,我们把一个项目的生命周期分为如下几个阶段:

图片 11

组件化开发方案主要关注的是在迭代开发阶段的对团队效率的提升。 它主要从以下几个方面提升了开发效率:

工作流程 - 如何“驱动开发”?

图片 12

开发流程

怎么样的工作方式,才算“风格指南驱动开发”?其实,当团队拥有了“组件化的思想”和“在线风格指南”,“风格指南驱动开发”的整个过程其实是行云流水的,我简单描述一下:

1.挖掘到新的需求/特性

当新的需求出现时,UX开始进行页面设计,Living Style Guide会作为设计的参考文档。通常情况,设计师会查看已有的调色板、字体和其他基本元素或组件来组成新的页面布局。在组件化的思想和Living Style Guide的帮助下,BA和设计师都会尝试使用或者扩展现有的组件。

2.抽象成组件

一旦设计完成,BA、UX和开发会开始讨论如何把新的设计细分为独立的组件,哪些是已经存在可以重用的,哪些是新的需用新建或者扩展实现的。Living Style Guide作为桥梁帮助设计与开发进行沟通,促进双方的理解,确保实现的准确性。而抽象出来的组件,帮助BA划分任务和故事(Story),以便更加准确的估算“故事点”。

3.实现和文档化

此时,Living Style Guide是作为一个开发框架和设计试验场(playground)。

作为一个试验场(playground),允许你随时看到每一个开发出来的组件,作为开发框架,允许你快速开发,它和真正的产品实现完全隔离,这种隔离会鼓励你以更加抽象的方式创建组件,以便于让他们更容易被重用。

Living Style Guide的开发注重组件化的隔离和规范化的开发流程(套路清晰明了),我们常常会开发一些自动化的构建任务来帮助快速初始化一个组件需要的基本内容,只要开发人员对开发所需的前端技术栈有掌握,就能较快速的开发完成相应的组件。

而开发完成的组件在Living Style Guide中立刻变成“活的文档”,可以快速展示各种不同的组件应用场景,提供给UX和BA做审查(review)。

4.组件在产品应用中的热插拔

最后一步,就是将组件应用到真正的产品实现中(该产品代码应该是与Living Style Guide毫无关系的业务代码)。而对于Living Style Guide输出的结果,应该可以任意选择刚好满足需求所需要的组件,拥有足够的灵活性,才能实现它在产品应用代码中的热插拔。

如果还有第5步的话,那就是重复上面的4步,这就是“风格指南驱动开发”的完整流程。

3、React Native

把React Native单独拿出来,是因为确实不能简单的将它分到其它任意一种方案里面去。React Native确实是最近最火的跨平台App解决方案了。它脱胎于React,因为React基于Virtual DOM来进行界面渲染,所以用Native的View来替换掉原本React的HTML DOM就顺理成章的引出了React Native的概念。

它与之前的跨平台方案有一个本质的区别,在于:其它方案都在追求写一次code解决所有平台的问题,而React Native的理念在于“Learn Once, Write Anywhere”。虽然大部分代码是平台无关的,但是平台相关的代码都需要单独实现,这虽然对跨平台带来了不便,但是引入的好处也是显而易见的,View层的部分通过原生组件实现,性能比其他WebView的方案不知道高到哪去了。而且React Native整套的逻辑代码都通过JavaScript实现,这样就让跨平台应用能够方便的复用逻辑代码。另外虽然React Native没有支持使用CSS来实现样式,但是提供了类似CSS的样式表支持,有过UI开发经验的人都能够非常快的上手。由于前端React也是非常的火,很多React社区的很多产出都可以在React Native上借鉴使用。

React Native对于没有复杂动画效果的一般应用来说不失为一个很好的解决方案。而且对于一些小型的企业级应用也是非常适用的。但是,React Native对于Android平台的支持度是不如iOS平台的,而且现有的非常成熟的应用也较少,所以说如果要在一些面向用户量很大,讲求用户体验的App中使用还是要慎重考虑的。

但是,其实Facebook已经在自家的App上用起来了,而且实测效果还是很好的。不过呢,人家毕竟是自家维护的,所以说真正要在项目上用可能还是得试了才知道效果。

图片 13

facebook Androidfacebook iOS

三工程方案

1. 以架构层的组件复用降低工作量

在大型应用的后端开发中,为了分工、复用和可维护性,在架构层面将应用抽象为多个相对独立的模块的思想和方法都已经非常成熟和深入人心了。

但是在前端开发中,模块化的思想还是比较传统,开发者还是只有在需考虑复用时才会将某一部分做成组件,再加上当开发人员专注在不同界面开发上时,对于该界面上哪些部分可以重用缺乏关注,导致在多个界面上重复开发相同的UI功能,这不仅拉升了整个项目的工作量,还增加了项目后续的修改和维护成本。

在组件化开发方案下,团队在交付开始阶段就需要从架构层面对应用的UI进行模块化,团队会一起把需求分析阶段产生的原型中的每一个UI页面抽象为一颗组件树,UI页面自己本身上也是一个组件。如下图:

图片 14

通过上面的抽象之后,我们会发现大量的组件可以在多个UI界面上复用,而考虑到在前端项目中,构建各个UI界面占了80%以上的工作量,这样的抽象显著降低了项目的工作量,同时对后续的修改和维护也会大有裨益。

在这样的架构模式下,团队的运作方式就需要相应的发生改变:

  1. 工程化方面的支持,从目录结构的划分上对开发人员进行组件化思维的强调,区分基础组件,业务组件,页面组件的位置,职责,以及相互之间的依赖关系。
  2. 工作优先级的安排,在敏捷团队中,我们强调的是交付业务价值。而业务是由页面组件串联而成,在组件化的架构模式下,必然是先完成组件开发,再串联业务。所以在做迭代计划时,需要对团队开发组件的任务和串联业务的任务做一个清晰的优先级安排,以保证团队对业务价值的交付节奏。

留在最后的思考 - 它到底驱动了什么?

图片 15

作为好奇宝宝的你们和我,当读完这篇文章,应该仍然在思考,它到底驱动了什么?

也许你比较熟悉TDD和BDD,他们通过测试,驱动我们编写刚好满足测试和满足需求的实现,而测试反过来成为保护伞,在我们通过重构提升代码质量的同时,保证功能的安全性。

那么,“风格指南驱动开发”到底驱动了什么?也许,它驱动着我们尽最大可能去重新使用已有的组件(代码)和设计更通用的组件,也驱动着我们(开发、UX、BA)进行更加频繁的沟通,它驱动着BA(业务分析)书写更加合理的Story,也驱动开发进行更加合理的代码和资源的管理。


更多精彩洞见,请关注微信公众号:思特沃克

4、原生应用

原生应用的开发真的是让人又爱又恨。爱在于你可以在它上面施展拳脚、使用新特性、实现炫酷的效果。而恨则在于它跨平台性几乎为零,除了资源外几乎没有可重用的东西,即使是相似架构上的逻辑你也得再实现一遍。使用原生开发,能够方便地添加动画效果,调用底层硬件,所有的限制仅仅是来自平台的限制。但是正常情况下需要对不同的平台搭配不同的开发人员,而且如果要追求良好的用户体验,整个应用的设计还得满足相应平台的设计规范,这不仅是对Dev的考验,也是对UX的考验。不过如果真的对App的质量有很高的要求,我觉得这一切的付出也还是都是值得的。

如果针对的是要求硬件性能、讲究动画效果、追求用户体验的应用,还是建议分平台单独设计,并且都使用原生的技术方案来实现。其实这也是目前市面上大部分企业做出的选择。

使用原生开发我个人还有一个观点,就是设计上要尽量遵守原生应用的设计规范,如果想要一套设计通吃所有平台,最终只会搞一个不伦不类的应用出来。知乎算是国内在这方面做得比较好的应用了,也取得了不错的效果。

图片 16

知乎

其实,在真正启动项目之前,在进行技术选型时,除了要考虑更符合业务的架构外,还要考虑开发人员的能力及技术栈。毕竟最后App还是由Dev们开发的。如果仅仅考虑业务而不考虑开发人员的技术能力来选择技术方案,不仅有一种钦定的感觉,而且最后往往坑到的还是自己。

我们常说:工具是死的,人是活的。考虑多种因素,在技术选型上做出更充分的考量,才是真正正确的选择。所以说又回到那句老话上:“It depends…”

四对比分析

2.以组件的规范性保障项目设计的统一性

在前端开发中,因为CSS的灵活性,对于相同的UI要求(比如:布局上的靠右边框5个像素),就可能有上十种的CSS写法,开发人员的背景,经历的不同,很可能会选择不同的实现方法;甚至还有一些不成熟的项目,存在需求方直接给一个PDF文件的用户流程图界面,不给PSD的情况,所有的设计元素需要开发人员从图片中抓取,这更是会使得项目的样式写的五花八门。因为同样的UI设计在项目中存在多种写法,会导致很多问题,第一就是设计上可能存在不一致的情况;第二是UI设计发生修改时,出现需要多种修改方案的成本,甚至出现漏改某个样式导致bug的问题。

在组件化开发方案下,项目设计的统一性被上拉到组件层,由组件的统一性来保障。其实本来所有的业务UI设计就是组件为单位的,设计师不会说我要“黄色”,他们说得是我要“黄色的按钮……”。是开发者在实现过程中把UI设计下放到CSS样式上的,相比一个个,一组组的CSS属性,组件的整体性和可理解性都会更高。再加上组件的资源高内聚特性,在组件上对样式进行调整也会变得容易,其影响范围也更可控。

图片 17

在组件化开发方案下,为了保证UI设计的一致性,团队的运作需要:

  1. 定义基础设计元素,包括色号、字体、字号等,由UX决定所有的基础设计元素。
  2. 所有具体的UI组件设计必须通过这些基础设计元素组合而成,如果当前的基础设计元素不能满足需求,则需要和UX一起讨论增加基础设计元素。
  3. UI组件的验收需要UX参与。
  1. 开发方式
  2. 性能 体验
  3. 更新 维护

3. 以组件的独立性和自治性提升团队协同效率

在前端开发时,存在一个典型的场景就是某个功能界面,距离启动界面有多个层级,按照传统开发方式,需要按照页面一页一页的开发,当前一个页面开发未完成时,无法开始下一个页面的开发,导致团队工作的并发度不够。另外,在团队中,开发人员的能力各有所长,而页面依赖降低了整个项目在任务安排上的灵活性,让我们无法按照团队成员的经验,强项来合理安排工作。这两项对团队协同度的影响最终会拉低团队的整体效率。

在组件化开发方案下,强调业务任务和组件任务的分离和协同。组件任务具有很强的独立性和自治性,即在接口定义清楚的情况下,完全可以抛开上下文进行开发。这类任务对外无任何依赖,再加上组件的职责单一性,其功能也很容易被开发者理解。

所以在安排任务上,组件任务可以非常灵活。而业务任务只需关注自己依赖的组件是否已经完成,一旦完成就马上进入Ready For Dev状态,以最高优先级等待下一位开发人员选取。

图片 18

在组件化开发方案下,为了提升团队协同效率,团队的运作需要:

  1. 把业务任务和组件任务拆开,组件的归组件,业务的归业务。
  2. 使用Jira,Mingle等团队管理工具管理好业务任务对组件任务的依赖,让团队可以容易地了解到每个业务价值的实现需要的完成的任务。
  3. Tech Lead需要加深对团队每个成员的了解,清楚的知道他们各自的强项,作为安排任务时的参考。
  4. 业务优先原则,一旦业务任务依赖的所有组件任务完成,业务任务马上进入最高优先级,团队以交付业务价值为最高优先级。
  5. 组件任务先于业务任务完成,未纳入业务流程前,团队需要Living Style Guide之类的工具帮助验收组件任务。

开发方式

4.以组件的Living Style Guide平台降低团队沟通成本

在前端开发时,经常存在这样的沟通场景:

  • 开发人员和UX验证页面设计时,因为一些细微的差异对UI进行反复的小修改。
  • 开发人员和业务人员验证界面流程时,因为一些特别的需求对UI进行反复的小修改。
  • 开发人员想复用另一个组件,寻找该组件的开发人员了解该组件的设计和职责
  • 开发人员和QA一起验证某个公用组件改动对多个界面上的影响

当这样的沟通出现在上一小节的提到的场景,即组件出现在距离启动界面有多个层级的界面时,按照传统开发方式,UX和开发需要多次点击,有时甚至需要输入一些数据,最后才能到达想要的功能界面。没有或者无法搭建一个直观的平台满足这些需求,就会导致每一次的沟通改动就伴随着一次重复走的,很长的路径。使得团队的沟通成本激增,极大的降低了开发效率。

在组件化开发方案下, 因为组件的独立性,构建Living Style Guide平台变得非常简单,目前社区已经有了很多工具支持构建Living Style Guide平台(比如getstorybook)。

开发人员把组件以Demo的形式添加到Living Style Guide平台就行了,然后所有与UI组件的相关的沟通都以该平台为中心进行,因为开发对组件的修改会马上体现在平台上,再加上平台对组件的组织形式让所有人都可以很直接的访问到任何需要的组件,这样,UX和业务人员有任何要求,开发人员都可以快速修改,共同在平台上验证,这种“所见即所得”的沟通方式节省去了大量的沟通成本。

此外,该平台自带组件文档功能,团队成员可以从该平台上看到所有组件的UI,接口,降低了人员变动导致的组件上下文知识缺失,同时也降低了开发者之间对于组件的沟通需求。

图片 19

想要获得这些好处,团队的运作需要:

  1. 项目初期就搭建好Living Style Guide平台。
  2. 开发人员在完成组件之后必须添加Demo到平台,甚至根据该组件需要适应的场景,多添加几个Demo。这样一眼就可以看出不同场景下,该组件的样子。
  3. UX,业务人员通过平台验收组件,甚至可以在平台通过修改组件Props,探索性的测试在一些极端场景下组件的反应。

性能 体验

5. 对需求分析阶段的诉求和产品演进阶段的帮助

虽然需求分析阶段产品演进阶段不是组件化开发关注的重点,但是组件化开发的实施效果却和这两个阶段有关系,组件化方案需要需求分析阶段能够给出清晰的Domain数据结构,基础设计元素和界面原型,它们是组件化开发的基础。而对于产品演进阶段,组件化开发提供的两个重要特性则大大降低了产品演进的风险:

  • 低耦合的架构,让开发者清楚的知道自己的修改影响范围,降低演进风险。开发团队只需要根据新需求完成新的组件,或者替换掉已有组件就可以完成产品演进。
  • Living Style Guide的自文档能力,让你能够很容易的获得现有组件代码的信息,降低人员流动产生的上下文缺失对产品演进的风险。

更新 维护

三、组件化开发方案在React Native项目中的实施

前面已经详细讨论了为什么和如何做组件化开发方案,接下来,就以一个React Native项目为例,从代码级别看看组件化方案的实施。

五综合

1. 定义基础设计元素

在前面我们已经提到过,需求分析阶段需要产出基本的设计元素,在前端开发人员开始写代码之前需要把这部分基础设计元素添加到代码中。在React Native中,所有的CSS属性都被封装到了JS代码中,所以在React Native项目开发中,不再需要LESS,SCSS之类的动态样式语言,而且你可以使用JS语言的一切特性来帮助你组合样式,所以我们可以创建一个theme.js存放所有的基础设计元素,如果基础设计元素很多,也可以拆分位多个文件存放。

import { StyleSheet } from 'react-native'; module.exports = StyleSheet.create({ colors: {...}, fonts: {...}, layouts: {...}, borders: {...}, container: {...}, });

1
2
3
4
5
6
7
8
import { StyleSheet } from 'react-native';
module.exports = StyleSheet.create({  
        colors: {...},  
        fonts: {...},  
        layouts: {...},  
        borders: {...},  
        container: {...},
  });

然后,在写具体UI组件的styles,只需要引入该文件,按照JS的规则复用这些样式属性即可。

  1. 开发方式
  2. 性能 体验
  3. 更新 维护

2.拆分组件树之Component,Page,Scene

在实现业务流程前,需要对项目的原型UI进行分解和分类,在React Native项目中,我把UI组件分为了四种类型:

  • Shared Component: 基础组件,Button,Label之类的大部分其它组件都会用到的基础组件
  • Feature Component: 业务组件,对应到某个业务流程的子组件,但其不对应路由, 他们通过各种组合形成了Pag组件。
  • Page: 与路由对应的Container组件,主要功能就是组合子组件,所有Page组件最好名字都以Page结尾,便于区分。
  • Scene: 应用状态和UI之间的连接器,严格意义上它不算UI组件,主要作用就是把应用的状态和Page组件绑定上,所有的Scene组件以Scene后缀结尾。

Component和Page组件都是Pure Component,只接收props,然后展示UI,响应事件。Component的Props由Page组件传递给它,Page组件的Props则是由Scene组件绑定过去。下面我们就以如下的这个页面为例来看看这几类组件各自的职责范围:

图片 20

(1)searchResultRowItem.js

export default function (rowData) { const {title, price_formatted, img_url, rowID, onPress} = rowData; const price = price_formatted.split(' ')[0]; return ( onPress(rowID)} testID={'property-' + rowID} underlayColor='#dddddd'> {price}{title} );}

1
2
3
4
5
6
7
8
9
10
export default function (rowData) {
    const {title, price_formatted,
            img_url, rowID, onPress} = rowData;
    const price = price_formatted.split(' ')[0];
    return (
         onPress(rowID)}
          testID={'property-' + rowID}
          underlayColor='#dddddd'>
          {price}{title}
  );}

(2)SearchResultsPage.js

import SearchResultRowItem from '../components/searchResultRowItem'; export default class SearchResultsPage extends Component { constructor(props) { super(props); const dataSource = new ListView.DataSource({ rowHasChanged: (r1, r2) => r1.guid !== r2.guid}); this.state = { dataSource: dataSource.cloneWithRows(this.props.properties), onRowPress: this.props.rowPressed, }; } renderRow(rowProps, sectionID, rowID) { return ; } render() { return ( ); }}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import SearchResultRowItem from '../components/searchResultRowItem';
export default class SearchResultsPage extends Component {
 
  constructor(props) {
    super(props);
    const dataSource = new ListView.DataSource({
      rowHasChanged: (r1, r2) => r1.guid !== r2.guid});
    this.state = {
      dataSource: dataSource.cloneWithRows(this.props.properties),
      onRowPress: this.props.rowPressed,
    };
  }
 
  renderRow(rowProps, sectionID, rowID) {
    return ;
  }
 
  render() {
    return (
      
    );
  }}

(3)SearchResultsScene.js

import SearchResults from '../components/searchResultsPage'; function mapStateToProps(state) { const {propertyReducer} = state; const {searchReducer:{properties}} = propertyReducer; return { properties, }; } function mapDispatchToProps(dispatch) { return { rowPressed: (propertyIndex) => { dispatch(PropertyActions.selectProperty(propertyIndex)); RouterActions.PropertyDetails(); } }; } module.exports = connect( mapStateToProps, mapDispatchToProps,)(SearchResults);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import SearchResults from '../components/searchResultsPage';
function mapStateToProps(state) {
  const {propertyReducer} = state;
  const {searchReducer:{properties}} = propertyReducer;
  return {
    properties,
  };
}
 
function mapDispatchToProps(dispatch) {
  return {
    rowPressed: (propertyIndex) => {
      dispatch(PropertyActions.selectProperty(propertyIndex));
      RouterActions.PropertyDetails();
    }
  };
}
 
module.exports = connect(
  mapStateToProps,
  mapDispatchToProps,)(SearchResults);

@王利华,vczero

3.Living Style Guide

目前社区上,最好的支持React Native的Living Style Guide工具是getstorybook,关于如何使用getstorybook搭建React Native的Living Style Guide平台可以参见官方文档或者我的博客。

搭建好Living Style Guide平台后,就可以看到如下的界面:

图片 21

接下来的工作就是不断在往该平台添加UI组件的Demo。向storybook中添加Demo非常简单,下面就是一个关于SearchPage的Demo:

import React from 'react'; import {storiesOf, action} from '@kadira/react-native-storybook'; import SearchPage from '../../../../src/property/components/searchPage'; storiesOf('Property', module) .add('SearchPage', () => ( ));

1
2
3
4
5
6
7
import React from 'react';
import {storiesOf, action} from '@kadira/react-native-storybook';
import SearchPage from '../../../../src/property/components/searchPage';
storiesOf('Property', module)
  .add('SearchPage', () => (
    
));

从上面的代码可以看出,只需要简单的三步就可以完成一个UI组件的Demo:

  1. import要做Demo的UI组件。
  2. storiesOf定义了一个组件目录。
  3. add添加Demo。

在构建项目的storybook时,一些可以帮助我们更有效的开发Demo小Tips:

  1. 尽可能的把目录结构与源代码结构保持一致。
  2. 一个UI组件对应一个Demo文件,保持Demo代码的独立性和灵活性,可以为一个组件添加多个Demo,这样一眼就可以看到多个场景下的Demo状态。
  3. Demo命名以UI组件名加上Demo缀。
  4. 在组件参数复杂的场景下,可以单独提供一个fakeData的目录用于存放重用的UI组件Props数据。

“存 在即合理”。凡是存在的,都是合乎规律的。任何新事物的产生总要的它的道理;任何新事物的发展总是有着取代旧事物的能力。React Native来的正是时候,一则是因为H5发展到一定程度的受限;二则是移动市场的迅速崛起强调团队快速响应和迭代;三则是用户的体验被放大,用户要求极 致的快感,除非你牛x(例如:12306最近修改手机号需要用户自己发短信接收验证码)。
以下简单的介绍下H5、React Native、Native的含义:

4.一个完整的业务开发流程

在完成了上面三个步骤后,一个完整的React Native业务开发流程可简单分为如下几步:

  1. 使用基础设计元素构建基础组件,通过Living Style Guide验收。
  2. 使用基础组件组合业务组件,通过Living Style Guide验收。
  3. 使用业务组件组合Page组件,通过Living Style Guide验收。
  4. 使用Scene把Page组件的和应用的状态关联起来。
  5. 使用Router把多个Scene串联起来,完成业务流程。

最近三四年间,国内外的前端与全栈开发者社区都在坚持不懈地追寻使用JavaScript与HTML、CSS技术体系开发App内场景的核心工程技术。这种技术,在国内很多公司与团队中,被通称为H5。——童遥

四、总结

随着前后端分离架构成为主流,越来越多的业务逻辑被推向前端,再加上用户对于体验的更高要求,前端的复杂性在一步一步的拔高。对前端复杂性的管理就显得越来越重要了。经过前端的各种框架,工具的推动,在前端工程化实践方面我们已经迈进了很多。而组件化开发就是笔者觉得其中比较好的一个方向,因为它不仅关注了当前的项目交付,还指导了团队的运作,帮助了后期的演进,甚至在程序员最讨厌的写文档的方面也给出了一个巧妙的解法。希望对该方法感兴趣的同学一起研究,改进。

1 赞 收藏 评论

这段是取自童老师给小二我新书作的序,没有断章取义的意思。很清楚,H5并不是狭义的HTML5新标签和API,而是工程化的“In App” technology。

关于作者:ThoughtWorks

图片 22

ThoughtWorks是一家全球IT咨询公司,追求卓越软件质量,致力于科技驱动商业变革。擅长构建定制化软件产品,帮助客户快速将概念转化为价值。同时为客户提供用户体验设计、技术战略咨询、组织转型等咨询服务。 个人主页 · 我的文章 · 84 ·   

图片 23

iOS/Android ——原生应用(都懂得,不解释)。

React Native —— React & Native ,应运而生!

一、React Native的出现

React Native的出现,似乎是扛起的反H5的旗子。就像当年Facebook放弃H5,全部转向Native一样。这一点,我们需要认同和保持高度的清醒。 那么,React Native是否又是在吞食Native的领地呢?技术的发展,是用户风向标的导向起的作用。任何一门技术的出现,都是当时用户需求的体现。

我们应该从以下几点看待React Native的出现。

"鉴往知来"——从过去的教训中总结经验,从用户的角度开拓未来
“HTML5差强人意,但是与原生应用相比还是有些差距”——为了更高的追求! 用户体验!
“人才宝贵,快速迭代”——Web开发者相对较多,寻找平衡点
“跨平台!跨平台!跨平台!”——单一技术栈
“xx是世界上最好的语言” ——工程学的范畴,没有最好,只有最适合

HTML5 vs React Native ? HTML5 : React Native
结论(React Native):
1、原生应用的用户体验
2、跨平台特性
3、开发人员单一技术栈
4、上手快,入门容易
5、社区繁荣

二、3款应用效果

注:以下所有对比均在iOS平台下
图片 24
图片 25
图片 26
上面3张图片,如果去掉第一张图的“HybirdApp”的字样,是否分得清哪个是React Native开发?哪个是Native应用。
你的第一感觉是什么?

三、工程方案

为 了评估3种方案的技术优势和弱势。我们需要开发功能大致相似的App。这里,我们使用了“豆瓣”的API来开发“豆搜”应用。该应用能够搜索“图书”、 “音乐”、“电影”。想当年,豆瓣以“图书评论”走红,尤其是12年当红!豆瓣是一个清新文艺的社区,一个“慢公司”。最近有一则网传消息,注意是网传 ——“传京东投1.5亿美元控股豆瓣”。今天,不聊豆瓣,我们要聊一个工程化的问题。

我们需要将3款App的功能做到一致,同时需要保持技术要点一致。比如React Native这里使用了TabBar,那么Native我们也必须使用TabBar。简单而言就是:功能一致,组件 & API一致。我们功能如下图所示:
图片 27

1、H5方案
在H5/Hybird应用中,我们使用AngularJS开发单页webApp,然后将该WebApp内嵌入到iOS WebView中,在iOS代码中,我们使用Navigation稍微控制下跳转。
WebApp地址:
WebApp项目地址: (很简单的一个项目)
H5/Hybird项目地址:

2、React Native
在React Native中,封装必要的功能组件。
项目地址:
项目结构如下图:
图片 28

3、Native(iOS)
使用React Native大致相同的组件开发App,不使用任何第三方库,代码布局。
项目地址:

四、对比分析

很 多时候,新技术的采用最希望看到的是数据,而不是简单说“用户体验棒,开发效率高,维护成本低”。不过,生活中也有这样的同学,知一二而能窥全貌。当然, 本人生性胆小,也没有那么多的表哥和隔壁的老王,所以不敢早下定论,不敢太放肆。赵本山在《大笑江湖》中有句名言“May the force be with you”(别太放肆,没什么用)。因此,从以下几个方面做一个简单的对比。

----------提纲------------

1、开发方式

(1)代码结构
(2)UI布局
(3)UI截面图
(4)路由/Navigation
(5)第三方生态链

2、性能 & 体验

(1)内存
(2)CPU
(3)动画
(4)安装包体积
(5)Big ListView
(6)真机体验

3、更新 & 维护

(1)更新能力
(2)维护成本
----------提纲------------

1、开发方式

很 多人说React Native的代码不好看,不好理解。那是因为前端工程师都熟悉了Web的开发方式。怎么解决这个问题呢,可以先看看iOS代码,断定不熟悉iOS的同学 心里会默念“一万匹**马奔腾”。那时候,你再看React Native,你会觉得使用React Native开发App是件多么美好的事!OK,我们先来看下三者在开始“一款简单App”的代码结构。
(1)代码结构
H5/Hybird的开发模式,我们需要维护3套代码,两套是Native(iOS/Android)代码,一套是WebApp版本。这里,我们使用AngularJS作为WebApp单页开发框架。如下图所示。
图片 29
在React Native中,同样需要关注部分的Native代码,但是大部分还是前端熟悉的JavaScript。在“豆搜”应用中,代码结构如下:
图片 30
在Native开发中,更加强调Native开发者的能力。平台是:iOS/Android。
图片 31
结 论:从前端角度而言,React Native跨平台特性,不要开发者深入的了解各平台就能开发一款高效App。同时,语言层面而言,JavaScript运用很广泛,入门门槛相对较低。 React Native虽然抛弃了MVC分离实践,但是从业务角度而言,更为合理。一切而言:对前端,对移动领域是利好的消息。

(2)UI布局
“面容姣好”,合理的UI却总是跟着时间在变。那么UI布局就不是小事。
Web开发布局目前大多是 DIV + CSS。
React Native的布局方式是Flexbox。

   //JSX
  <ScrollView style={styles.flex_1}>
    <View style={[styles.search, styles.row]}>
      <View style={styles.flex_1}>
        <Search placeholder="请输入图书的名称" onChangeText={this._changeText}/>
      </View>
      <TouchableOpacity style={styles.btn} onPress={this._search}>
        <Text style={styles.fontFFF}>搜索</Text>
      </TouchableOpacity>
    </View>
    {
      this.state.show ?
      <ListView
        dataSource={this.state.dataSource}
        renderRow={this._renderRow}
        />
      : Util.loading
    }
  </ScrollView>
  //样式
  var styles = StyleSheet.create({
      flex_1:{
        flex:1,
        marginTop:5
      },
      search:{
        paddingLeft:5,
        paddingRight:5,
        height:45
      },
      btn:{
        width:50,
        backgroundColor:'#0091FF',
        justifyContent:'center',
        alignItems:'center'
      },
      fontFFF:{
        color:'#fff'
      },
      row:{
        flexDirection:'row'
      }
    });        

而Native布局就有种让你想吐的感觉,尤其是iOS的布局。这里不是指采用xib或者Storyboard,而是单纯的代码,例如添加一个文本:

UILabel *publisher = [[UILabel alloc]init];
publisher.frame = CGRectMake(bookImgWidth + 10, 50, 200, 30);
publisher.textColor = [UIColor colorWithRed:0.400 green:0.400 blue:0.435 alpha:1];
publisher.font = [UIFont fontWithName:@"Heiti TC" size:13];
publisher.text = obj[@"publisher"];
[item addSubview:publisher];           

总结:React Native既综合了Web布局的优势,采用了FlexBox和JSX,又使用了Native原生组件。比如我们使用一个文本组件。
<Text style={{width:100;height:30;backgroundColor:'red'}}>测试</Text>

(3)UI截面图
Hybrid方式截面图
图片 32
可以看到第一层列表页是完整的布局,实际上这就是Web页面;而第二层灰色的是Native的WebView组件。
iOS UI截面图
图片 33
图片 34
可以看到Native页面的组件特别多,即使是列表页,其中某一项都是一个组件(控件)。

当然,我们就会想,能够完全调用原生组件呢?那样性能是否更好?
React Native UI截面图
图片 35
图片 36
可以清楚的看到React Native调用的全部是Native组件。并且层次更深,因为React Native做了组件的封装。如上图,蓝色边框的就是RCTScrollView组件。

(4)路由/Navigation
在Web单页面应用中,路由由History API实现。
而React Native采用的路由是原生的UINavigationController导航控制器实现。
React Native NavigatorIOS组件封装程度高;Navigator可定制化程度高。
Navigator方法如下:

getCurrentRoutes() - returns the current list of routes
jumpBack() - Jump backward without unmounting the current scene
jumpForward() - Jump forward to the next scene in the route stack
jumpTo(route) - Transition to an existing scene without unmounting
push(route) - Navigate forward to a new scene, squashing any scenes that you could jumpForward to
pop() - Transition back and unmount the current scene
replace(route) - Replace the current scene with a new route
replaceAtIndex(route, index) - Replace a scene as specified by an index
replacePrevious(route) - Replace the previous scene
immediatelyResetRouteStack(routeStack) - Reset every scene with an array of routes
popToRoute(route) - Pop to a particular scene, as specified by its route. All scenes after it will be unmounted
popToTop() - Pop to the first scene in the stack, unmounting every other scene         

相对Native而言,这些接口更Native还是很相似的。

//iOS UINavigationController  
//相对Web而言,不用自己去实现路由,并且路由更加清晰         
[self.navigationController pushViewController:detail animated:YES];

"豆搜" WebApp路由(基于AngularJS)如下:
图片 37

"豆搜" React Native版本导航如下:
图片 38

"豆搜" iOS版本导航代码如下:
图片 39

总结:React Native封装的导航控制更容易理解。

(5)第三方生态链
“我的是我的,你的也是我的。 ”——我不是“疯狂女友”,我是React Native!
我们缺少“城市列表”组件,OK,使用JSX封装一个;觉得性能太低,OK,基于React Native方案封装一个原生组件。
这个iOS图表库不错,拿来用呗! => 完美!
这一切都是基于React Native提供的模块扩展方案。
所以说:iOS第三方库 + 部分JavaScript库 = React Native 生态库

2、性能 & 体验

我们都很关注一款App性能。因此测试和体验App的性能很重要。以下测试,都是基于相同的case。
测试平台:模拟器,iphone6,iOS8.4
(1)内存
首先,我们来看下Native应用占用的内存情况。一开始,原生应用启动后,占用内存是20~25M;针对相同的case,跑了2min,结果如下图:
图片 40
可以看出,峰值是87.9M,均值是72M;内存释放比较及时。

我们再来看下Hybird App的情况。App已启动,占用内存35~55M;同样,跑了2min以上,结果如下图:
图片 41
可以看出,峰值在137.9M,因为整个应用在WebView中,内存释放不明显,存在缓存。

最后,看下React Native的情况。App启动占用内存35~60M,同样跑2min以上,结果如下图:
图片 42
可以看出,峰值在142M,内存相对释放明显。

总结:React Native和Web View在简单App上相差不大。二者主要:内存消耗主要是在网页数据上。

(2)CPU
我们可以看一下Native应用程序CPU的情况,最高值在41%。
图片 43
Hybird App的最高值在30%。
图片 44
React Native的最高值在34%。
图片 45

总结:CPU使用率大体相近,React Native的占用率低于Native。

(3)动画
React Native提供了Animated API实现动画。简单效果,基本OK。个人觉得React Native不适合做游戏,尤其布局能力。
Native Animation提供UIView动画
H5/Hybird:采用js动画能力
总结:React Native Animated API / 封装Native动画库 可以满足基本需求

(4)安装包体积
Hybird App:
34(App壳) + 5(HTML) + 125(Angular) + 29(An-route) + 6(min.js) + 4(min.css) = 203 KB。

React Native:
不含bundle: 843KB
含bundle: 995KB

Native
83KB

React Native框架包大小
843(不含bundle) – 32(Hybird_app空壳,初识项目) = 811KB

相比快速迭代和热更新,比Native多了811KB一点都不重要,我们将图片素材、静态资源线上更新缓存起来即可减少很多体积。
总结:牺牲一点体积,换更大的灵活性!(世界上哪有那么美的事,除非丑,就会想得美,:) )。

(5)Big ListView & Scroll 性能
循环列表项500次: H5页面惨不忍睹
React Native还可以接受
Native 采用UITabView更高效,因为不渲染视图外部分。

(6)真机体验
机型:iphone4s,iOS7
Native > React Native > Hybird
如果非要给个数字的话,那我个人主观感受是:
Native: 95%+ 流畅度
React Native: 85~90% 流畅度
H5/Hybird: 70% 流畅度

总结:Native/React Native的体验相对而言更流畅。

3、更新 & 维护

(1)更新能力
H5/Hybird: 随时更新,适合做营销页面,目前携程一些BU全部都是H5页面;但是重要的部分还是Native。
React Native:React Native部分可以热更新,bug及时修复。
Native:随版本更新,尤其iOS审核严格,需要测试过关,否则影响用户。

(2)维护成本
H5/Hybird: Web代码 + iOS/Android平台支持
React Native:可以一个开发团队 + iOS/Android工程师;业务组件颗粒度小,不用把握全局即可修改业务代码。
Native:iOS/Android开发周期长,两个开发团队。

总结:React Native 统一了开发人员技术栈,代码维护相对容易。

五、综合

1、开发方式

(1)代码结构: React Native更为合理,组件化程度高
(2)UI布局:Web布局灵活度 > React Native > Native
(3)UI截面图:React Native使用的是原生组件,
(4)路由/Navigation:React Native & Native更胜一筹
(5)第三方生态链:Native modules + js modules = React Native modules

2、性能 & 体验

(1)内存:Native最少;因为React Native含有框架,所以相对较高,但是后期平稳后会优于Native。
(2)CPU:React Native居中。
(3)动画:React Native动画需求基本满足。
(4)安装包体积:React Native框架打包后,811KB。相比热更新,可以忽略和考虑资源规划。
(5)Big ListView
(6)真机体验:Native >= React Native > H5/Hybrid

3、更新 & 维护

(1)更新能力: H5/Hybird > React Native > Native
(2)维护成本: H5/Hybird <= React Native < Native

React Native定制难度相比Native有些大;但是具备跨平台能力和热更新能力。
最后硬广一下我的书:
图片 46

本文由9159.com发布于前端,转载请注明出处:做移动应用开发,12306最近修改手机号需要用户自

关键词: