郭虹宇：关于Samurai Native和React Native的思考

个人简介 郭虹宇,A coder, a geek, a ghost of samurai in the human shell. 活跃于开源技术社区，早年供职于鹅厂无线部门。 2008年，加入腾讯，先后负责 QQ音乐、QQ影院、QQ阅读、QQ游戏/游戏大厅、QQ空间等多个项目的管理、架构设计及主力研发工作。 2012年，加入Geek Zoo Studio，致力于创造最有影响力的移动端开源团队，先后创造多款开源产品包括 ECMobile，O2OMobile。 2014年，国内第一批研究Semi-Hybrid架构的框架作者，新的启程才刚刚开始……

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 各位InfoQ的网友大家好，我们现在正在QCon北京2015的现在现场，现在坐在采访室的是郭虹宇老师，他今天在QCon上做了Hybrid混合应用的一次分享。郭老师请您先简单介绍一下自己。

郭虹宇：大家好，我叫郭虹宇，来自Geek Zoo Studio，最早的时候是在腾讯无线部门，负责过一些QQ空间、QQ游戏大厅、QQ音乐、影院等App的一些架构以及团队与研发管理的工作。目前是在一家做开源的工作室。我们在GitHub上有很多的开源项目，比如说EC Mobile、O2O Moblie来解决一些垂直行业的实际问题，两年前开源了BeeFramework，最近两周开源了Samurai-Native，这是一个半混合的开发框架，可以使开发人员使用HTML+CSS，以及基于我们私有浏览器内核来构建Native原生用户体验的一个App的技术方案。

   

2. 您最近开源的这个Samurai-Native框架，能否介绍一下它的特性？

郭虹宇：Samurai主要是有这么几样东西吧，首先它是基于我们自研的浏览器内核，基于浏览器内核，可以通过解析开发者所编写的HTML和CSS，将它转化成Native的WebView，也就是说我们主要的特性以及实现的主要功能是使用Web的技术手段来描述一个UI长什么样子，并且通过我们的技术将一些HTML和CSS这样的描述文件，构建并渲染成Native的一个View的交互体验。

   

3. 您刚才提到了它是您自己自定义化的一个浏览器内核，那么您在这个浏览器内核上有哪些个性化的设置呢？

郭虹宇：首先这个东西跟传统的浏览器内核，比如说大家都知道Webkit，最大的不同是这样的，我们都知道传统浏览器内核分几个阶段，parser是将HTML和CSS pass成DOM和StyleSheet，再将StyleSheet和DOM混合在一起之后，构建出Render，Render最后再通过浏览器的Painter，将Render Tree渲染，也就是我们实际说的画到你看到的浏览器的一个窗口上，这样的话我们现在做的事最大的不同是什么呢，除了最后一步以外，我们都能复用，因为HTML和CSS经过了大概20年的历史检验，它能够描述出几乎所有的市面上你看到这些产品复杂的布局结构。我们通过这样多年沉淀下来的技术，再加上我们将最后一步改造，将最终结果变成构建出Native Application里面的View，将外部开发的这种体验，和Native原生的View，包括手势识别、动画效果，以及最终串起来的整体的用户的交互体验，融合到了一起，所以最大的差别就是这样，跟传统的浏览器内核不一样，我们支持将原生的控件以及体验接入到原来的浏览器内核的架构里。

   

4. 您在两年前开发了BeeFramework，现在又有Samurai-Native，能不能说说这两者开发之间的一些关系，有一些什么样的经历？

郭虹宇：BeeFramework这个比较早了，是2013年的时候开源的，2013年的时候，如果了解我这个框架的网友可以这样理解，BeeFramework应该是现在的开源的Samurai-Native的前身，为什么呢？我们是走了一些弯路的，这个事我们不得不承认，BeeFramework当时没有考虑到未来开发人员他的学习成本，以及是否要使用一些标准化的东西来支撑这个框架走下去，所以当时走得比较远的是，BeeFramework当时自定义了一套UIML，也就是说XML再加CSS来构建Native的UI View，其实这条路可能不是未来开发的大趋势，就是Native和Web融合的时候应该走的一个正确的方向，所以Samurai-Native跟BeeFramework最不同的就是，我们重新思考了一下我们应该开源走的这条路，将我们的标准和基础放到了W3C以前定的标准的HTML和CSS的基础之上，所以这样最大的不同就是，两边都有同样的技术，架构上后者Samurai-Native更倾向于标准的浏览器架构，标准上是越来越遵守标准W3C的规范。

   

5. 下面这个问题可能有些尖锐，有些人认为移动开发应该是模块化的，就像开发积木，然后把这些积木搭起来一样，您为什么要做框架呢？

郭虹宇：我觉得这个问题很难回答，但是我想说这么一件事，其实也是我们从BeeFramework吸取出来的一个经验教训，我觉得以前我的理解，可能两年前我的思维还不够成熟，那时候想的是框架应该越做越大，不断的在框架里面做加法，应该这个框架解决几乎所有我们开发中遇到的这些问题，但是这个思路是不对的，我想应该是这样，像BeeFramework或者类似这样的框架，如果在一个成熟的团队，有成熟的架构师在引领，技术再往后发展的话，框架应该是越做越小，所以刚才你提到这个问题，以后的开发是模块化的，应该像搭积木一样把这个App搭出来，最后为什么我还要做框架？其实我不光是在做框架，我是做一个带框架的模块，为什么呢？在这样的一个思维之下，你发现可能以后我们开源产品或者说能构建出来一个App，它里面所有的模块都自有一套框架，不同的框架解决不同模块所在领域的问题，以后可能你会发现终端开发会有这样一个方向的定位，可能有一部分人在解决的是UI层面的问题，有些人可能解决的是跟服务器通讯的问题，有些人可能解决的是客户端存储的问题，有些人可能解决的是业务逻辑上怎么写，还有一些人可能是在架构上思考，怎么能在其他平台复用打通的问题。这个模块你把它垂直划分，像切蛋糕一样，以前我们想的是蛋糕应该有一百层，每层是平行搭在上面的，它不应该是这样的，我觉得应该是竖切，竖切之后，这些框架你可以做得很小，小到什么程度？比如说像我们Samurai-Native，实际上只是解决我们公司和团队作UI构建的纵深里面的一个模块级别的问题，所以我们在做这些东西的时候是用框架的思维在做模块，大概是这样。

   

6. Facebook在上个月开源了React Native的iOS版本，它这个应该也算是半混合的开发模式，那您对它这个技术有什么看法？

郭虹宇：我觉得Facebook做了一个很有意义的事，它真正的贡献我觉得并不是改变了人的开发方式，而是就像今天我分享的主题一样，真正改变的是我们应该重新思考App未来的架构，Facebook开源的这个React Native，我觉得它想做的一件事，随着Facebook团队越来越大，App做得越来越庞大，功能越来越多，用户的需求也越来越多，总是在做加法的时候，什么时候才能让这个团队的人员以及技术水平达到一个平衡，而去做更多的事，所以我觉得它给我们带来一个很好的思想，一定要把跨平台公共的问题抽离出来给出一种解决方案，然后通过通用的技术来解决掉之后，对于平台化差异的一些东西，通过差异的解决办法来解决，所以基于一种这样的思想，我觉得给大家一个很大的启发。

   

7. Samurai-Native和React Native两者的技术有什么不同？

郭虹宇：最大的不同也是刚才我说过的，React Native我是这样分析的，Facebook的历史由来是他们先研发了ReactJS，然后ReactJS的两位创始人想到前端开发其实可以干更多的事，但其实他们定义的这个，虽然我不知道这个中文怎么来说，但是我觉得他们应该是给行业一个重新定义，就是未来的由Facebook以及ReactJS粉丝转化过来的人，未来可能会变成叫做终端开发，也就是说它用相同的技术栈能解决跨平台不同UI的交互体验的问题。对于Samurai-Native实际上是完全另外一个方向，我们更多考虑的是Native开发者的问题，相比不一样的是，我们不是想构建一个ReactJS这样JS框架，而是让Native的开发，安卓和iOS的Native开发，能用同一套语言，大家都说中国话或者都说英语，能通过一种语言来沟通交流，界面上可以复用的一些资源。所以是两个方向，所以Samurai-Native是更倾向于遵守W3C规范，从HTML和CSS这种描述语言和标准开始，构建出一套在行业或者工业级别的规范下，能让两端的人打通。

   

8. 最后一个问题，您和QFish两位老师做的两个开源项目，一个是BeeFramework，一个是Samurai-Native，它们在GitHub上都有上千的Star，应该是在开源上做得非常成功，能请您分享一下如何做好开源项目？

郭虹宇：其实说这个事我觉得很惭愧，并没有做得太好，因为还是有很多网友也在骂，为什么在骂呢？刚才你也说了，主力开发就是我们两个人，其实要做好的话，还是需要所有人参与进来，我们目前来看BeeFramework以及Samurai-Native，从两个不同的技术方向上，我们只是起了一个开始，但是我更想的，像BeeFramework我们当时开源之后，国内的开发者贡献的代码数量不多，大部分人使用的方式是找到BeeFramework之后，把它肢解，然后把很多的代码可以放到自己工程里面来用。所以要想做好，其实从BeeFramework摔倒的经验来看，就像刚才您问到的，我们应该把框架做小，然后做成模块，做成模块之后，后面怎么把Samurai-Native做好，我们现在的规划就是，从Samurai-Native开始，我们起了一个叫Hackers Painters这样的一个组织，以后会去把每一个模块当作一个项目来做，这样的话在用户就不会像之前一样，感觉框架太重，参与不进来，新的这种组织的方式，可能很多人在某一个领域里面，他发现代码切割得很干净，项目和项目之间边界很清楚，他想参与到哪个项目里的话，其实是可以贡献他自己的代码，我觉得在后续不会太以我和QFish我们两个人为主力，更希望的是以一种更好的组织方式，让更多的人才，以及刚才会上与很多热心网友围观，大家一起来讨论问题，激发很多思想，我想让大家把真正你的思想落实到代码，提交到我们项目里面来，我觉得这样才真正会把这个项目做活。因为从中国来看，在GitHub上，我觉得没看到任何一个比较好的开源组织，为什么呢？每个人都在做，把框架做得越来越大，然后自己走得越来越远，然后很多人参与不进来。我们现在的想法就是，要起一个首先跟自己公司无关的一个组织，自己的公司以及公司里面每一个成员作为这个组织里面的一个成员，然后邀请其他人进来，这样的话集思广益，把这个东西才能做得越来越好。