1、问题描述

当前大屏主干需要投屏功能开机即可用，但是投屏本身需要的P2P模式与连接wifi的STA模式是冲突的（原因如下）

因此如何在时序上合理分配两者就成为了在不影响wifi的正常连接的前提下达成设计指标所必须考虑的关键点。不应在wifi框架层对其进行修改，这样会扰乱wifi的状态机，带来难以预料的后果，只能在业务层面优化，由应用层完成修改

 

 

2、核心思想

修改的核心主旨就是要确保miracast投屏需要的P2P模式和连接wifi的STA模式能够以我们预设的方案在合适的条件下开关

 

 

3、实现方案

（1）、手动连接

思路：这个可以在连接时先关闭miracast开关，等待连接完成再打开

方案：在wifi界面及wifi密码界面每次点击 "连接" 后通知launcher处于手动连接状态并关闭miracast，连接上会打开miracast，异常情况依赖于launcher的40s定时器自动开启。（通过事件订阅下发手动连接状态，通过isManualConnect的值维护连接过程中投屏状态不被其他操作所影响）

（2）、自动连接

思路：由于上层可以感知到当前wifi连接状态，也保存有已连接网络的列表，所以可以在每次网络状态为未连接状态时关闭miracast开关，等待网络连接成功再打开

方案：使用 "wifiManager.on(type: "wifiConnectionChange", callback: Callback<number>)" 监听wifi连接状态改变（轮询时间约为10~20s），每次连接状态为

断开时，都会查询当前wifi列表和设备已保存wifi的信息，同时判断设备是否有已连接过的wifi，若有则关闭miracast。当连接状态为已连接时，会执行打开miracast的操作并重置计数。

比较已保存WiFi列表是否较上次发生变化，若列表无变化则判断重连次数，当重连次数大于2次后，执行主动连接操作（调用connectToDevice连接wifi，最后不管连接结果如何都重置次数，通过isManualConnect的值维护连接过程中投屏状态不被其他操作所影响），若列表有变化则重置计数，执行第一次回连

（3）、保持投屏

思路：为了避免有连接失败导致投屏不能被打开的现象发生，设置一个定时打开miracast投屏的设定，检测到当前投屏是关闭状态时将其打开以保证投屏功能的正常使用

方案：每40s执行，先查询是否处于手动连接的状态，当此时miracast为关闭状态且不处于手动连接才打开miracast

 

 

4、各场景分析与测试用例执行

 

（1）、手动连接&&成功：连接开始时关闭miracast投屏，连接成功后打开（会被保护）

（2）、手动连接&&失败：连接开始时关闭miracast投屏（会被保护），这里连接不成功，所以不能依靠连接成功后打开投屏的逻辑将其打开，需要等待定期的投屏状态检测线程打开投屏

（3）、自动连接&&不被干扰：检测到需要自动连接时首先将P2P关闭，这里分为能连接上和不能连接上（例如密码修改），前者的话可以直接在连接上之后打开投屏，后者的话会无法连接成功，但是会等待定时检测投屏状态的线程将投屏打开，从而不会一直影响正常投屏。如果网络状态不再发生变更那么最多尝试两次回连（第二次是手动回连，这一次会被保护）然后除非网络状态发生变更，否则不会再进行回连的尝试，最后定时检测投屏状态的线程会把投屏重新打开；如果这中间发生网络状态变更那计数会被清除，在需要自动回连的场景继续进行最多两次尝试。

（4）、自动连接&&被打扰：如果本身是能够自动连接上的场景，那么即使被打断，手动连接本身也会携带关闭投屏和连接wifi的动作，等连接成功之后也会重新打开投屏，所以不影响。如果是连接不上的场景，那么逻辑上会先关闭投屏，等待手动连接先关闭投屏，如果手动连接成功那么投屏会再次打开，且之前的计数会被清除避免原来的回连尝试受到影响，如果手动连接失败那么无法在连接成功后打开投屏，只能等定时的投屏线程打开投屏

（5）、改名：由于P2P服务会一直运行，所以改名不会有问题

（6）、投屏保持打开状态：由于P2P服务会一直运行，而且会定期检查投屏状态，再加上自动连接关闭投屏不会一直尝试下去，所以投屏在稳定下来之后会保持打开状态

 

补充用例如下

 

 

5、总结

该需求在原理上实现起来并不复杂，难点在于如何设计确保投屏状态按照我们需要的逻辑保持开关，保证不会在时序上起冲突。