上个月开始,国内的主流技术网站开始在推荐NativeScrpit,"js+xml写跨终端app"、"原生体验挡不住",不少网站都拿这个当作宣传NativeScript的噱头。最近比较清闲,没禁得住诱惑,从早到晚看了快一周,简单的搭了一个小应用的界面。可是在这个开发过程当中,总有些槽须要吐,不吐不快。下面说说从框架完整性、开发难度、实际开发过程几个方面谈谈我对这个新框架的见解。(不会介绍NativeScript的具体用法,想了解的请先移步官网)。javascript
(NativeScript官网首页 https://www.nativescript.org/)css
NativeScript主推的是用javascript语言写逻辑+XML写布局来实现跨终端App(即iOS、Android、WP),可是目前只支持iOS、Android,github上看到说WP正在开发中,预计很快跟上。目前的NativeScript是beta尝鲜版,可是里面所提供的widget组件、layout方式让不少前端开发者看了以后磨拳擦掌打算拿这个干点儿大事儿。html
实际上是图样图森破。前端
NativeScript和React不一样,没法与原生项目融合,即你只能纯写个NativeScript的应用,不可能把它抽离出来做为某原生应用的一部分来出现。虽说它和React的出发点一致都是"用Web APP的开发速度打造Native App的体验",可是实际上,它算是鸡肋吧,我以为拿它来写个展现App或者简单的应用仍是不错的。java
其次,NativeScript中虽然已经支持了不少组件,好比说tabview、srcollview、button,可是提供的组件方法、属性过少,整个框架还不是很丰满。举个例子,(前端开发出身,app开发目前只接触过iOS),Button按钮咱们确定会常常给它设定背景,即图片按钮。好比下面这个:node
原生应用里,好比我接触过的iOS里用属性确定能够设置,前端用background-image也行。可是目前NativeScript里面Button是没办法设置背景的,只能添加背景色。因此要想实现这个按钮怎么办呢?我也是看了github上的demo才知道该怎么作的。既然是图片按钮,那就纯图片好了,因此上面那个按钮在NativeScript中XML布局里面的代码是这样的:ios
<GridLayout row="0" col="0" cssClass="crossBtn"> <Image url="~/app/images/cross-btn.png" stretch="fill" /> </GridLayout>
最外层封个Layout而后让图片填充,说是按钮其实就是图片。再举几个例子:statusBar怎么取消显示,我一直没有找到;文字不能加粗、不能更改字体;Label组件周边有一圈儿Margin始终干不掉;Search组件外层有灰色底色等。并且组件对于系统调用也不是很好,找了半天文档和博客也没见到怎么读取通信录,目前系统调用就支持照相机、文件、定位。git
因此我以为,NativeScript若是不能在属性支持上作的更好,估计不会火过久。github
第一天在写一个官方文档上的Dock布局时,布局出不来,跑起来模拟器以后页面空空的。看样是解析出问题了,回去看源码,结果发现是XML源码的问题。当时我直接从官网上粘贴下来的这段XML源码(http://docs.nativescript.org/ApiReference/ui/layouts/dock-layout/HOW-TO.html):web
可能你们看出来了,最后几个标签由于空格根本就没成对。我当时也把空格删了,本身手动改的对齐,仍是不行。最后恰巧试出来了是标签内style和=直接的空格,也得删了,要否则解析为空。问了一下身边作安卓和WP的同窗,说他们那边的XML解析不会出现这种问题。因此NativeScript的解析仍是应该优化一下,就这个样子的话,框架内提供的XML解析引擎我也不敢用啊。
做为一个忽悠前端写App的框架,没有好的布局支持怎么能忽悠住人呢。因此NativeScript在这方面作的仍是不错的,支持了absolute、stack、grid、dock、wrap这几种布局方式,就体验来说,自己作前端出身的,对几种布局都不太熟悉,上手开发以后grid用的最多,其中提供的*和auto解决了太多麻烦事儿。几种Layout之间混合嵌套使用,感受不错。可是感受XML嵌套层级太深了,好比写个留言板的样式,得内套4,5层标签。
(打算写一个记念日应用 某页面的布局样式)
可是布局时候应该注意组件的大小声明,若是采用的是grid布局方式,*会帮助咱们自动把组件占满剩余空间,并且支持2*:*这种比例模式。可是在Stack中须要设定元素的上下、水平对齐位置、有的控件还须要指明宽、高度。页面跳转使用的是frame模块的navigator方法,直接跳转到另外一个page(page在这个框架中是布局的基础)。
做为一个APP开发框架,事件支持和手势识别少不了。事件绑定主要有两种方法,一种在XML中经过属性的方式写(记得在js中export出对应的函数),另外一种是在JS代码中先getView拿到控件再给其添加事件。手势识别的话暂时支持tap、double、long tap、swipe、pan等几种,能够知足基本需求。
可是我在组合使用tap和long tap时发生了Bug。写了一个通信录的demo,在listview中的单一条目上绑定了单击和长按两种操做,本意是单击打开编辑页,长按弹出删除提示。手势混用以后每次长按以后就会报错,不了解具体详情,可是怀疑是否是手势捕获作的有点问题,两个事件都被触发了?求详解。
官网上推荐两种开发模式,一种是终端模式另外一种是Online的拖控件模式。第二种的话是用的国外网站,编辑没有问题可是在线预览的时候我这边迟迟打不开,多是墙的问题吧。因此直接配了一套环境。环境配置仍是很快的。我在用的电脑是IMac,其中只须要经过npm安装几个包和nativescript就能够了,官网文档在这块介绍的很清楚。
NativeScript的编译运行过程大概是先读取XML布局文件、JS逻辑代码(主要是事件绑定和一些组件建立),再经过Module模块转化成原生的组件,实现刚才说的原生体验。同时在编译过程当中会根据以前在命令行中建立的平台版本生成对应的完整项目文件,好比我添加了ios,那么就会生成下面这个文件夹:
在终端里面建立一个项目的步骤为1.create命令添加项目 2.add命令添加对应平台 3.run命令在模拟器或真机测试。其中最后一步的时间,我这边Mac平时最少一分钟,最多两分钟多。整个步骤大概是先export又打包又启动模拟器,启动模拟器以后还有十几秒的黑屏(这个是模拟器的问题?)。因此通常写完以后一运行,好嘛,两分钟过去了。因此单纯经过终端来编译执行仍是挺痛苦的。
可是后来发现一个改进的办法,速度提升了不少,就是经过直接打开生成的xcode项目来编码。xcode项目目录下会有完整的app文件夹和module模块文件夹,因此不用担忧缺东西的问题,并且在xcode中编码还会有对应的调试输出,打开模拟器的速度也快了不少,这几天都这么干的。
项目调试的话这个框架没有给咱们提供太好的方案,以后console.log控制台输出和自动报错两种。不过这里面有个争议点就是若是你在css文件里声明了该控件不支持的属性,不如说font-weight的话,不会报错,也不会显示。我以为应该报错,给开发者明确的提示。内存管理的话,没有太研究,官网里提到说该框架都是“基于弱引用,因此请不要担忧内存泄露的问题”。
总结来讲,整个项目的完整性我以为只完成了70%,如今应该仍是迭代开发状态,不知道开发者们还在没在接着弄,若是上面几个问题得不到改善的话就真火不起来了。
不得不说官网的文档写的不错,按照入门helloworld教程、布局方式、组件使用和最后的API,总体写的很清晰。可是部分组件的具体调用方式写的很不详细。好比说SearchBar,文档里面没有给XML中如何声明,只给了个js代码new方法,害的我觉得搜索框只能经过这种方式来加入。结果后来偶然间尝试成功了,XML标签得写成<Search-bar>。并且文档里面对于不支持属性的解决办法也没有给,上面提到的按钮背景图片,很普通的技术点,不支持好歹给个解决办法啊。最后还得去github下载demo。
语言上的话,主要使用XML、JS和CSS。CSS没什么说的,记得有些属性自己是不支持的,别害的本身觉得本身是写法错误。
JS的话,文档里面给出的API调用还算详细。经过require的方式加载模块,每一个组件都对应了一个原生控件;new命令实例化控件;export命令来模块导出,所导出的函数、属性、数值均可以在XML中被使用。总体编码风格和node.js同样,做为前端写起来很顺手。Event事件模块的话,两种方式绑定。
毕竟刚开源刚受关注,国内资料暂时比较少,博客园里面几篇文章看了一下都是在教怎么配环境。
总结来讲我以为开发难度不大,仔细看看文档,写几个demo,搞清布局方式就没啥了。
说说我(一个web前端)在写上面的那个记念日demo的流程。demo只是写了写界面和简单交互,尚未网络请求代码。
1.明确布局样式,找好设计草图
2.观察布局,划分页面区域,好比使用stack仍是grid,使用什么组件
3.写page.js和page-view.js,封装实际函数,好比pageload事件、tap事件等
4.合并请求文件,写清页面跳转逻辑
5.修改图标和引导页
大概就是这样,上面那个页面写了不到一个小时,感受速度通常把。确定没有我用autolayout+拉线的方法快,可是写一次生成三个客户端,知乎里看赵望野的评价很好玩,“write once run every where的乌托邦梦想”。小应用的话这么干,我以为值。
NativeScript的学习过程仍是挺愉快的,算是接触了一下黑科技(alert和dialog弹窗的调用真的很方便,后台JS一个函数就搞定了)。体会的话,感受这东西仍是在发展当中吧,若是能有组件优化、性能优化、编译速度提升、争取像React同样融合的改进的话,我以为仍是有应用前景的。上面文章若有错误之处欢迎指正,若是哪位同窗有更好的看法或者作过Native Script的性能测试,欢迎讨论,必定仔细学习。
最后说下我以为可能适合的应用场景:
1.小李是大三狗,他选了一门移动应用开发的课,惋惜他每天去写PHP,没咋学会安卓开发。要交大做业了,怎么办?
2.小李是大三狗,他选了三门移动应用开发的课,分别是安卓、WP、iOS,要交大做业了,时间不够怎么办?
3.小李是软件学院X班的团支书,学院团委说要搞个团建,建立一个团建APP,这时候老师找到了小李
4.小王最近比较闲,忽然间据说有个东西叫NativeScript...
过几天去看看React...天猫听说已经用上了?!