AT的URC处理效率问题

[jpsn123]

https://github.com/RT-Thread/rt-thread/blob/bb66d1ea50f51e28c930abe1159b593ed8fabbdc/components/net/at/src/at_client.c#L688

这里底层设备IO单次只读1字节，且每个字节都会进行URC表查找，这样的效率是不是太慢，如何RT

[illusionkiller]

因为这里需要采用流模式分行处理比较合适一些，且不是每个字节都查找，而是确定为新行数据和尾缀条件之后才会去查找

[Johnie9]

我以前也是看到这个at client的代码觉得太低效了，后来自己重新实现过， 不这样做的话，只能读取完一行再进行查找，但是如果URC一行很长，你需要一个非常大的接收行缓冲区，然后还要把这个拷贝到上层，空间占用大，每个字节都进行匹配可以小行缓冲区，匹配到之后，可以在回调中调用at_client_obj_recv将剩余数据读取到上层。也说不上好坏，只是选择不同而已，真正低效的是在读取行之后又重新进行urc匹配，如果本身上面就是urc匹配到的结果，再匹配一次没有任何意义，应该将at_recv_readline中匹配到的urc传出来，后面直接用，还有就是urc匹配里面每次都去算字符串长度属实是没必要。另外就是每个at_client都开一个线程，实际上多个at_client是可以用一个线程就解决的