你的位置:首页 > Java教程

[Java教程]去它的h5,我还是用js写原生跨平台app吧


智能手机功能越来越强大,已经在逐渐替代电脑的作用。百度、腾讯、阿里的移动端日活数也在逐步的赶上甚至超越电脑端用户。叫喊着“mobile first”的公司越来越多,App开发者应运而生,且队伍日趋庞大,有的人以此为契机走上创业之路。

一、APP开发之殇

移动开发并未如想像般风光。

每一个原生应用开发的项目都是一个巨大的坑。要么等着竞争者通过移动互联技术把你打败,要么跳进坑自己招人来开发移动应用。写App真是一个苦B的差事。做一个App通常要配置三套人马,一拨人去做android,一拨人去做ios;如果还有网站的话,还需要另外配置网页开发人员,开发成本也随之加倍。最可怕的是,需要面对大量的黑屏、闪退、屏幕适配等底层技术陷阱。再加上技术人员流失更换频率较高,业务系统维护周期较长,操作系统平台升级后的兼容性问题(例如IOS7 UI布局结构的强制调整问题、IOS8的64位内核强制升级问题)。到处都是技术陷阱,这岂是每个小项目的成本能够承受的。

许多公司都是新成立的创业公司,能出得起钱配足三套人马的凤毛麟角。通常都是一个人干三个人的活。如果一个研发牛人又能搞android又能搞ios,马上就能成为香饽饽,到手工资大把大把地。

人员问题往往还不需要研发操心,但是开发过程中更会遇到开发维护成本高、难度大、操作系统版本众多适配难等等实际问题。那更叫人头疼!

 

二、H5的解决之道

HTML5标准终于通过了!很多人看到其在移动端“阳光灿烂”的明天。一套html5的代码可以适应android、ios、微信、web等多端平台。许多人叫嚣,未来移动跨平台开发是H5的天下!很多“砖家”也说,HTML5将颠覆原生App世界。

       基于此,催生了一批跨平台H5跨平台开发平台/工具:PhoneGap 、Appcan、HBuilder 、APICloud……

然而,事情真的像想象中美好吗?

 

之前哥相信了“砖家”的这些话,上了H5的贼船,结果苦B、趟坑的日子就来了……

       基于血泪的经验,H5应用目前还是存在如下问题:

 

1、H5存在天生的“性功能”障碍

“性功能”的说法是HBuilder的老总提出的。即:性能不如原生,工具不如原生、功能不如原生。HBuilder及一众跨平台开发商都宣称自己解决了这些问题。

H5发展如此多年,在老旧机器上,甚至在高端android4.2以下版本的机器上,卡顿非常明显。虽然近一年来,千元机硬件性能大幅度飙升,千元机也能买到8核了。但你写一个H5的app试试,未经过专业人员性能优化,开多了页面依然卡顿。

H5的应用有许多优化点,如果没有经历若干次趟坑经验,很难搞出性能很好的应用来。

别听很多跨平台开发工具商吹的天花乱坠,稍微复杂一些的APP卡顿就是卡顿,短期内还是无法解决。

 

2、存在源码泄露、黑客代码注入等风险

H5写的app,你只需要将安装包后缀改为 zip,解压缩后就能直接看到源代码,根本没有秘密可言。想想看,你花了好几个月披星戴月赶工出来的app,源码随意就能被人拿走,稍微修改后就能重新打包成新的app,你是什么感受?

更可怕的是,你应用的支付宝密钥、微信的加密key全部都直接暴露给破解者了……

有的跨平台开发商声称提供混淆加密的功能,但实际上根本没什么卵用。无论你怎么加密,浏览器显示页面之前就必须解密出来才能正常显示。而在android4.4以后版本上,连上电脑,用Chrome浏览器直接就能提取出app打开的浏览器中原始页面的任意内容,甚至可以设断点调试,用浏览器控制台随意注入代码。

 

3、控件稀缺,集成三方SDK困难

H5的app,如果有美术基础,用HTML描述界面很是便捷。但是如果你想调用系统的一些功能,则就需要看你的跨平台的工具是否支持了。一旦尚未提供,那就苦B了。

虽然好多开发商都声称,自己的工具很容易自已封装控件扩展。但费话,如果我会原生开发,还用你这工具干毛啊,哥直接写原生的啦。    

我之前就遇到这个问题,写一款APP,要用到第三方的SDK,而当前的开发工具没有提供此类控件,导致项目无法进行。之后每天都去开发商BBS、QQ群里求爷爷告奶奶的等待人家开恩,帮你提供。连续一个月,人家根本不鸟你,项目最后无奈告终。

 

         既然H5的跨平台开发还不靠谱,那怎么办呢?

 

 三、原生跨平台解决方案

(一)、React Native的解决方案

React Native的出现,让人感觉到惊喜。既拥有Native的用户体验、又保留React的开发效率。这个理念似乎迎合了业界普片存在的痛点,开源不到1周github star破万,目前是27000+。

React Native的原理是在JavaScript中用React抽象视图操作为系统原生的UI组件,代替DOM元素来渲染。它不同于webkit或任何我们已知的浏览器,采用自行封装的渲染引擎,渲染生成不同平台下的原生UI,同时JS和Native之间通过Bridge通信实现相应的功能。

这种技术将独立的界面描述文件与原生UI统一起来,个人认为它是已知中间件产品中最先进、最能代表未来发展趋势的方向。

 

React Native看上去很美,然而现实却很“骨感”。

目前,React Native使用中还存在一些问题:

1、界面布局困难

React native与HTML5无关。虽然它使用的语言还是javascript,它使用自定义的react方式去声明界面,没有HTML和css! 对于广大开发者,你的HTML和css白学了,重新学facebook的语法。

同时,react布局方式与之前传统观念差别很大,且没有可视化工具,如果想布局出一套复杂的的界面是非常费劲的。

2、安装包太大

React native是自己的渲染引擎,不是webkit或任何我们熟悉的浏览器。相当于是facebook的定制浏览器。引擎包的体积不小,hello world就是7M。如果实现一个中等功能的APP,十几兆的包是跑不了啦。

 

3、开发工具

React native没有配套的ide,开发调试非常麻烦。没有原生开发基础的话甚至可能搭不起来开发环境。

打包也不方便,没有mac电脑无法调试或打包ios应用。

 

4、 不符合国情

像国内开发一款App,嵌入一些第三方开发包那是再正常不过的事情。比如登录要嵌入微信、微博、QQ等第三方库,聊天嵌入环信,统计嵌入友盟,支付嵌入支付宝……

这些第三方库如何集成到React Native的项目里呢?如果你祈祷哪天facebook帮你集成好发布一些控件包的话,那你就等着去吧。

 

(二)、DeviceOne的解决方案

DeviceOne是一个新兴的移动跨开发平台。2015年5月份正式对外发布(他们网站SEO做的很烂,宣传也少,故目前还较少人知道)。

DeviceOne采用类似于React Native的解决方案。它已经提供了大量丰富的UI组件和API组件,这些组件全部都是货真价实的纯原生实现,而运行中的应用也是纯原生的UI呈现。你开十几个页面根本感觉不到卡顿。

平台下所有UI组件功能组件都已经被抽象成可被自由扩展的跨平台组件,就连Webkit本身在模型中也仅仅退化成一个普通的UI组件而已,App开发者可以自由选择js脚本、lua脚本来编写业务逻辑。只需要下javascript人员即可完成纯原生的app开发,做出的产品那个流畅啊……

研发人员可以选择要打包的控件列表,打出的包非常小,通常在3-5M以内。而且由于是原生app,代码全部做的加密处理,黑客无法简单的解压缩就能盗用代码了。

同时,DeviceOne实现了界面和业务逻辑的分离。UI可以通过IDE直接拖拽生成,那叫一个爽字!

所见即所得的界面

DeviceOne已经提供了80多个控件,不仅仅可以DIY出很炫的界面,而且还很接地气的加入了许许多多第三方SDK,很方便使用。像 H5 难以完成的媒体、影音的效果,用DO实现轻而易举。

另外,DeviceOne并不排斥H5。你完全可以把之前实现的 html 代码用 WebView 控件加载起来,实现了历史资产的复用,以及过渡。

官方提供了三个演示app源码:

更多演示源码可以在论坛里找到。

我下载看了这些代码后,大约在两天时间内就完成了上手。在实际使用其进行了一个APP开发后,开发过程中没有什么太多的坑,过程还是很美好的。

 

         只需用JS就可以写原生APP,哇赛,简直是太爽了。

         等有空时,我会写一系列文章介绍它,以及用它开发一款APP的整个过程,帮助同我一样有跨平台APP开发的人更方便的去开发。

         让我们一起用JS写原生APP吧!

 

 

转载自OSChina,原地址:http://my.oschina.net/qinerg/blog/624956?p=7#comments