整个串口模块功能已经完成了。但需求又来了现在外接一个MCU模块与MTK也是通串口相连，如果我们要把代码变得更容易复用，新模块在更少的代码量上接入，那该怎么做呢。在蓝牙功能模块里我们通过测试后发现一个问题，如果中途有不正常关闭，再次启动就启不来了。这个问题是因为JNI的线程没有正常退出，程序退出后还在后台运行，影响一下次程序启动。
我们先回顾一下我们之前的程序架
很明显，我一架构我们无法拉入新的模块。主要原因是因为，我们只有两条主线，而且每一条主线都有逻辑操作。如果我增加模块就得从零开始写了，这样很麻烦，而且这么笨的做法连自己都觉得很愚蠢。
首先为了线程更安全和管理，我们把我们的线程移到上APP层，毕竟Java虚拟机有自己的回收，APP退出后或者崩溃后也有自己的处理回收机制。所以说，更安全一些。
在设计整个架构上我们想了很多方法，但是可能由于实现难度太大，或者由于思路分析不下去就放弃了。在设计的过程中主要遇到的问题是思路不清晰，一开始总是想在原来的构架上进行修改但是都不了了之。而原来的框架最大的问题是逻辑区分得不明确，数据流的流向也不明确。我们也去按功能去区分了一些源码，但还不是很清晰，至少头文件还是重复包含的，这就说明了块与块之间还是相互有联系的。
受Android系统源码的毒害，我们进入了一个误区就是，我们怎么想着让整个框架都是直线，尽量地把一些操作结合在一起。其实我们这是一个面向小范围的复用，如果我们硬是要把很多东西做利用，就要写更多的代码去支持这个想法，反而支持代码还多过要实用代码。或者说，把一些操作API和逻辑分得更开，即最下面的都是操作，上面的都是分析逻辑。但是我们这里有很多字符处理，这些处理放在上层反而不好处理。
我们主要的思路是：最底层的操作API共用，如module_open之类的，接下来就把按功能不一样的模块分开，但是这些功能模块要实现一个统一的结构体函数，再把这个结构体加入到唯一与Java交互的Jni层。整个框架要让Jni和Java只有一个接口就可以，避免会有很多Jni和Java类进行绑定。然后我们把以前Jni去调用Java的notifi函数改为Jni层提供一个函数供上层Read。这些就不要了Java层和Jni层相互交互，而难以把逻辑分开，也解除了Java和Jni要绑定和Jni也要往回查找Java函数这样一对一的关系。
所以我们最后的框架大体是这样的：
