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

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

不管是最早的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

发布了981 篇原创文章 · 获赞 5378 · 访问量 77万+
展开阅读全文

没有更多推荐了,返回首页

分享到微信朋友圈

×

扫一扫,手机浏览