经测试验证，使用go开发嵌入式linux完全可行。 速度，稳定性及开发效率都是最高的! 业余几天时间就已经做出来了个小demo。 功能: 可以支持银行卡双免https通信方式刷卡消费，二维码扫码消费。有界面显示，语音播放，串口通信。 优点： 1.高级语言，强大。json格式，websevice对接都很easy,不用再去找开源库openssl, 不用再去拼接json,拼接http头。 2.运行速度快，稳定性高，开发效率高。 3.跟c语言联系密切，调用c驱动非常简单，这点非常适合嵌入式开发。 但是，也有缺点。目前我们暂不考虑用。但若是新项目可以考虑使用。如果没有以下顾忌，完全可以大胆用。 我们不考虑用的原因是： 1.体积包比原来大了10倍左右。原来1兆多现在十多兆。会使应用升级耗流量，升级耗时间。目前流量还是有限(次要原因)。 2.比较关键的原因是 我们使用go的人员太少，大都是嵌入式c的开发者，没人来维护。让现有人员维护，他们还需要花时间成本去熟悉go语言。 3.比较关键的原因是我们老的项目太多，代码和业务太多，若完全移植过来也是个麻烦事。且后续会有新产品推出，再花时间在这上面意义不太大。 若从头开始，用go是正确的选择。 若系统是Android系统，现在使用java也未必是首选，还有其他的方式也可以考虑。 比如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 adnroid的开发方式。 具体采用哪种因情况而异。 互联网巨头由于是直面客户，前端的占比很重，有独立的前端开发和后台服务开发。后端服务使用java多一些。对go来说投入的精力不多。而咱们做pos的跟硬件结合紧密，界面不复杂，跟后台交互也不多，则可以考虑在go上花些功夫，做些研究。 对咱们pos机开发来说，前端和后端占比都不重。倒是经常调用本机的读卡驱动，硬件资源等多一些。因此，Android系统直接用java+JNI就能搞定了，用html5那种混合开发反而走了弯路，得不偿失。但考虑到pos的运行速度流畅度，稳定性和开发效率等方面原因，这种难道就是最优解吗？ 咱们没准也能创新出一种基于go+html5的新模式(html主要解决界面显示问题)，有待探索。 很多工作的意义，或者作用，是非技术同事看不到的，但是如果我们不坚持做下去，迫于业务压力或者自我松懈放纵，那么就什么也没有了。我们要推动一件事情，不可能一站出来就说，嘿，小样，我们这个不错，你拿去用吧，这样人家会猜疑你的，我们一定是要先做一定demo让人有一定初步印象，再强制或者偷偷再某一个生产业务试用，一方面将技术依赖弄进去，一方面要告诉其他同事，看看嘛，也没有引起多大问题嘛 做事难，推动难，难在坚持，难在携手共进，这里面是需要信念的