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開發者使用

更詳細的說明能夠參考咱們文檔中心對應的文檔。