标签：
DeviceOne技术介绍
一． DeviceOne是什么
DeviceOne(以下简称Do)是一个移动开发的平台或技术，与之对等的是Android移动开发技术，iOS移动开发技术，Windows（phone）移动开发技术。我们可以从下面的图里看出他们之间的关联和区别
|
|
|
|
|
|
|
|
|
Android
|
|
|
|
|
|
|
|
|
iOS
|
|
|
|
|
|
|
|
|
Windows
|
|
|
|
|
|
|
|
|
DeviceOne
|
|
|
|
|
|
|
|
从这个表我们可以了解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开发者使用
更详细的说明可以参考我们文档中心对应的文档。
what's deviceone
标签：
原文地址：http://www.cnblogs.com/wjiaonianhua/p/5680199.html
