flutter通讯,flutter通讯录

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

flutter udp通信 16进制 byte数据一些操作

ps：使用flutter开发app 与设备硬件交互要求使用udp通信

flutter UPD通信基于这大神的文章下进行修改的。

数据结构

flutter 数据结构中

Uint8List是一个固定长度的8位无符号整数列表。（感觉跟byte类型差不多都是占用1字节 0-255）

1. Listint 或 Uint8List转 int 要注意list的高低位

int byteToNum(Listint list) {

Uint8List resultList = Uint8List.fromList(list);

ByteData byteData = ByteData.view(resultList.buffer);

print(byteData);

return byteData.getInt16(0);

}

2.将字符串转成listint 并指定长度（字符串占用的字节）

3. 10进制int 转 16 进制listint。

其实这里应该是uint8list的。1字节。length 字节长度

设备正常使用有问题的方面。欢迎大家指出

相关问答

Q1: flutter 蓝牙开发遇到的坑

flutter 蓝牙开发遇到的坑

最近在做个flutter蓝牙功能，用的flutter_blue,在iOS上没有任何问题，照着例子写完，正常运行蓝牙功能，但是在安卓上发现各种坑，用这个插件首先是有些设备拿不到设备名称，还有就是读写特征和ios上拿到的也不一样。折腾好久，最后在github上找到外国友人给出的方案，就是用flutter_bluetooth_serial这个插件可以解决以上问题，就试了一下，结果真可以解决问题，而且这个用法感觉比flutter_blue 更强大，不需要通过读写特征值进行通讯，直接就能通过connection写入和接收数据。做下记录，希望能帮到有同样问题的人。因为我在遇到问题时，百度了全是不能解决问题的办法。

Q2: 做混合的话Uniapp和Flutter我应该学哪个啊？

Uniapp目前比较成熟，而且用的是Vue语法，学习成本比较低，而且行业里面用的也比较广泛，而Flutter的话，学习成本略高，因为要学习新的语言，还有就是目前生态不是特别完备，等他再发展发展吧。黑马程序员官网有成套免费视频哦，有什么不懂的可以直接过去学习。您的采纳是对我成长的鞭策

Q3: 桌面端开发都用什么语言，简单分析下这些语言的优劣势对比？

目前，最优的选择有四个：

1.如果只在win下使用，.net form是不二选择，可谓是又快又好，企业应用或定制开发都是相当好的，初学者也可以入手。

2.electron，跨平台。需要会前端，必须熟悉js、css和html。属于前端人员大杀器，如果是初学者，需要一下子学三样东西，再加上electron的进程间通信，可能会被搞懵。

3. qt5，可以使用qml（js语法）进行UI编程，但是需要懂c艹，但是写软件相当快，还可以写安卓、ios、Linux、嵌入式中的应用。

4.flutter，刚刚正式支持win平台的软件开发。谷歌出的这个东西，适合没有基础的初学者，因为是一个全新的体系，全新的语言，写ios、安卓非常高效，之后还会兼容h5。如果是初学者可以跟着走，值得尝试。但是新东西总有一些坑。

正式项目跨平台建议electron或qt，只用win平台强烈建议微软自己的net。个人技术尝试建议flutter。

桌面端开发跨平台的，如果你是轻量级的项目，那么我推荐你用electron, 目前使用Electron来开发的桌面应用非常多，我们最熟悉的比如Atom,VScode等等。

而且在github上也能找到许多应用使用了electron。

electron是Node，Chromium,html,css,js的结合框架，这就需要你有一定的前端基础。其实只需要了解一下electron的API就行了，其他的就像你在做web是一样的。

这种方式最大的缺点就是性能，还有透明窗口也有问题。所以在做需要性能方面占有很大成分的项目时，并不推荐使用这个方式。

那么其他的，就是最近几年使用比较多的windows directui框架，但它不是跨平台的。

那么就引出了qt，作为c++跨平台的界面框架，这个上手的话，我觉得对一般人是有难度的，因为首先需要扎实的c++功底，其次你要熟悉控件的制作原理，因为有时候你需要定制自己的UI控件。它现在在嵌入式，军工领域非常受欢迎。但是整个库非常臃肿庞大，而且开发界面的效率也非常低。如果来做互联网项目，迭代更新的速度根本就跟不上。

目前都只有大公司会采用，像maya这种生产力型的应用很多是qt做的。

还有一种是直接使用Cef加js，比如网易云音乐，就是这么搞的，但是很多和系统平台的交互接口你需要重写，等于是需要自己造轮子。工作量大，目前没有适合的框架给你套用，也需要扎实的c++功底。

其实pc端的应用基本也就windows会火一些，再加一个macos，那么选择qt应该会很好一点，毕竟你自己造一个跨平台的框架，太费时。总之，做跨平台就意味着，不可能做到既有效率又完美的实现各种功能，许多都要自己摸索。

win桌面端直接上visual studio啊！然后你熟悉什么语言？vb.net，c#，c++都有相应的win桌面工具。直接用就好了，非常好用

编程语言这种东西无所谓，只要能用啥都可以。主要看你老板需要和你会用什么语言。

比如我用AS编安卓程序，当然用JAVA。不过我后台最开始用ASP和ASP.NET来做，现在换PHP了。桌面端用QT或者VB做。涉及单片机部分控制也用C。

现在做跨平台的了开始以QT为主了。

只要能达到目的啥都可以。

学会1-2种换其他的也不是很难。

对初学者来建议学C起步吧。

精通一门，重新学个语言入门也就1个月的事。

PC桌面程序，如果简单一点的，用pyqt5+python的开发难度和周期都比较现实一点

会C++ 用Qt5 非常不错写代码效率很高

会js 用atom使用的那个框架

会Python用PyQt 写代码很快

会java用JavaFX

看语言咯

还可以用delphi，其firemonkey框架发布8年时间，支持跨平台：win，安卓，ios，macos，linux，后续支持webassembly，界面是控件拖拽布局所见即所得，开发效率较高。编译生成的是机器码，编译速度快，调试方便，其生成机器码运行效率较高，支持x86，arm的32位64位处理器。支持跨平台3D界面，蓝牙通讯，定位，重力，摄像等，支持多种SQL,NoSQL数据库。单个开发工具实现前后端开发，跨平台开发。适合个人和小公司用一套工具实现大部分开发需求。

主要有以下几种技术

### Duilib

#### 简述

Duilib是在Windows平台上使用最广泛的类库，使用C++和XML混合编程，国内很多计算机企业都喜欢使用这个类库，可能是由于他的技术许可比较宽泛的原因。

适合于界面比较简单的软件，视觉特效丰富，局限于Windows的平台。例子：360电脑管家。

#### 优势

#### 劣势

### Gtk、Qt或WxWidget：

#### 简述

三种基本可以做到跨平台的技术，使用C/C++开发，使用者广泛。其中WxWidget使用了API嫁接方式，Qt和Gtk（包括各种绑定技术）使用自绘技术。

结构严谨，软件可以做的很大很复杂。例子：WPS和Maya。

#### 优势

#### 劣势

### Electron：

#### 简介

使用Web技术开发桌面软件，基于Chromium（Chrome）引擎，使用JS编程语言，绝大多数使用者都是原来的网页开发者。

绝大多数都是爱好者使用，处于“勉强可用”的地步。

适合大面积静态展示型软件使用。例子：网易云音乐。

#### 优势

#### 劣势

### QtQuick（QML）

#### 简述

Qt公司开发的一款基于OpenGL的图形类库，有显卡加速，类似于Duilib。采用了C++与QML混合编程。QML类似于JavaScript语言。

QtQuick下一个版本在Qt 6上更加强大，业界期待已久。

#### 优势

#### 劣势

### Atk、Swing或JavaFX

使用Java语言开发软件，有JDK加持业界积累的众多Java类库支持。有不输于VS的IDEA加持，本应该更棒，只是现在已经式微了。

绝大多数使用者都是企业开发（不追求界面美观）、爱好者（开发顺手）。

### WinForm、WPF或Xamarin：

使用C#开发，WinForm和WPF局限于Windows平台。有VisualStudio加持使用很爽。

### Flutter:

使用Dart语言，新类库，bug可能会很多。

### SwiftUI或Cocoa：

苹果平台原生界面技术，macOS平台内建支持，不是macOS专用软件不推荐。

### Win32：

经典Windows 平台API，绝大多数只有一些老软件还在使用，不是维护老软件不推荐。

winform,不二选择

webview2，作为一个浏览器控件嵌入在桌面应用中，支持.net core和.net framework

Q4: uniapp即时通讯需要后端吗

uniapp即时通讯不需要后端。即时通讯软件，能为uniapp实现商城系统信息数据同步采用，socketioclient通讯协议来进行通讯、自动回复、数据分析、用户管理等功能。

uniapp小程序

uniapp现在确实很火啊，简直是多端小程序的福音，上手也快，主要是组件确实多，而且做一些非硬件类以及捆绑特殊sdk的app也很快。原生app的市场真就被蚕食太多了。

HBuilder装机量800万台足见目前的开发者用户量了，比flutter容易上手。uniapp跨平台程序，微信小程序，支付宝小程序，字节跳动小程序，等等小程序，跨平台不支持引入jQuery等操作DOM的插件，但可以通过操作数据的长度，判断是否spu属性选择完毕。

Q5: 鼎力推荐github 6.7k star开源IM项目OpenIM性能及消息可靠性测试

先说结论，对于容量和性能：

服务器资源： 8核16G内存， 6个机械磁盘，每个磁盘100G，用于mongo分片，10MB带宽。

容量：用户容量10万以上，消息条数10亿条。

性能评估：同时在线用户10万，每秒钟发送消息900条，消息延时1秒（从发送者发出消息到接收到消息）

启动sdk，模拟50个用户在线、离线情况，消息可靠性100%。

发送10万消息，有3条失败，其他消息都能被对方精确收到，并成功落地本地db。对于失败的3条消息，接收方确实没有收到，系统消息是一致的。

OpenIM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包括IM服务端和客户端SDK，是一套整体的解决方案，代码开源，一切可控，

OpenIM可以实现全平台支持，目前支持Android，iOS，Flutter，Uni-app，react-native, JSSDK等。

OpenIM可以应用在企业内部办公，dating交友，在线客服等项目，也可以用于元宇宙。

github地址：

开发者中心:

在单机的情况下，模拟线上用户发消息流程，在线用户量和消息量达到一定量级后，系统CPU、内存、磁盘占用、以及消息时延情况。以确定用户群体达到一定量级后，对服务器资源的预先评估。本次测试并不极限测试，一是因为生产环境本来都会有用户量和消息量的限制，二是因为OpenIM的消息模型，消息发送首先都会通过websocket入库kafka，理论上发送消息的写入性能是两者的组合，而消息发送的真正瓶颈实际在mongodb的随机读写。

服务器资源：腾讯云主机（香港）1台：linux Ubuntu 18.04.4系统，4核8G内存，单块机械硬盘。5Mb带宽。

测试条件：去掉消息入库mysql（因mysql仅用于管理后台，不影响线上用户服务）。日志级别调整为4或更低。kafka设置2个分区，msg_transfer 2个。

测试流程：1个客户端（成都，window pc，4核16G内存）启动1万个协程，模拟用户与服务器建立websocket长连接，间隔时间为随机50-100秒之间。两个客户端共模拟2万用户同时在线，发送消息，观察消息流转各个模块的处理能力，共计2500万条消息，观察系统内存、磁盘资源使用情况。

mongodb数据情况

redis数据情况

磁盘状态

资源占用分析

（1）redis内存消耗极小，一个用户一条数据（包括token和seq），和用户量成正比，3万用户占用几十M内存。

（2）mongodb如果去掉cache，内存消耗极小，每个document存放5000条消息，与用户量和消息量成正比，3万用户，2500万消息，索引才950K（更好的方式查看mongo消耗cache之外的内存）

（3）2500万消息，磁盘空间占用10G。

（4）每秒钟150条消息，cpu整体占用50%，即2核。

性能分析

（1）性能瓶颈在mongodb写入操作，1条消息，需要按照发送者和接收者拆分2次，mongodb写入2次，未来可以针对mongodb读写进一步优化。

（2）对于cpu消耗较大的模块，未来做一次整体优化。

（3）性能很平稳，不会随着数据量增加而降低。机械磁盘iops 达到200基本达到了设备的极限

服务器资源： 8核16G内存， 6个磁盘，每个磁盘100G，用于mongo分片，10MB带宽。

性能评估：同时在线用户10万，每秒钟发送消息900条，消息延时1秒（从发送者发出消息到接收到消息）

（1）mongo集群部署，支持上亿用户同时在线，千亿级消息；

（2）简化集群部署；

（3）数据备份、恢复工具；

以上主要对服务端性能做了一个大致测试，但一套完整的IM解决方案，不仅仅是服务端的工作。实际上，客户端重要性毋庸置疑，具体包括如何利用seq和服务端同步消息，如果保证消息收发的时序，如何回调客户端（会话改变、新增，新消息），消息落地本地db，seq同步，消息推拉如何结合以确保消息收发可靠性。

相比于性能测试，实际上，消息的可达性（可靠性）更为重要。所以，我们在做性能测试的同时，也要对消息的可达性（可靠性）进行测试，如果不能保证消息收发的正确性，再高的性能也是徒劳。本文重点总结关于OpenIM对于消息可达性测试的方案、过程以及结果。先说结论，OpenIM消息可达率100%，大家可以放心使用在生产环境中。seq对齐和同步机制，保证了OpenIM的消息可达性是业界领先的。

IM消息系统的可靠性，通常就是指消息投递的可靠性，即我们经常听到的“消息必达”，通常用消息的不丢失和不重复两个技术指标来表示。确保消息被发送后，能被接收者收到。由于网络环境的复杂性，以及用户在线的不确定性，消息的可靠性（不丢失、不重复）无疑是IM系统的核心指标，也是IM系统实现中的难点之一。总体来说，IM系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令和通知，包括但不限于进群退群通知、好友添加通知等，为了方便描述，统称“消息”）。

从消息发送者和接收者用户行为来讲，消息“可靠性”应该分为以下几种情况：

（1）发送失败，对于这种情况IM系统必须要感知到，明确反馈发送方。如果此消息没有发送成功，发送方可以选择重试或者稍后再试。

（2）发送成功，如果接收方处在“在线”状态，应该立即收到此消息。如果接收方处在“离线”状态不能收到消息，一旦上线则立刻收到消息。

（3）消息不能重复，用数学术语表示：“有且仅有这条消息”，如果重复了，可能表达的意思就变了。总之，一个商用 IM系统，必须包含消息“可靠性”逻辑，才能谈基本可用，这是IM系统最基本也是最核心的逻辑。

互联网真实场景复杂，但客户端大体可以分为两种情况：（1）发送消息时，接收方在线，能收到消息；（2）发送消息时接收方不在线，登录后能收到离线消息。我们用测试程序模拟互联网客户端各种场景，按照登录、发送消息、接收消息的情况，把测试客户端分为以下2种类型：

（1）启动测试时离线，随机sleep 0-60 秒后登录，发送消息，且接收消息

（2）启动测试时离线，随机sleep 0-60 秒后登录，不发送消息，只接收消息

在实际测试中共计50个客户端，约25个（50%概率）客户端不发送只接收消息，约25个（50%概率）客户端发送且接收消息。

发送模式：每个客户端随机选择其他客户端作为消息接收者；

测试预期：每一条发送成功的MsgID，都能在接收的消息列表中找到，同样，每一条接收到的MsgID，都能在发送成功的消息列表中找到。

具体做法：（1）消息发送成功后，通过OnSuccess回调，记录MsgID；收到新消息后回调OnRecvNewMessage，记录MsgID；（2）周期性对比两个消息列表，确认是否完全一致；

发送数据100000条，其中失败3条，9999997条成功，接收方成功接收9999997条消息（接收方成功接收到消息，写入本地db，并能触发消息回调）