经一段时间的实战，使用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让人有一定初步印象，再强制或者偷偷再某一个生产业务试用，一方面将技术依赖弄进去，一方面要告诉其他同事，看看嘛，也没有引起多大问题嘛
