what's deviceone

DeviceOne技术介绍

一．     DeviceOne是什么

DeviceOne(如下简称Do)是一个移动开发的平台或技术，与之对等的是Android移动开发技术，iOS移动开发技术，Windows（phone）移动开发技术。咱们能够从下面的图里看出他们之间的关联和区别

	开发环境	IDE	开发语言	调试	API	编译	生成安装包
Android	Mac/    Windows	Eclipse/    Android Studio	Java	模拟器/真机	Android    SDK	本地	apk安装包
iOS	Mac	XCode	Object C/Swift	模拟器/真机	iOS    SDK	本地	ipa安装包
Windows	Windows	Visual Studio	C#	模拟器/真机	Windows    SDK	本地	appx安装包
DeviceOne	Mac/    Windows	DeviceOne Studio	JavaScript/Lua	Android支持模拟器/真机，其它只支持真机	DeviceOne SDK	云编译	同时生成apk, ipa和appx安装包

 

从这个表咱们能够了解Do的特色:

1.  移动App开发过程的全部阶段Do都介入：编码—调试—编译—测试—发布。在任何一个环节都有对应的产品和服务来对应。

2.  使用Do开发App彻底不须要了解其它三种技术的细节

3.  使用Do开发须要了解Do的基本框架和API

4.  使用Do能作到一次开发，多平台发布，Write Once，Run Anywhere

5.  使用Do开发App须要云编译，须要联网。

6.  使用Do开发使用JavaScript/Lua，相对于其它开发语言，使用更简单，更易理解

7.  Do平台具备本身的JS/Lua SDK，目前有大概100个组件，每一个组件都有2-3个平台的原生实现。组件还在不断扩展中。这个组件能够由官方来开发，也能够由任何有原生开发能力的开发者开发并分享。

8.  Do平台只是移动端开发平台，并无提供服务端开发的任何服务和技术。

 

 

二．     为何须要DeviceOne

既然不一样的移动操做系统有不一样的开发技术，为何还须要Do？Do是解决原生开发的二个重要问题：

1.  相同的业务逻辑须要在 iOS 和 Android 平台各实现一次，多套人，多套代码带来的开发，维护以及交流的效率和成本。除了开发成本高，也会引入体验的细微差异。是否有一种技术方案能够作到一份代码，两个平台运行，行为相同

 

2.   移动 APP 开发领域，要极致体验发布就不灵活（Native），要灵活发布就没有极致体验（H5）。有没有一种技术方案能够兼顾极致的体验和灵活的发布？

Do能很好的解决这二个问题。

 

 

三．     DeviceOne与其它跨平台的差异

国内外有很多相似跨平台的技术或多或少的解决这些问题，他们的差异是什么了？为何要选择Do了？

咱们能够把目前市场上跨平台技术分二类：

---- 以Webview加载H5为核心，以原生扩展为辅助的跨平台技术

这种技术国外以Cordova为表明，国内以AppCan，AppCloud，Wex5为表明的。这些技术的特色是：

 

1.  以H5为核心的web技术实现跨平台，对于熟悉web技术的人来讲，开发界面速度很快

 

 

2.  整个App的框架包括大部分的UI是由一个或多个Webview组件加载Html来实现，缺点就是体验，尤为是Android下体验不好。并且在不一样版本的Android下Webview的表现也有很多差别。

 

Do平台的性能咱们在后面会单独说明。

 

3.  整个App绝大部分的逻辑处理都是靠Webview里的html里的js来处理。这一块，性能相比原生差了不少。另外复杂度上高了不少，Webview只是原生众多组件中的一个，由它来支撑和控制整个App基本上很难，不少开发中的坑没法解决。

 

而Do平台利用JavaScript脚本语言只是桥接原生，绝大部分复杂的逻辑功能都封装在目前已有的100多个原生组件里。

 

 

4.  这种技术模式只能使用web已有的标签去模拟原生UI组件，包括不少交互操做，特别是原生最强大的动画都是靠模拟实现，效果可想。最为不方便的是只支持弹出一些原生的UI组件，而不能混合定制原生的UI，好比你不能在弹出的一个原生二维码扫描视图里定制任何的个性化。

 

而Do平台生成的App全部UI都是原生的组件，能够任何个性化的组合和个性化的设置。

 

 

5.  源代码没法作到真正的加密，由于原生的Webview组件加载的Html和js代码并不支持个性化的加密。这样会致使企业应用很难保证本身的代码和数据的安全。

 

而Do平台能够支持全部代码全部数据的个性化加密，详细的下面还会说明。

 

总之，我以为这种方式已经走到头了，这种方式作个原型做个demo很是好。做成熟想长期运维使用的app就是一个大坑。甚至害得国内不少开发者对国内跨平台技术的失望

 

 

----以原生Android,iOS, Windows技术为基础，以自定义标签加JavaScript为主的跨平台技术。

这种技术国外的以React Native，Xamarin为表明，国内的以阿里的Weex为表明。这种技术是属于新兴的技术。

这些技术的特色是：

1.  从新设计了一套相似H5的规范，并设计相似一个webview的组件来解析这套规范，包括ui和js代码，可是开发的规范和习惯都和H5相似，便于web开发人员的参与。

 

Do定义的ui并非相似h5，而是把ui代码和js/lua代码彻底分开成不一样的文件。Ui文件经过IDE的拖拽功能来实现，而后经过属性设置的方式，固然也支持js/lua代码访问，Do的方式更接近传统和原生技术的开发习惯。

 

 

2.  这些技术的体现都是一个原生的SDK，要开发一个完整的App，开发者仍是须要了解Android，iOS开发技术，仍是须要搭建不一样的开发平台，仍是须要不一样的开发人员去调试，编译，发布。只是让部分代码能够实现跨平台。

 

而Do对android，iOS，windows的移动操做系统的基础框架作了抽象，包括移动系统最基础元素Activity，UIViewCotroller之类的，也标准化了事件机制，存储管理，绑定机制，同步异步等等基础结构，彻底屏蔽了操做系统和对应开发技术的差别性。目标就是App开发者无需了解Android，iOS技术的细节，用一套代码实现真正的跨平台，write once，run anyway。

 

 

3.  Do提供一套自动化的屏幕适配，让开发者不须要在这个细节上作更多的考虑。

 

 

4.  Do最大的价值就是提供了一套组件重用的规范和标准，并且是跨平台的组件。咱们日常用原生开发不少都是最基础的代码重用，组件重用也仅限于单个平台。而Do的组件商店已经积累了快100个跨平台的原生组件了，是由Do官方和一些我的原生开发者开发的，有不少都开源了，你们能够参考。目前正在以收费组件的方式吸引更多原生开发者参与。

 

 

5.  Do产品化相对成熟不少，内部开发和使用已经1年，对外正式发布半年多，已经积累了不少企业应用，这几个月开始积累很多我的上线Appstore的应用，有一些成熟App已经开源，有不少示例Demo，有基本24小时的技术服务，已经逐步创建起一个移动开发的生态圈。

 

整体上咱们认为这种技术是跨平台的将来主流，但还处于初期，而Do已经走到的这种技术的最前沿。

 

 

四．     DeviceOne的产品组成

Do是一个移动开发的技术，包含了多个产品应用开发的不一样阶段

 

1.    IDE：Do提供了一个自主开发的集成开发工具DeviceOne Studio，利用Do开发App大部分工做都离不开这个工具。除了常规IDE的功能外，有几个显著特色：

       * Do Studio工具是基于EclipseRCP框架开发的，因此不少Eclipse的强大和扩展功能都支持

       * Do Studio支持UI界面的所见即所得的可视化拖拽和编辑，这个功能极大的简化了App的开发工做。

       附图是Do Studio的基本界面图：

       

 

2.   Do的核心框架，每一个Do生成的App都包含了这个核心框架，核心框架很是小，也就1M左右

 

3.   Do的组件商店里的组件，每个组件都对应android, iOS, Windows的部分或所有实现，部分源代码已开源

4.   Do的调试版本App，这个调试App能够安装到手机上，并和IDE创建局域网的连接，IDE上任何代码的改动均可以同步实时经过这个调试版本看到效果。

 

5.   Do的发布版本App，这个App就是最后给最终用户的安装包，包含本身的图标，签名等配置，可以上线到Appstore或其余App商店

      以上四个部分是有关联关系的，不论是调试App和发布App都包含了核心框架，均可以在组件商店里勾选部分组件生产安装包，结构参考下图：

      

 

6.   开发者管理服务

7.   开发者应用管理服务：用户全部的应用配置，应用安装包都保存下来，能够随时从新打包。可是咱们不提供源码管理服务。

8.   云编译打包服务：这个服务能够提供用户生成不一样平台下调试App和发布App的安装包。目前这个服务是公有云的服务，咱们能够为一些大型企业提供私有云的打包服务。

9.   开发者组件开发服务：若是开发者有原生开发能力，能够在这个服务里开发本身的组件，提供给本身内部或者分享给全部的App开发者使用。并能够以收费的方式提供。

10. 开发者技术支持，包括QQ，论坛，培训等

 

 

五．     DeviceOne的性能

 

跨平台是为了提升开发效率，随着带来的必然是性能的下降。但从软件发展的历史看，部分损失某一方面的性能来换取效率的提升仍是很是值得的。

 

Do相对纯原生有性能的损耗，可是相对H5就高不少，咱们用一些数据来讲明，都是相对原生多消耗的。测试的机型是Android的中等机型小米4，而iOS整体上都比Android性能要快一点。

 

----打开页面page1打开page2须要多消耗的步骤

1.  初始化JS引擎：须要100-200ms，可是初始化一次后就缓存了，并且这个缓存并非针对page1或page2来缓存，page2关闭本身后，page1打开page3也可使用这个引擎的缓存。Page1打开page3这个时间就基本为0ms了。

 

2.  解析ui文件和js文件获取文本内容：大概5k须要20ms，可是也是打开一次后就缓存了文本内容，下次这个时间就基本为0ms

 

3.  执行js代码：这个时间彻底看js代码里调用了什么原生API，由于绝大部分的逻辑都是在原生代码里执行，因此这里多消耗的时间也基本可忽略，下面咱们还会列出一些数据。

总之，一个页面初次打开平均会有30ms左右的延时，之后打开基本没有任何额外的延时。

 

 

----执行一个API比原生多消耗的步骤：好比咱们执行一个最简单的获取系统时间的函数

[mw_shl_code=javascript,true]var global = sm("do_Global");
  for(var i=0;i<100;i++){
      global.getTime();
  }[/mw_shl_code]

执行100次大概须要25ms，假设原生执行100次也须要5ms,也就是每一次执行须要额外的0.2ms。

而咱们常常点击一个按钮，调用的原生API也就几个，因此这里也能够忽略。

 

 

3.  执行一样的逻辑js相比原生的差别，android使用的是著名的v8引擎，ios使用的是系统自带的jscore引擎，这一块的速度也是很是快的。

咱们测算一下执行空的循环10万次，android的v8执行js代码须要10ms，原生大概5ms

 

 

整体上来讲，虽然咱们的测试还不够严谨精确，可是从数据上看性能的损失能够忽略，或者说对用户的体验没有影响。

其实更好的方式是下载已上线Appstore和Andoird商店的应用去体验一下，使用者从性能和体验上是分不出纯原生和Do开发的App的差异。

 

 

六．     DeviceOne的安全

跨平台技术都支持应用内升级，也就是能够动态修改和升级界面和逻辑，由于页面和逻辑代码其实都是字符串，因此安全性相对原生多了一个风险。

企业来讲，这种安全性是必需要考虑的。

上面提过，基于原生Webview+h5技术的跨平台没法根本解决这个问题，最多只能混淆或一些特殊的手段，可是利用一些简单的技术好比经过chrome的调试就能够轻松看到全部源代码。

 

而Do接管和控制了全部ui和js的解析，自然能够很轻松的使用加密算法加密全部代码。咱们的加密机制和开发者以及应用id绑定。而应用id是所有惟一的，只要开发者帐号没有泄露，其余人即便获取到你的加密过的数据和代码，也没法识别。

 

缺省的加密方式很简单，只须要在应用的配置的地方勾选代码加密就能够了。数据加密可使用特定的组件对数据额外的加密保存。

更多加密的说明参考咱们的文档中心。

 

 

七．     DeviceOne的组件扩展

Do并无脱离原生开发，只不过把原生开发和App开发者分离了，原生开发者只负责开发和业务无关的组件，好比Button，VideoView之类的。而App开发者不须要理解操做系统的差别，只须要参考组件的一套JS／Lua的API，而后专心整理本身App的业务需求，就能搭建出跨平台的App。

Do构建的平台也是积累和沉淀原生开发人员的技术的一种方式，并且是比代码级别更高级的组件重用，咱们提供了一个标准和平台，让原生开发者能够封装积累本身的技术，咱们的平台会保证质量。并且原生开发者在咱们的平台上销售本身的组件，App开发者购买使用组件开发App，从而促进一个完整的生态圈的发展。

组件扩展的基本过程就是

1.   咱们提供的组件开发管理界面上建立组件，定义属性，事件，方法

2.   定义完后，能够下载咱们自动生成的原生Android, iOS项目，不少代码已经自动生成

3.   开发者在这个项目里添加真正功能实现的原生代码，编译成jar包或者a文件

4.   上传jar包和a文件到咱们的平台，而后本身开发App使用或者分享到组件商店给全部App开发者使用

更详细的说明能够参考咱们文档中心对应的文档。