嵌入式linux之go語言開發（五）階段性小結

經一段時間的實戰，使用go開發嵌入式linux完全沒問題。

使用進階語言開發嵌入式，是一種享受!( 注:是嵌入式linux,而非記憶體和空間都很吃緊的嵌入式其他系統。)

速度，穩定性及開發效率都是最高的。

運作速度和穩定性不亞于傳統c語言寫的應用，但是開發效率絕對高出幾個量級。

舉個例子，假如你的c應用裡需要調用https的背景接口，協定格式是 xml 或者 json ,你會怎麼做？

用 c 可能一周，用 go 則隻需一天......

業餘幾天時間就已經做出來了個小應用。

功能:

可以支援銀行卡雙免https通信方式刷卡消費，二維碼掃碼消費。有界面顯示，語音播放，序列槽通信。

優點：

1.進階語言，強大。json格式，websevice對接都很easy,不用再去找開源庫openssl, 不用再去拼接json,拼接http頭。

2.運作速度快，穩定性高，開發效率高。

3.跟c語言聯系密切，調用c驅動非常簡單，這點非常适合嵌入式開發。

若系統是Android系統，選擇就更多了。

比如Hybrid App,React Native,阿裡的Weex,Google新出的 flutter架構，滴滴推出的重磅開源跨平台統一 MVVM 架構Chameleon等。

何為Hybrid App?

随着移動浪潮的興起，各種APP層出不窮，極速的業務擴充提升了團隊對開發效率的要求，這個時候使用IOS&Andriod開發一個APP似乎成本有點過高了，而H5的低成本、高效率、跨平台等特性馬上被利用起來形成了一種新的開發模式：Hybrid APP。

作為一種混合開發的模式，Hybrid APP底層依賴于Native提供的容器（UIWebview），上層使用Html&Css&JS做業務開發，底層透明化、上層多多樣化，這種場景非常有利于前端介入，非常适合業務快速疊代，于是Hybrid火啦。

Hybrid發家史,這一段摘自網絡，

最初攜程的應用全部是Native的，H5站點隻占其流量很小的一部分，當時Native有200人紅紅火火，而H5開僅有5人左右在打醬油，後面無線團隊來了一個執行力十分強的伺服器端出身的leader，他為了了解前端開發，居然親手使用jQuery Mobile開發了第一版程式，雖然很快方案便被推翻，但是H5團隊開始發力，在短時間内已經趕上了Native的業務進度。

使用Hybrid技術前要注意一個邊界問題，什麼項目适合Hybrid什麼項目不适合，這個要搞清楚，适合Hybrid的項目為：

① 有60%以上的業務為H5

② 對更新（開發效率）有一定要求的APP

不适合使用Hybrid技術的項目有以下特點：

① 隻有20%不到的業務使用H5做

② 互動效果要求較高（動畫多）

任何技術都有适用的場景，千萬不要妄想推翻已有APP的業務用H5去替代，最後會證明那是自讨苦吃，當然如果僅僅想在APP裡面嵌入新的實驗性業務，這個是沒問題的。

weex為何能夠做到跨平台呢？看官方文檔可看出它大緻的使用的技術。html,css,javascript,,vue.js,nodejs,webpack等。界面可以使用vue.js建構出各個UI元件，或者reaect等其他元件，不局限于vue.js。因為weex是一個架構，有自己的一套渲染引擎和SDK。抽象出native層提供接口api供js調用。畢竟像支付寶，微信等電商app,一個app中前端和後端的分量很重。真正調本機資源的，分量占比小。

ios的WebView的前端與Native的互動大緻可以有：1.URL Schema 2. JavaScriptCore（蘋果ios的javascript引擎，類似google的V8）。每種方式有什麼優勢，都是我們需要深度挖掘的。

Android中也可以使用url scheme或者webview有幾個方法可以專門可js互動，或者JSBridge，或者Native.js，或者還有其他的方式。

url scheme是一種類似于url的連結,是為了友善app直接互相調用設計的。具體來講如果是系統的url scheme,則打開系統應用,否則找看是否有app注冊這種scheme,打開對應app.這裡具體為app不會注冊對應的scheme,而是由前端頁面通過某種方式觸發scheme(如用iframe.src),然後Native用某種方法捕獲對應的url觸發事件,然後拿到目前的觸發url,根據定義好的協定,分析目前觸發了那種方法,然後根據定義來執行等。

Weex是一個使用Web開發體驗來開發高性能原生應用的架構。

Weex緻力于使開發者能基于當代先進的Web開發技術，使用同一套代碼來建構Android，iOS和Web應用。具體來講，在內建了WeexSDK之後，你可以使用JavaScript和現代流行的前端架構來開發移動應用。

Weex的結構是解耦的，渲染引擎與文法層是分開的，也不依賴任何特定的前端架構，目前主要支援Vue.js和Rax這兩個前端架構。

http://weex.apache.org/cn/guide/

頁面：首先移動應用應該可以被拆解成若幹個頁面，每個頁面相對解耦獨立，同時每個頁面都有一個 URL 進行唯一辨別。

路由：這些頁面将會通過路由機制有機的串聯起來，頁面之間的關系是通過路由來進行排程的。常見的移動應用路由包括導航欄、tab 切換等。

裝置能力：以各種 API 或服務的方式提供出來，供頁面自由使用。

微信的小程式,以及百度，支付寶的小程式是什麼？是怎麼做到的？他們也大都采用了這種形式來做到渲染一個應用。做到真正的跨平台和運作于微信，支付寶這個大生态之上。使用vue.js或者reaect等技術建構出的各個UI元件。js大行其道，發揮了很大作用。難怪說js是網際網路時代使用最廣泛最通用的語音，曾經被認為是腳本語音工具語言的javascript,不可小觑。

這點可以關注了解微信小程式和公衆号開發了解到。下載下傳Web開發者工具，https://mp.weixin.qq.com/，使用了javascript,Vue.js,html5,nodejs等技術

是以，隻有想不到的，沒有做不到的。一切皆有可能。

是以若在Android下局部使用go開發。也有另外好多種可能。

或者若界面不重要的場景下，這是前提，否則也得不償失。go+原生GUI來做（如直接用NDK的 OpenGL ES 位元組實作 UI.pos機上界面不花哨，畫一個也可以），或使用Dear imgui ，或者用go+html5,gomobile等來做。

兩款開源的GUI，LittlevGL和Nuklear

或者使用golang-ui。該項目為nuklear.h提供了Go綁定 - 一個小型的ANSI C GUI庫。 https://github.com/vurtun/nuklear

或者https://github.com/golang/mobile，當然這些目前都是實驗性質的，有待商賈。

具體采用哪種因情況而異。

網際網路巨頭由于是直面客戶，前端的占比很重，有獨立的前端開發和背景服務開發。後端服務使用java多一些。對go來說投入的精力不多。而咱們做pos的跟硬體結合緊密，界面不複雜，跟背景互動也不多，則可以考慮在go上花些功夫，做些研究。

對咱們pos機開發來說，前端和後端占比都不重。倒是經常調用本機的讀卡驅動，硬體資源等多一些。是以，Android系統直接用java+JNI就能搞定了，用html5那種混合開發反而走了彎路，得不償失。但考慮到pos的運作速度流暢度，穩定性和開發效率等方面原因，這種難道就是最優解嗎？

咱們沒準也能創新出一種基于go的新模式。

很多工作的意義，或者作用，是非技術同僚看不到的，但是如果我們不堅持做下去，迫于業務壓力或者自我松懈放縱，那麼就什麼也沒有了。我們要推動一件事情，不可能一站出來就說，嘿，小樣，我們這個不錯，你拿去用吧，這樣人家會猜疑你的，我們一定是要先做一定demo讓人有一定初步印象，再強制或者偷偷再某一個生産業務試用，一方面将技術依賴弄進去，一方面要告訴其他同僚，看看嘛，也沒有引起多大問題嘛

做事難，推動難，難在堅持，難在攜手共進，這裡面是需要信念的

-------------------------------------------------------------------------------------------

成功不是追求别人眼中的最好，而是把自己能做的事情做得最好。

每個人都應該有夢想，這才是生命的意義。

做事情貴在堅持，隻有這份堅持，才實踐了意義。

處處留心皆學問，愛學習，愛思考。

在這裡分享學習，分享感悟，共同進步。

凝聚學習的圈子，思考的圈子。

掃碼關注微信公衆号：aazhen1987

凝聚學習和思考的圈子。

--------------------------------------------------------------------------------------------