上个月开始，国内的主流技术网站开始在推荐NativeScrpit，"js+xml写跨终端app"、"原生体验挡不住"，很多网站都拿这个当做宣传NativeScript的噱头。最近比较悠闲，没禁得住诱惑，从早到晚看了快一周，简单的搭了一个小应用的界面。但是在这个开发过程中，总有些槽需要吐，不吐不快。下面说说从框架完整性、开发难度、实际开发过程几个方面谈谈我对这个新框架的看法。（不会介绍NativeScript的具体用法，想了解的请先移步官网）。
(NativeScript官网首页 https://www.nativescript.org/)
一、框架完整性
NativeScript主推的是用javascript语言写逻辑+XML写布局来实现跨终端App(即iOS、Android、WP)，但是目前只支持iOS、Android，github上看到说WP正在开发中，预计很快跟上。目前的NativeScript是beta尝鲜版，但是里面所提供的widget组件、layout方式让很多前端开发者看了之后磨拳擦掌打算拿这个干点儿大事儿。
其实是图样图森破。
1.与原生APP融合？No way
NativeScript和React不同，无法与原生项目融合，即你只能纯写个NativeScript的应用，不可能把它抽离出来作为某原生应用的一部分来出现。虽然说它和React的出发点一致都是"用Web APP的开发速度打造Native App的体验"，但是实际上，它算是鸡肋吧，我觉得拿它来写个展示App或者简单的应用还是不错的。
2.组件支持不够完善
其次，NativeScript中虽然已经支持了很多组件，比如说tabview、srcollview、button，但是提供的组件方法、属性过少，整个框架还不是很丰满。举个例子，（前端开发出身，app开发目前只接触过iOS），Button按钮我们肯定会经常给它设定背景，即图片按钮。比如下面这个：
原生应用里，比如我接触过的iOS里用属性肯定可以设置，前端用background-image也行。但是目前NativeScript里面Button是没办法设置背景的，只能添加背景色。所以要想实现这个按钮怎么办呢？我也是看了github上的demo才知道该怎么做的。既然是图片按钮，那就纯图片好了，所以上面那个按钮在NativeScript中XML布局里面的代码是这样的：
<GridLayout row="0" col="0" cssClass="crossBtn"> <Image url="~/app/images/cross-btn.png" stretch="fill" /> </GridLayout>
最外层封个Layout然后让图片填充，说是按钮其实就是图片。再举几个例子：statusBar怎么取消显示，我一直没有找到；文字不能加粗、不能更改字体；Label组件周边有一圈儿Margin始终干不掉；Search组件外层有灰色底色等。而且组件对于系统调用也不是很好，找了半天文档和博客也没见到怎么读取通讯录，目前系统调用就支持照相机、文件、定位。
所以我觉得，NativeScript如果不能在属性支持上做的更好，估计不会火太久。
3.XML解析引擎
第一天在写一个官方文档上的Dock布局时，布局出不来，跑起来模拟器之后页面空空的。看样是解析出问题了，回去看源码，结果发现是XML源码的问题。当时我直接从官网上粘贴下来的这段XML源码（http://docs.nativescript.org/ApiReference/ui/layouts/dock-layout/HOW-TO.html）：
可能大家看出来了，最后几个标签因为空格根本就没成对。我当时也把空格删了，自己手动改的对齐，还是不行。最后恰巧试出来了是标签内style和=直接的空格，也得删了，要不然解析为空。问了一下身边做安卓和WP的同学，说他们那边的XML解析不会出现这种问题。所以NativeScript的解析还是应该优化一下，就这个样子的话，框架内提供的XML解析引擎我也不敢用啊。
4.布局方式
作为一个忽悠前端写App的框架，没有好的布局支持怎么能忽悠住人呢。所以NativeScript在这方面做的还是不错的，支持了absolute、stack、grid、dock、wrap这几种布局方式，就体验来讲，本身做前端出身的，对几种布局都不太熟悉，上手开发之后grid用的最多，其中提供的*和auto解决了太多麻烦事儿。几种Layout之间混合嵌套使用，感觉不错。但是感觉XML嵌套层级太深了，比如写个留言板的样式，得内套4，5层标签。
（打算写一个纪念日应用 某页面的布局样式）
但是布局时候应该注意组件的大小声明，如果采用的是grid布局方式，*会帮助我们自动把组件占满剩余空间，而且支持2*：*这种比例模式。但是在Stack中需要设定元素的上下、水平对齐位置、有的控件还需要指明宽、高度。页面跳转使用的是frame模块的navigator方法，直接跳转到另一个page（page在这个框架中是布局的基础）。
5.事件和手势识别
作为一个APP开发框架，事件支持和手势识别少不了。事件绑定主要有两种方法，一种在XML中通过属性的方式写（记得在js中export出对应的函数），另一种是在JS代码中先getView拿到控件再给其添加事件。手势识别的话暂时支持tap、double、long tap、swipe、pan等几种，可以满足基本需求。
但是我在组合使用tap和long tap时发生了Bug。写了一个通讯录的demo，在listview中的单一条目上绑定了单击和长按两种操作，本意是单击打开编辑页，长按弹出删除提示。手势混用之后每次长按之后就会报错，不了解具体详情，但是怀疑是不是手势捕获做的有点问题，两个事件都被触发了？求详解。
6.项目编译
官网上推荐两种开发模式，一种是终端模式另一种是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...天猫据说已经用上了?!