John Lee

@ped2019-dev Sorry, I forgot to modify this copy demo. New code separates setDevie() and openSerial(). ``` public SerialPort open(String devicePath, String baudrateString) { mSerialWorker.setDevice(devicePath, Integer.parseInt(baudrateString)); try { return mSerialWorker.openSerial(); }...

@ped2019-dev You should change your mind and write your own code. Create multi SerialWorker instances at the same time. > https://github.com/licheedev/SerialWorker/blob/661363c3c55cd17596109eb48a0976f1cb3e8d78/app/src/main/java/com/licheedev/serialworkerdemo/serial/SerialManager.java#L74 Open these SerialWorkers later. > https://github.com/licheedev/SerialWorker/blob/661363c3c55cd17596109eb48a0976f1cb3e8d78/app/src/main/java/com/licheedev/serialworkerdemo/serial/SerialManager.java#L124

@ped2019-dev DoorSerialWorker and CardSerialWorker are just demo codes, they are not for common usage. Imitate and impletement your own `SerialWorker`s、`SandData`s and `RecvData`s.

测试了一下，强制使用 recyclerview 1.0.0版本，才能一步到位触发下拉，改成1.1.0都不行 ``` configurations.all { resolutionStrategy.force 'androidx.recyclerview:recyclerview:1.0.0' } ```

发现新的问题，SmartRefreshLayout嵌套CoordinatorLayout的时候，上拉加载会很诡异。  图上的界面布局层次是这样的： ``` SmartRefreshLayout CoordinatorLayout FrameLayout RecyclerView ``` 具体现象描述大概是： 1.当手指按住滑动到列表底部时，继续上拉，不出现footer，需要松开手指再滑动，才会出现footer； 2.当惯性滑动(fling)列表到底部时，在短时间内按下手指往上滑动（多次重复松开再滑），无法拉出footer，需要松开手指完全停止操作，等待大概1秒，然后往上滑动列表，才能拉出来footer。

> 可以留意一下具体复现的操作，便于排查问题 昨天看到服务端有新的提交，我试着替换了下重新运行了大半天，暂时没复现25%占用的问题，但看着版本号没变，不晓得是不是程序修复了。 还有不知道跟网速有没有关系，所在的出租屋共用一条宽带，邻居不知道做了什么，他一下班回来网就很容易卡，卡到连打开个百度都失败的那种，前晚出现25%占用的时候，网就卡过一阵，不过昨天网很流畅，可能邻居回家过年了。

> > > 可以留意一下具体复现的操作，便于排查问题 > > > > > > 昨天看到服务端有新的提交，我试着替换了下重新运行了大半天，暂时没复现25%占用的问题，但看着版本号没变，不晓得是不是程序修复了。 还有不知道跟网速有没有关系，所在的出租屋共用一条宽带，邻居不知道做了什么，他一下班回来网就很容易卡，卡到连打开个百度都失败的那种，前晚出现25%占用的时候，网就卡过一阵，不过昨天网很流畅，可能邻居回家过年了。 > > 的确，当网络慢发送数据无法确保到达时，系统会尽可能重试，期间cpu会有增高现象，一般这种情况基本不会持续太长时间。建议再观察一下。 又用了几天，还是有这个25%占用的问题，有时候甚至服务端的进程自动就挂掉。 前几天服务端的进程就挂掉过，因为我宿舍和老家都部署了蒲同英P5，现在回老家了，用不着smarGate，就一直没重启服务端。 几个小时前心血来潮，运行了下服务端，手机切换流量上网，运行smarGate App，用jellyfin看了几个视频(映射的是tcp协议)，然后杀掉了smarGate App，几个小时后，VNC看一下win7虚拟机，果然又25%占用了，这时候启动smarGate App，app上找不到win7虚拟机上的服务端，杀掉服务端进程并重新运行，app上才刷新出服务端。 这时候出租屋的邻居应该都回家过年了，网络很流畅，应该不是网络卡顿的问题。感觉这bug出现得很频繁，P2P打洞成功后，随便看几个视频，杀掉手机app，放置一段时间，就大几率异常占用25%。  

这demo是google原代码自带的，我没改过里面的代码。 https://github.com/licheedev/Android-SerialPort-API/blob/0e329bec294043c8c47e0ba7a8a9c0e5f732ef2b/sample/src/main/java/android/serialport/sample/SerialPortActivity.java#L46 如果是这个demo的话，改大这个数组的容量看看。 > 我修改size = mInputStream.read(received); 成size = mInputStream.read();以后收到的全是000000000000000000000 你下面改的是读取一个字节，到size变量里，size变成读取到的那个字节的内容了，而不是到读取到的数据长度。 received数组压根没参与，内容没改变过，当然是默认初始化的全0。

不要期待一次性就能把串口传输的数据读全的，我试过对接一个波特率只有4800的项目，每次read只能读到1个有效字节，解决方法是把读到的数据全缓存到一个大数组里面，然后按照具体协议进行分包。