Infoq 采访：豆瓣混合开发框架 Rexxar
2016-12-02
简介
这篇是Infoq关于”豆瓣混合开发框架Rexxar”的一个采访的内容。主要回答了我们为何造了Rexxar这个轮子。我们也表达了自己对移动端混合开发的一些看法。对于移动开发中采用 Web 技术，Rexxar应该会有一定的借鉴经验。
采访
1 豆瓣App的开发团队配置是怎么样的？（前端、iOS、Android各占多少）使用Rexxar的理想团队配置是怎样的？
我们的移动团队大约有十多位客户端工程师，其中iOS和Android各一半。另有一位优秀的前端工程师专门支持豆瓣App中的混合开发，他负责Rexxar Web的开发，提供基础设施。同时如果有一些较复杂的业务要用Rexxar实现，他也会参与和指导业务开发。
使用Rexxar这类混合开发技术，使得团队开发的技术栈向前端技术偏斜了。所以，较理想的配置是团队中加入了较优秀的前端工程师。他来处理基础设施的开发，和疑难问题的解决。同时，整个团队需要理解混合开发所带来的优势，认可这个开发方式的转变，并且愿意学习和调整自己的技术栈。在项目中，在合适的场景中，我们优先使用Rexxar。在团队中，我们鼓励非前端工程师学习和使用前端技术。为此，我们专门组织了关于前端技术内部培训。让有意愿的非前端工程师具有了可以使用前端技术进行日常开发的基本能力。在我们的日常开发中，大部分Rexxar页面都由客户端工程师完成，前端工程师会帮忙做Code Review和解决疑难问题。
2 Rexxar相比较于之前的一些Hybrid方案（PhoneGap/Cordova等）有什么优势？
PhoneGap由Apache接管后改名为Cordova，所以它们实际上是一个项目。PhoneGap/Cordova实际上不应该称为Hybrid方案。因为，它的目标是全面使用前端技术开发移动应用，而不是前端和原生技术混合使用。但是，包括Cordova，还可以加上React Native，以及Rexxar的目标是一致的：使用前端技术来开发移动应用，提高工程效率。
豆瓣实际上使用过PhoneGap开发过一款移动App，并在AppStore上架了，这个应用叫豆瓣音乐人。我们对PhoneGap/Gordova有一定了解和使用经验。为何在开发豆瓣App时又造了一个叫Rexxar的轮子呢？这是因为，我们对PhoneGap/Gordova这个项目的理念并不完全赞同。所以，Rexxar的出发点和PhoneGap/Gordova并不一样。
PhoneGap/Gordova这个项目极具野心。它希望完全使用前端技术解决移动开发。所以，可以看到它尽力让前端技术完成尽量多的开发工作，只在前端无法直接调用的原生系统功能方面提供了前端可用的接口。主流的PhoneGap/Cordova项目将业务逻辑都实现在一个WebView中。目标是，让开发者只使用前端技术就可以完成一个移动应用的开发。这种做法需要有一个前提：前端技术可以解决移动开发的所有需求。我们认为PhoneGap/Gordova这个理念在现阶段有些过于理想化了，或者说过于激进了。
Rexxar则相对实际，或者说保守一些。我们仍然认为，现阶段，甚至在相当遥远的未来，移动开发中前端技术都不太可能完全代替原生技术。但我们同时承认，移动开发中总是存在部分功能是适合使用前端技术完成的。在我们的认识中，前端技术和原生技术应该是共生的。移动开发中，前端技术不会完全代替原生技术；而有了前端技术的加入，移动开发的效率会提高。基于这种认识，我开发了Rexxar。可以看到，Rexxar立足于在一个原生项目使用前端技术，而不是整个项目都使用前端技术实现。我们甚至提供一个页面部分使用Rexxar完成，部分使用原生技术实现的方案。
总结而言，如果Rexxar和PhoneGap/Gordova比较的话，大目标是一致的：使用前端技术开发移动应用。实现技术栈差不多：使用WebView，提供调用原生功能的接口。但是，出发点不一样。PhoneGap/Gordova致力于完全使用前端技术进行移动开发；Rexxar致力于在移动项目中部分使用前端技术。
3 你们在Rexxar实践中，采用React作为前端，有调研过React Native吗？是否会考虑使用RN？
Rexxar本身对前端框架的选择没有要求，只是我们选择了React来实现业务层。在开发和使用Rexxar过程中，我们看到了React Native的发布(2016年12月)。React Native提供了一种使用前端技术开发移动应用的技术方案。这和我们开发Rexxar的目的是一致的。只是，我们仍然在停留在浏览器引擎中，而Facebook大胆激进地脱离了沉重的浏览器引擎，架设了自己的Web通向Native的桥梁。我们马上就组织了研究Rexxar Native，并做了小范围的实践，也与同行做了交流。结论是，现在，React Native还稍显稚嫩。对于一些技术栈比较特别的团队，比如Web经验特别丰富，前端工程师特别优秀，但又缺乏优秀的客户端工程师的情况，React Native是一个快速切入移动应用市场的技术选择。但就我们的情况和React Native的现状而言，我们应该还会坚持，不会使用React Native。当然，React Native一直在发展和进步。如果，有一天React Native和React可以在代码级别移植，我们也许会尝试从WebView迁移到React Native。毕竟WebView的性能仍然弱于原生。
4 你们的豆瓣App和Web实现了多少代码共用？（只计算Rexxar相关代码）
我们使用Rexxar的一个目的就是实现代码在 Android，iOS和Web三个平台的可移植。所以，只要是豆瓣App中使用Rexxar开发的页面都有被使用到移动Web站的能力。只是存在一些产品上的要求，某些页面只需要在豆瓣App出现，而没有移动 Web站需求。
5 使用Rexxar开发的方式，完全使用它进行开发的情况下，对于设备API和本地组件的扩展性如何？使用它代替WebView的话，对App体积的影响？
我们对于Rexxar使用场景有明确的定义：页面是重度展示，并轻度交互的。所以，除了比较简单的应用之外，如果对使用体验有追求，大概很难仅用Rexxar，或者其他某种混合开发完成。
对于扩展Rexxar的功能，我们留出了清晰易用的接口。项目中也提供了几个扩展Rexxar功能的实例，文档也较为完整。我们在豆瓣App中其实也使用相同的接口做了一些扩展，只是由于和豆瓣App的业务绑定较深，就没有放入Rexxar项目。如果有问题，可以在github上提，我们会尽力解答。
Rexxar在客户端的实现其实就是一个定制了更多功能的WebView。而且，我们使用的是系统的WebView。所以，它对App的体积没有影响。但是，同时使用很多个WebView带来的内存问题Rexxar同样也有，这是需要注意的。
6 豆瓣App的Crash监控/日志是如何做的？由Rexxar带来的Crash占比多少？
我们没有为Rexxar监控做特别的处理。Crash监控和日志就混在原来的日志中。从上线了Rexxar之后，JavaScript引擎的相关错误是有一些增长。错误的比例和Rexxar的页面的增加相关，一直在变化，但都未超过10%。但是，由于豆瓣App中主要还是原生页面占大多数。所以，Rexxar带来的Crash所占的比例并不大。
这方面，现阶段我们还没有做太多的工作。在移动环境下，如何定位Rexxar页面的错误，如何修正，如何调试这些都是基础设施。这也是我们未来需要加强的。
7 你们为何将其开源出来，对Rexxar开源项目有什么愿景？
豆瓣App和我们的团队都经历了从小到大的发展过程。Rexxar是这个发展过程中，我们解决工程效率的一个方案。在豆瓣移动开发中使用Rexxar，确实在一定程度上提高了我们的开发效率。以前一个页面需要iOS和Android两位工程师各开发一遍，现在只需要一位工程师写一次前端代码，甚至还可以应用到移动Web站上去。前端技术开发界面方面开发方面也有效率上的优势。热部署能力，使我们规避了发布移动应用的审核过程，也让bug修复过程更便利。
我们将Rexxar这个项目开源。一方面，是因为提高移动开发的工程效率是一个普遍问题，而我们的实践结果也证明Rexxar确实帮助我们改善了工程效率。所以，Rexxar应该能给大家提供一些借鉴的方向；另一方面，是为了提高项目本身的质量。我们知道还存在不少问题。开源这个项目，促使我们提高了整个项目的代码质量，也更容易听到大家的意见和建议。
虽然Rexxar仍然存在一些问题，和使用上的限制。但是在有限的使用中，我们仍然收获不少。所以，在未来我们应该会持续推动Rexxar在豆瓣移动开发中的使用。对于Rexxar未来的发展，我们主要关注两个方面：一方面是基础设施，比如，如何在产品中，更好地监控Rexxar页面出现的问题，如果希望在大型项目中使用Rexxar，这些基础设施是应该配备的；另一方面是性能，Rexxar仍然是跑在浏览器引擎中的，浏览器引擎这个中间层提高了我们的工程效率，但也因为性能问题局限了使用范围。所以，我们会花一些提高Rexxar的运行效率。比如，Rexxar的iOS版一直在关注从UIWebView迁移到WKWebView的可能性。