你的位置:首页 > Java教程

[Java教程]whats 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开发者使用



更详细的说明可以参考我们文档中心对应的文档。