Web App开拓者们实在是受够了HTML5运用的诸多根本体验问题，如：加载韶光长，用户体验差，动画效果弱等。Native App开拓者则是对付变革的需求以及App Store审核韶光无法平衡。
因此，从React Native发布起，如一阵夏日凉风唤醒了沉睡的开拓者，使得这类技能近期备受关注。React Native实现办理的是前端开拓者可以利用相同的技能体系来办理跨平台运用开拓的问题，并以创建HTML及CSS子集通过WebCore技能与原生结合构建出与体验上险些无差别的App。
一来HTML5原有痛点被肃清，二来前端技能栈被保留，难道前端开拓工程师的春天真的来了？
Web与Native交叠：未来的全终端开拓工程师
F8大会的主题折射出一个非常主要的不雅观点，未来可能Web前端开拓工程师与Native移动运用开拓工程师的事情职责会相互重叠，所持技能及开拓环境会趋向于统一，平台之间的边界不会太明显，未来的几年可能会产生一种新的职位叫做“全终端开拓工程师”，属于“全栈”系列的前半部分，他们会更专注于跨平台App的UI及交互构建，使多平台体验同等，从iOS App、Android App到HTML5 App的UI开拓。
就此方向，React Native才给出了一个大一统的口号：“Learn once，write everywhere”。为什么？想想就知道了。
React Native实在并不算是新技能，以往BeeFramework（XML+CSS）、NativeScript（JS+CSS）等都有类似的实现，但它们只专注于Native平台并利用了一些非标准或不为前端开拓者而熟知的技能。
React Native思维最大的不同在于，基于ReactJS的知识体系，只要学过一次就可以写遍全平台，那么我们可以认为iOS只是一个开始（Facebook野心是巨大的）。
React Native因何而来？
React Native能够被设计并实现，我个人以为是得益于作者对付浏览器技能和Virtual DOM技能的深度技能思维及扩展，由于在基于此项技能的基本模型及模式建立好的情形下，架接于任何一个平台来实现将不再是难事。我们能够看到React Native中有类似于WebKit的影子，比如Shadow View和CSS Node。
在内存中，这两种基本元素构建出能够表达UI构造的一种通用模型，那么在任何一个平台上只要遵照这个规则，都将可以描述出一个UI是“长什么样子”，有些类似于浏览器中的DOM Tree + Style Tree。基于此，React Native通过ReactJS又实现了一套平台无关的触控处理及数据绑定，这样将原来平台干系的代码抽离到了平台无关的JavaScript措辞来实现，大大降落了React Native开拓者对平台特性及措辞的依赖。
回顾浏览器的发展历史，从20年前Netscape发布了Navigator到如今的Chrome及Safari，浏览器内核的实质没有什么变革，输入进入的是UIML（如HTML），其核心WebCore帮你加载、解析、构建、打算出页面中每个元素结点高下级关系、位置、及样式。
不幸的是，W3C对付HTML5标准的确立与推进也过于缓慢，而且标准与需求明显严重脱节，颇有些鸡肋之感。W3C险些错失落了在移动真个布局机会，乃至我们不清楚这帮大佬是不是真的有考虑Web技能在移动端发展的未来，让人不禁想问，为什么React Native这类技能不是由Google和Apple两大WebKit推戴者及手机操作系统开拓商发起并实现的？
未来又将如何？
以是，此时一定会涌现其他一些不甘寂寞的巨子浮出水面，给出答案。那便是，考试测验重造足够好的轻量级WebCore，用于知足同时具有原生性能及体验，并也具有Web开拓效率的全新技能。
关于这一点，我以为React Native偏离得有些远，Facebook最初更多的只是为理解决自己内部的需求，现在是想借ReactJS吸引更多的开拓者来重造一个“通天塔”。
自然，韶光长了会涌现两种结果，一种是Web与Native领悟，另一种则是Web与Native分裂。而分裂的结果是，Facebook强行撕裂一些W3C身上对自己有利的肉，翻炒之后做成React这道菜。对付企业来说，全面换用React Native的机遇还不足成熟，至少在Android版本推出后再看。笔者本人也看过React Native iOS的实当代码还有待改进。
取精华去糟粕，Samurai-Native框架与React Native有哪些不同？
末了，再说说我所开拓的Native App框架Samurai-Native。与React-Native相反，Samurai-Native的理念是使Native开拓者可以利用标准Web技能（HTML+CSS）办理跨平台UI开拓的问题，已在Github上开源。
Samurai-Native架构图
Samurai-Native与React Native比较有着诸多不同，后者在Native部分拥有着很多已经让人无力吐槽的实现：
<Text>不是UILabel或类似控件，而是drawRect，这样的问题是accessibility很差，无法选择复制粘帖，也无法实现富文本效果。<Text>不能嵌套，不能够利用Web开拓者思维来构建文本段。<List>不是UITableView或UICollectionView，而是通过UIScrollView实现的大略列表，无法知足后续繁芜需求。不能利用GestureRecognizer，而是由JS大略判断点击区域来实现手势识别。不能利用ResponderChain，事宜机制只能利用ReactJS供应的办法。JSX：让人无法想像的历史倒退，W3C通过20年将 “布局、样式、数据” 三者分享，Facebook只花了几个月就能合并到一起了。CSS-layout，只支持Flex-Box，不支持Fluid（流式）布局。CSS不支持继续和叠加，不支持多Class。HTML标准标签均无法利用。Native API须要手动导出，当iOS系统升级时，可能会带来兼容性问题。控件必须继续自RCTView，并须要定义RCTViewManager，难以将现有控件为React-Native所用。全局hook了触屏事宜，由root view转发给touch handler，再用60fps的timer刷新给ReactJS来处理，无法想像的实现办法……无法利用onclick，必须包裹一层<TouchableHighlight>，使布局构造变得极为繁芜。须要利用Chrome调试App，而无法利用原生IDE，调试过程变得极为繁芜。Samurai-Native的UI HTML示例代码
因此，在开拓Samurai-Native的过程中，笔者专门针对这些问题进行了改进，取React Native精华，让它们成为Samurai-Native中的上风：
支持标准HTML；支持标准CSS；支持UITableView；支持UICollectionView；利用原生GestureRecognizer；利用原生ResponderChain；UI layout、style、data完备分离；支持Fluid布局；支持样式继续和叠加，支持多Class；支持部分标准HTML标签（有做取舍）；支持原生控件直接导入，只须要通过<YourView/> 标签命名即可；支持onclick、onpan、onswipe多种手势；利用Xcode调试。为什么选择HTML+CSS的组合，而不再利用类似于React-Native或BeeFramework的XML？紧张缘故原由是不想再造轮子。HTML经由20年的韶光考验，已经足够成熟，是最好的繁芜UI布局的描述措辞。
Samurai-Native事情流程图
那么总结起来，Samurai-Native的终极目标是想做成一个标准的Web浏览器内核，来为开拓者们供应一款W3C标准WebCore的跨平台UI办理方案，既能渲染Web页面，又能天生原生View树。通过私有浏览器内核技能（Objective-C编写）将HTML+CSS解析渲染成为Native View树，从而既有Web开拓体验，又有不错的用户体验。
（责编/唐小引）
作者简介：
郭虹宇（@老郭为公民做事），有着近十年的移动App开拓及架构履历。曾在腾讯无线部门做研发Leader，目前经营开源事情室Geek-Zoo Studio。
CSDN移动将持续为您优选移动开拓的精华内容，共同磋商移动开拓的技能热点话题，涵盖移动运用、开拓工具、移动游戏及引擎、智能硬件、物联网等方方面面，如果您有想分享的技能、不雅观点，可通过电子邮件（tangxy#csdn.net，请把#改成@）投稿。
第一韶光节制最新移动开拓干系信息和技能，请关注mobilehub公众年夜众微旗子暗记（ID: mobilehub)。
