在FoxOne1.5.1更新中，打开各种交易所网页的速度有了很大的提升。我们测量了新版FoxOne在不同网络环境下的Dom加载和页面加载情况下所需要的时间：可以看出新方案在DOM加载速度和Page加载速度方面都有不同程度的提升（从9%~31%)。我们该怎么做呢？Webview的问题FoxOne的桌面版使用Electron+ElectronBuilder+Vue作为技术栈。Electron是一个使用Web技术构建桌面应用程序的框架，ElectronBuilder为Electron提供了打包、签名、跨平台CI和自动更新的全家桶解决方案。我们一开始选择Electron是因为web技术会为FoxOne的开发提供很多便利，但是由于Electron项目依赖于Chromuim，所以Chromuim上游的一些问题会无缝转化到Electron上。典型的就是webview可以看做是一个运行在独立进程中的比较安全的iframe。如果我们需要在ElectronApp中嵌入网页（而不是在新窗口中打开），将其放入webview是官方推荐的标准做法，许多著名的桌面软件也在使用它。本来FoxOne也在用webview，一开始好像没问题。但是很快我们就发现了问题：1、虽然webview运行在一个独立的进程中，但是在DOM结构上和Renderer进程是同源的，所以在渲染webview的时候，会拖累整个Renderer进程的DOM;2.webview(1,2,3)存在一些问题，我们无法解决这些问题，Electron团队也无法解决——甚至，考虑到webview在Chromuim中的应用范围狭窄，Chromuim团队可能不打算解决他们。针对以上问题，我们决定使用browserview代替webview。browserview和webview最大的区别是browserview是托管在主进程而不是renderer。这与Chrome中处理页面的方式非常相似，从而导致页面响应速度很快。当然，由于GUI属于两个进程，代价就是我们在处理GUI布局时，不得不单独处理browserview。browserview的问题在使用过程中，我们发现browserview的问题主要表现在两个方面。browserview缺少webview丰富的API。使用browserview，你将无法使用插件、预加载脚本、截图等。Browserview在渲染器进程中是不活跃的，因此你无法使用舒适的CSS来控制布局。对于第一点，我们选择在实现中直接操作webContents来获取丢失的方法和属性。对于第二点，我们设计了一个专门的browserviewmanager来控制browserview布局的对外表现。使用browserview考虑到browserview的独立性，我们设计了一个browserviewmanager来管理所有的browserview，并使用ipcMain和ipcRenderer建立通信。当用户在客户端进行操作（如前进、后退、刷新、切换页面等）时，通过Electron事件机制将相应的指令传递给browserviewmanager，然后让browserviewmanager操作browserview及其webcontents来执行指令。结论虽然browserview在Electron中还是一个实验性的功能，但是API并不完善，缺乏webview的脚本预加载等机制。但是如果你需要在App中嵌入外部网页，在适当权衡下使用browserview是一个不错的选择。招聘时间~FoxOne是一个以技术为导向的创新团队。我们正在围绕基础研究和产品化寻找区块链技术的正确应用方向。而现在，改变世界需要您的陪伴。招聘前端工程师、移动端工程师、爬虫工程师、Golang研发工程师、社区产品运营。欢迎热爱FoxOne的有识之士加入我们。请注意，我们的招聘邮箱是jobs@fox.one。谢谢大家阅读。
