移动端开发语言的未来的猜想#华为云·寻找黑马程序员#

【摘要】 #华为云.寻找黑马程序员#

不管是最早的Phonegap，还是后来的React Native、Weex，Flutter，或者是各个公司自创开发语言，都是在不断寻求开发语言统一，从而解决ios、android乃至H5、小程序多端代码复用的问题，从而提高开发效率，降低人员学习及维护成本。

基于WebView的框架优点很明显，它们几乎可以完全继承现代Web开发的所有成果（丰富得多的控件库、满足各种需求 的页面框架、完全的动态化、自动化测试工具等等），当然也包括Web开发人员，不需要太多的学习和迁移成本就可以 开发一个App。同时WebView框架也有一个致命（在对体验&性能有较高要求的情况下）的缺点，那就是WebView的渲 染效率和JavaScript执行性能太差。再加上Android各个系统版本和设备厂商的定制，很难保证所在所有设备上都能提供 一致的体验。 

为了解决WebView性能差的问题，以React Native为代表的一类框架将最终渲染工作交还给了系统，虽然同样使用类 HTML+JS的UI构建逻辑，但是最终会生成对应的自定义原生控件，以充分利用原生控件相对于WebView的较高的绘制效 率。与此同时这种策略也将框架本身和App开发者绑在了系统的控件系统上，不仅框架本身需要处理大量平台相关的逻 辑，随着系统版本变化和API的变化，开发者可能也需要处理不同平台的差异，甚至有些特性只能在部分平台上实现，这 样框架的跨平台特性就会大打折扣。 

Flutter则开辟了一种全新的思路，从头到尾重写一套跨平台的UI框架，包括UI控件、渲染逻辑甚至开发语言。渲染引擎依 靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接口，可以在最大程度上保证不同平台、不同设备的体 验一致性，逻辑处理使用支持AOT的Dart语言，执行效率也比JavaScript高得多。 

京东的Taro、美团的MPVUE这些，又是在寻找APP与H5、小程序之间的结合点，通过语言或者工具的转换，从而实现一套代码满足移动端所有入口的体验。

几个想法：

1.android和ios的原生开发语言（android JAVA和OBJC），应该会逐步退居二线，甚至可能失业，因为在前端不会有重量级的业务逻辑层，一套MVVM前端框架+JS语言貌似就已经够用了；而与底层结合密切，涉及到高性能要求的（摄像头、视频编解码等）能力库，必然会用性能更好的C语言实现，通过JNI对外开放接口接即可；如果某个客户端想做成和原生界面相似的效果，就使用类似RN的框架，如果想做成多端统一风格的效果，就使用Flutter框架，而追随系统原生效果这个命题，也将越来越弱化（我要自己的个性，我自己的多端长得一样岂不是更好？），JAVA和OBJC会比较尴尬；

2.微前端有可能成为现实，用不同语言实现的各个模块运行在不同的容器中，一个APP中，DartVM上运行Flutter实现的业务模块，DavikVM上运行原生模块，各种形式的WebView容器中运行H5页面，系统级的Router负责统一的页面跳转调度；

3.前几年基于原生开发语言比较流行的热修复、模块化，后续会逐步成为各个框架的标配，热修复（动态更新模块）方面，大家也一定会想办法突破苹果的所谓政策管制，苹果可以考虑从前期审核的方式转变为事后追责处罚的方式，从而既能允许APP动态更新以保持足够的灵活性，也可以在APP违规（如上线后开发自己的支付入口，或上线更新部分模块搞***、暴力、***）后追责处罚。

来源：华为云社区  作者：霍向明201811