mcufpga卡顿

Posted 2023-05-06

mcufpga卡顿原因：mcu和 fpga同频设备的干扰

1、无线wifi信号源太多，造成干扰

　　现在几乎是家家都有 无线路由 ，每个公司及 办公室 都有可能布置无线路由器，有的还不止放一个。用手机搜索wifi信号，动不动就可以找到十几个。这样情况下比较造成相互之间的干扰。

　　现在的无线路由器一般工作在2.4Ghz和5Ghz这两个频段，大部分是2.4G的。许多路由器出厂默认的信道设置成1或者6。这样同频同信道之下，就非常容产生干扰。就像同波段声音的干扰结果类似，会很多杂音、噪音出来，听不清楚。wifi干扰之后就是上网数据丢包、打开网页很慢。　　

2、其他同频设备的干扰

同样工作在2.4G的设备还有 微波炉 、蓝牙设备等，一般蓝牙设备发射功率小，不用考虑干扰。微波炉工作时泄漏的功率就厉害了，会造成很大的干扰。不过这些情况容易发现和控制的。

处理的方法

万一发现你的手机信号满格，但是上网很慢的情况，排除没有开微波炉、或是宽带本身没有问题、也不是很多人同时使用时，就要动手解决wifi信号干扰的问题了。

1、解决起来也不复杂，如果该路由器还有5G频段的，就连5G网络，一般可以解决，因为目前大部分路由器使用2.4G的。　　

如果没有5G的，那只有你自己是路由的主人、或者求助路由器的主人来解决了。找不到的话，那只好不用wifi、直接用运营商的网络吧。

2、测量分析周围wifi的状况

测试周边wifi的数量、强度等状况，不一定要专业的设备，安卓手机上都可以找到、安装一些wifi分析的APP，装上后就可以直接测量。

主要是看所有的wifi信号使用的信道的情况，看看你的路由器信道是不是落在最多的WIFI源上，是的话就要避开它们。 参考技术A 关于MCU死机问题，近期小编在出差期间遇到多起，且原因不同。所以，今日小白借此机会讲一讲因硬件问题造成的MCU死机。

MCU不良

在遇到死机问题时，已经可以判定是硬件原因造成的前提下，大多人的选择是交叉验证MCU,先判定是否是MCU单体不良造成的死机。在小编以前遇到的死机问题处理过程中，因MCU不良造成的死机，其实并不多，但也确确实实的会存在这种原因。

电源异常

关于电源异常造成的MCU死机，其实也是最常见的。就小编出差工厂产线跟线就期间遇到的过多起关于电源异常造成的死机问题。

经验不足的硬件工程师，遇到这类问题往往无从下手。心急的人往往喜欢按照上面第一个原因，先更换MCU，如果还是存在就选择更换PMU，如果电路中运用到了Memory，相信也会将其也更换掉。如果真是这三者导致的或许还好，但是一旦并非这三者导致，我们还需要重新定位排查。PMU输出电压的排查，应该是后续排查工作的第一步。

小编曾在产线出差时，遇到过因PMU供电异常导致的死机，后来逐步排查，发现PMU后级负载芯片出现贴片极性贴反，将PMU相关电源拉低，影响到电源稳定性,进而引发的死机问题。当我们把后级负载芯片按照极性要求，重新贴正，死机问题就不再出现。

晶振电路异常

都说晶振属于电子产品的“大心脏”，是保障MCU有条不紊的运行条件之一，为MCU提供时钟频率，稳定性极高。然而一旦晶振本体失效或者相关电路走线受到干扰，都有可能造成MCU死机。对于晶振出现的问题，我们往往可以在靠近MCU端测量时钟频率，来确定其测量值是否符合设计标准，测量值是否稳定。

静电引入

关于静电导致的死机，往往是虚无缥缈的存在。小编在以前的项目中，就遇到生产测试出现极低概率的死机问题，软件抓取log，往往无法看出根本原因。根本原因看不出来的同时，大多数人也喜欢往静电方面扯。静电造成的芯片工作不稳定或者不良，往往成为了许多芯片厂商答复给客户芯片不良的原因。
虽然，但是！
不过有些问题确实是静电导致的。这时，我们可以通过静电枪在敏感位置进行接触放电测试模拟死机现象。因为静电引入导致的死机问题，我们只需按照解ESD的思路进行解决即可。

供电电源干扰

在一些高频电路中，其产生的辐射等干扰会影响到电源的稳定性，这种情形，也会引起死机。解决的最好办法就是，高频电路走线尽量避免电源走线。

除此之外，硬件方面造成的死机原因不止这些，电路中贴片或者装配不良产生意想不到的短路有时也会导致的死机，在做手机项目的时候，曾有员工在装配主副板FPC时，没有严格按照SOP作业，导致装配不良引发了手机开机进入dump模式，机器反复重启问题。最终拆机排查发现BTB座子存在变形引起了短路，才找到原因。

Android卡顿优化思路

卡顿优化思路

• 卡顿原理分析
• 卡顿流程flow
• 卡顿概貌分析
• 卡顿实际数据收集
• 卡顿优化细节

卡顿原因

屏幕刷新频率高于帧率,帧率低于30

每帧执行流程

Choreographer中维护着四个队列callbacks

• 输入事件队列
• 动画队列
• 绘制队列
• app添加的frameCallback队列

vysnc信号由SurfaceFlinger中创建HWC触发，通过bitTube技术发送到目标进程，目标进程vsync信号到来时，执行Choreographer中的onVsync回调，最终触发doFrame顺序执行这四条队列中的消息。

bitTube

在linux/unix中，bitTube技术成为socketPair，它通过dup技术复制socket的句柄，传递到目标进程，开启socket的全双工通信。

句柄

在内核中，每一个进程都有一个私有的“打开文件表”，这个表是一个指针数组，每一个元素都指向一个内核的打开文件对象。而fd，就是这个表的下标。当用户打开一个文件时，内核会在内部生成一个打开文件对象，并在这个表里找到一个空项，让这一项指向生成的打开文件对象，并返回这一项的下标作为fd.

ui优化

• 多余Bg移除
• ui重叠区域优化 cancas.clipRect
• 减少ui层级
• 耗时方法分析与优化
• 多样式布局采用单一rv处理

webview优化

webview的加载流程

webiew初始化

• 目的是初始化并启动浏览器内核。
• 提前初始化webview并隐藏 优化126ms

webview 单独进程

• 单独进程 activity配置
• 单独进程的交互 webview.addJavascriptInterface(),webview.evalute()

安全性

• addJavaScriptInterface添加的java对象的方法，需要添加@addJavascriptInterface注解，避免xss攻击

卡顿收集策略

开发卡顿检测StrictMode

private void initStrictMode() 
    if (isDebug()) 
        StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
                .detectCustomSlowCalls() //API等级11，使用StrictMode.noteSlowCode
                .detectDiskReads()
                .detectDiskWrites()
                .detectNetwork() // or .detectAll() for all detectable problems
                .penaltyDialog() //弹出违规提示对话框
                .penaltyLog() //在Logcat 中打印违规异常信息
                .penaltyFlashScreen() //API等级11
                .build());
        StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                .detectLeakedSqlLiteObjects()
                .detectLeakedClosableObjects() //API等级11
                .penaltyLog()
                .penaltyDeath()
                .build());
    

线下卡顿检测

• adb shell dumpsys gfxinfo [packagename]

Applications Graphics Acceleration Info:
Uptime: 205237819 Realtime: 436545102

** Graphics info for pid 5842 [xxxx] **

Stats since: 198741999784549ns
Total frames rendered: 653
Janky frames: 157 (24.04%)
50th percentile: 9ms
90th percentile: 34ms
95th percentile: 53ms
99th percentile: 200ms
Number Missed Vsync: 46
Number High input latency: 268
Number Slow UI thread: 76
Number Slow bitmap uploads: 3
Number Slow issue draw commands: 8
Number Frame deadline missed: 92

• 通过gpu绘制条形柱分析

条形柱共分为8种颜色，绿色和蓝色部分是异步应用能够优化的部分。包括其他处理 - 输入 - 动画 - travel

BlockCanary检测卡顿

在ActivityThread.main中的Looper大循环中，Looper.looponce会不断从消息队列中取出消息派发出去,并在前后通过logging打印了两个日志，我们通过设置自定义的logger，在两部分日志的时间差与30ms做对比，如果超过30ms，认为是卡顿。

logging.println(">>>>> Dispatching to " + msg.target + " "
                    + msg.callback + ": " + msg.what);
msg.target.dispatchMessage(msg);
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);

卡顿分析信息收集

• Debug.startMethodTracing 收集具体的卡顿方法
• 查看trace文件 根据bottomup分析具体的耗时方法
• 火焰图，横轴是调用方法耗时，纵轴是调用深度
• 调用图，调用链以及方法耗时

线上卡顿分析与收集

在ActivityThread.main中的Looper大循环中，Looper.looponce会不断从消息队列中取出消息派发出去,并在前后通过logging打印了两个日志，我们通过设置自定义的logger，在两部分日志的时间差与30ms做对比，如果超过30ms，认为是卡顿。将主线程堆栈信息写入到缓存文件并异步发送到日志后台。

常见的卡顿问题

sharepreference

• 首次读取写入会loadxml到内存
• sp文件修改是全量读写的
• commit异步写入，通过CountdownLatch阻塞等待结果
• apply延迟100ms写入，无返回结果
• 主线程ANR，sp的修改会先体现在内存中，然后往QueueWorker中加入磁盘异步写数据的任务，但是会在Activity.onResume以及Service.onstartCommand等方法中增加waitToFinish等待磁盘写入完成的代码。
• 解决方案使用MMKV
• 尽量拆分小的xml

主线程操作文件

主线程网络操作