Android ANR的trace文件基本信息解读
2024-05-24 01:04:50
ANR堆栈文件的抓取
- android6以下可以直接读取/data/anr目录下的trace.txt文件，然后过滤出自己进程的anr文件即可
- android6及以上，没有读取/data/anr的权限，需要native层通过拦截SIGQUIT信号，结合消息机制msg的when超时时间，底层dump堆栈信息。详细原理详见微信技术团队的分享：微信Android客户端的ANR监控方案
Android ANR的trace文件基本信息解读
- 示例
"main" prio=5 tid=1 Native| group="main" sCount=0 dsCount=0 flags=0 obj=0x727c02f8 self=0xb400007a2f210800| sysTid=339 nice=-10 cgrp=default sched=0/0 handle=0x7ab698d500| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fc8197000-0x7fc8199000 stackSize=8192KB| held mutexes=at android.os.MessageQueue.nativePollOnce(Native method)at android.os.MessageQueue.next(MessageQueue.java:339)at android.os.Looper.loop(Looper.java:200)at android.app.ActivityThread.main(ActivityThread.java:8312)at java.lang.reflect.Method.invoke(Native method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:632)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)
线程基本信息
- 线程优先级：prio=5 (主线程均是5)
- 线程ID： tid=1 主线程的id一般都是1
- 线程状态：Native ：表示正在调用JNI
- 还有其他多种状态，表示发生ANR时主线程的状态
- 线程组名称：group=“main”
- 线程被挂起的次数：sCount=0
- 在等待GC时，有时候挂起的线程数量比较多
- 线程被调试器挂起的次数：dsCount=0
- 线程的java的对象地址：obj= 0x7682ab30
- 线程本身的Native对象地址：self=0x7bd3815c00线程调度信息：
线程优先级信息
- Linux系统中内核线程ID: sysTid=6317与主线程的进程号相同
- 线程调度优先级：nice=-10
- 线程调度组：cgrp=default
- 线程调度策略和优先级：sched=0/0
- 线程处理函数地址：handle= 0x7c59fc8548
线程状态信息
- 线程调度状态：state=S
- 线程在CPU中的执行时间、线程等待时间、线程执行的时间片长度：schedstat=(1009468742 32888019 224)
- 线程在用户态中的调度时间值：utm=91
- 线程在内核态中的调度时间值：stm=9
- 最后执行这个线程的CPU核序号：core=4
线程堆栈信息
- 堆栈地址和大小：stack=0x7ff27e1000-0x7ff27e3000 stackSize=8MB
ANR中的主线程状态及ANR示例分析
Blocked
- case 1
"main" prio=5 tid=1 Blocked| group="main" sCount=0 dsCount=0 flags=0 obj=0x72996758 self=0xb400007ac7e10800| sysTid=28366 nice=-10 cgrp=default sched=0/0 handle=0x7b4f71b500| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fe0a67000-0x7fe0a69000 stackSize=8192KB| held mutexes=at com.autonavi.base.ae.gmap.GLMapEngine.addGestureMessage(SourceFile:-1)- waiting to lock <0x0f62c521> (a com.autonavi.base.ae.gmap.GLMapEngine) held by thread 96at com.amap.api.mapcore.util.c.addGestureMapMessage(SourceFile:2892)at com.amap.api.mapcore.util.p$c.b(SourceFile:801)at com.amap.api.mapcore.util.am.a(SourceFile:104)at com.amap.api.mapcore.util.ak.d(SourceFile:61)at com.amap.api.mapcore.util.p.a(SourceFile:195)at com.amap.api.mapcore.util.c.onTouchEvent(SourceFile:1795)at com.amap.api.mapcore.util.e.onTouchEvent(SourceFile:47)
- 分析：
- GLMapEngine锁被线程96持有，主线程一直等待到ANR，需要解决锁等待的问题
- case 2
"main" prio=5 tid=1 Blocked| group="main" sCount=1 dsCount=0 cgrp=apps/bg_non_interactive handle=0xb6f4fb4c| sysTid=4232 nice=0 sched=0/0 cgrp=apps/bg_non_interactive handle=0xb6f4fb4c| state=S schedstat=( 93912199183 67364592009 177636 ) utm=7567 stm=1824 core=1 HZ=100| heldMutexes=at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:172)at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:166)at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:159)
- 分析
- cgrp=apps/bg_non_interactive 表示app在后台；
- sCount=1有一个线程被挂起；
- nice=0 压后台时，线程优先级降低，nice值越小（负数），优先级越高
- schedstat( 93912199183 67364592009 177636 )，表示线程执行时间很长
Native
- case 1
"main" prio=5 tid=1 Native| group="main" sCount=0 dsCount=0 flags=0 obj=0x727c02f8 self=0xb400007a2f210800| sysTid=339 nice=-10 cgrp=default sched=0/0 handle=0x7ab698d500| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fc8197000-0x7fc8199000 stackSize=8192KB| held mutexes=at android.os.MessageQueue.nativePollOnce(Native method)at android.os.MessageQueue.next(MessageQueue.java:339)at android.os.Looper.loop(Looper.java:200)at android.app.ActivityThread.main(ActivityThread.java:8312)at java.lang.reflect.Method.invoke(Native method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:632)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1049)
- 分析
- 表明ANR时，主线程的状态是在调用JNI，此处主线程的MessageQueue停留在nativePollOnce，表示主线程没有需要处理的消息；此状态大概率是没有dump出状态，或者ANR已经发生，没有dump出ANR的堆栈
- case 2:
"main" prio=5 tid=1 Native| group="" sCount=0 dsCount=0 flags=0 obj=0x7877b2c0 self=0x7e5f214c00| sysTid=25160 nice=0 cgrp=default sched=0/0 handle=0x7ee5d67548| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fe88ba000-0x7fe88bc000 stackSize=8MB| held mutexes=at java.io.FileDescriptor.sync(Native method)at android.os.FileUtils.sync(FileUtils.java:197)at android.app.SharedPreferencesImpl.writeToFile(SharedPreferencesImpl.java:777)at android.app.SharedPreferencesImpl.access$900(SharedPreferencesImpl.java:54)at android.app.SharedPreferencesImpl$2.run(SharedPreferencesImpl.java:642)at android.app.SharedPreferencesImpl.enqueueDiskWrite(SharedPreferencesImpl.java:661)at android.app.SharedPreferencesImpl.access$100(SharedPreferencesImpl.java:54)at android.app.SharedPreferencesImpl$EditorImpl.commit(SharedPreferencesImpl.java:580)...at android.os.Handler.handleCallback(Handler.java:873)at android.os.Handler.dispatchMessage(Handler.java:99)at android.os.Looper.loop(Looper.java:242)at android.app.ActivityThread.main(ActivityThread.java:7227)at java.lang.reflect.Method.invoke(Native method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:499)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:962)
- 分析
- SP属于IO操作，建议通过apply方式进行，将同步改成异步；或者使用子线程进行保存
Waiting
"main" prio=5 tid=1 Waiting| group="main" sCount=0 dsCount=0 flags=0 obj=0x731a0ec8 self=0xb40000753e8b6c00| sysTid=28146 nice=-10 cgrp=default sched=0/0 handle=0x753fe804f8| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fd0403000-0x7fd0405000 stackSize=8192KB| held mutexes=at java.lang.Object.wait(Native method)- waiting on <0x025d68dd> (a android.opengl.GLSurfaceView$GLThreadManager)at java.lang.Object.wait(Object.java:442)at java.lang.Object.wait(Object.java:568)at android.opengl.GLSurfaceView$GLThread.onPause(GLSurfaceView.java:1731)at android.opengl.GLSurfaceView.onPause(GLSurfaceView.java:579)at com.amap.api.mapcore.util.e.onPause(SourceFile:117)at com.amap.api.mapcore.util.e.onDetachedGLThread(SourceFile:73)at com.amap.api.mapcore.util.c.destroy(SourceFile:5750)at com.amap.api.mapcore.util.t.onDestroy(SourceFile:207)at com.amap.api.maps.MapView.onDestroy(SourceFile:165)
- 分析
- 主线程等待超时导致ANR
Sleeping
"main" prio=5 tid=1 Sleeping| group="main" sCount=0 dsCount=0 flags=0 obj=0x71ddabd8 self=0xb4000077247b3c00| sysTid=17264 nice=0 cgrp=default sched=0/0 handle=0x7725f054f8| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fd62dd000-0x7fd62df000 stackSize=8192KB| held mutexes=at java.lang.Thread.sleep(Native method)- sleeping on <0x0b3201c6> (a java.lang.Object)at java.lang.Thread.sleep(Thread.java:442)at java.lang.Thread.sleep(Thread.java:358)at com.amap.api.mapcore.util.c.destroy(SourceFile:5731)at com.amap.api.mapcore.util.t.onDestroy(SourceFile:207)at com.amap.api.maps.MapView.onDestroy(SourceFile:165)
- 分析
- 在主线程使用了Thread.sleep，导致主线程超时ANR
WaitingForGcToComplete
- case 1
"main" prio=5 tid=1 WaitingForGcToComplete| group="main" sCount=0 dsCount=0 flags=0 obj=0x72f93540 self=0x7edd210800| sysTid=27919 nice=0 cgrp=default sched=0/0 handle=0x7f641e10d0| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fe2497000-0x7fe2499000 stackSize=8192KB| held mutexes=at java.util.Arrays.copyOf(Arrays.java:3257)at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)at java.lang.StringBuilder.append(StringBuilder.java:137)at android.os.Handler.toString(Handler.java:862)at java.lang.String.valueOf(String.java:2924)at java.lang.StringBuilder.append(StringBuilder.java:132)at android.os.Looper.loop(Looper.java:185)at android.app.ActivityThread.main(ActivityThread.java:8668)at java.lang.reflect.Method.invoke(Native method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)
- 分析
- 由于app内存问题，比如缓慢的内存泄漏等，导致APP频繁的GC，数组的copyOf等操作，触发了GC，这类问题的解决不一定是copyOf本身导致的，而有可能是app其他地方内存泄漏导致的；需要等待GC结束之后才能分配内存；
- case 2
"main" prio=5 tid=1 WaitingForGcToComplete| group="main" sCount=0 dsCount=0 flags=0 obj=0x74a91540 self=0x7604810800| sysTid=13782 nice=-10 cgrp=default sched=1073741825/2 handle=0x768b7a50d0| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fce4eb000-0x7fce4ed000 stackSize=8192KB| held mutexes=at java.lang.StringFactory.newStringFromChars(StringFactory.java:260)at java.lang.StringBuilder.toString(StringBuilder.java:413)at android.os.Looper.loop(Looper.java:185)at android.app.ActivityThread.main(ActivityThread.java:8668)at java.lang.reflect.Method.invoke(Native method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)
- 分析
- 和上一个类似，app内存已经处于比较高的状态，此时小的newStringFromChars或者copyOf均会导致GC，需要等待GC结束之后才能分配内存；
Suspended
"main" prio=5 tid=1 Suspended| group="main" sCount=1 dsCount=0 cgrp=bg_non_interactive handle=0x7fa2a39000| sysTid=16770 nice=-4 sched=0/0 cgrp=bg_non_interactive handle=0x7fa2a39000| state=S schedstat=( 2661049558440 288674775480 3568435 ) utm=226454 stm=39650 core=1 HZ=100| heldMutexes=at android.os.MessageQueue.removeMessages(MessageQueue.java:702)at android.os.Handler.removeCallbacks(Handler.java:487)at me.ele.android.lmagex.b$3.println(SourceFile:103)at android.os.Looper.loop(Looper.java:153)at android.app.ActivityThread.main(ActivityThread.java:5665)at java.lang.reflect.Method.invoke!(Native Method)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:822)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:712)
- 分析：
- app压后台时，线程优先级由-10降低到nice=-4，通过Handler进行removeCallbacks，线程被挂起导致ANR
WaitingPerformingGc
"main" prio=5 tid=1 WaitingPerformingGc| group="main" sCount=2 dsCount=0 cgrp=default handle=0x7305320a98| sysTid=22746 nice=-10 sched=0/0 cgrp=default handle=0x7305320a98| state=S schedstat=( 9818861431 3483191114 27855 ) utm=765 stm=216 core=1 HZ=100| heldMutexes=kernel: (couldn't read /proc/self/task/22746/stack)at java.util.Arrays.copyOf(Arrays.java:3352)at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130)at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114)at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:417)at java.lang.StringBuilder.append(StringBuilder.java:133)at android.os.Looper.loop(Looper.java:164)at android.app.ActivityThread.main(ActivityThread.java:6623)at java.lang.reflect.Method.invoke!(Native Method)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:942)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:832)
- 分析
- 由于app内存问题，比如缓慢的内存泄漏等，导致APP频繁的GC，数组的copyOf等操作，触发了GC，这类问题的解决不一定是copyOf本身导致的，而有可能是app其他地方内存泄漏导致的；需要等待GC结束之后才能分配内存；
Runnable
- case 1
"main" prio=5 tid=1 Runnable| group="main" sCount=0 ucsCount=0 flags=0 obj=0x71e0bb18 self=0xb4000079a0f92c00| sysTid=19963 nice=-10 cgrp=default sched=0/0 handle=0x79a25cc4f8| state=? schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100| stack=0x7fd7bb5000-0x7fd7bb7000 stackSize=8188KB| held mutexes= "mutator lock"(shared held)at java.lang.Throwable.nativeGetStackTrace(Native method)at java.lang.Throwable.getOurStackTrace(Throwable.java:852)at java.lang.Throwable.getStackTrace(Throwable.java:837)at android.os.strictmode.Violation.hashCode(Violation.java:37)at android.os.StrictMode$ViolationInfo.hashCode(StrictMode.java:2962)at android.os.StrictMode$AndroidBlockGuardPolicy.onThreadPolicyViolation(StrictMode.java:1821)at android.os.StrictMode$AndroidBlockGuardPolicy.lambda$handleViolationWithTimingAttempt$0$StrictMode$AndroidBlockGuardPolicy(StrictMode.java:1790)at android.os.StrictMode$AndroidBlockGuardPolicy$$ExternalSyntheticLambda0.run(unavailable:-1)at android.os.Handler.handleCallback(Handler.java:938)at android.os.Handler.dispatchMessage(Handler.java:99)at android.os.Looper.loopOnce(Looper.java:210)at android.os.Looper.loop(Looper.java:299)at android.app.ActivityThread.main(ActivityThread.java:8273)at java.lang.reflect.Method.invoke(Native method)at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:576)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1073)
- 分析：
- nativeGetStackTrace操作耗时，导致ANR
- case 2
"main" prio=5 tid=1 Runnable| group="main" sCount=0 dsCount=0 cgrp=bg_non_interactive handle=0xf750bb38| sysTid=9404 nice=-4 sched=0/0 cgrp=bg_non_interactive handle=0xf750bb38| state=R schedstat=( 161587126622 89304032298 370948 ) utm=13341 stm=2817 core=4 HZ=100| heldMutexes= "mutator lock"(shared held)at java.lang.ref.Reference.get(Reference.java:203)at android.os.MessageQueue.nativePollOnce(Native Method)at android.os.MessageQueue.next(MessageQueue.java:330)at android.os.Looper.loop(Looper.java:137)at android.app.ActivityThread.main(ActivityThread.java:5659)at java.lang.reflect.Method.invoke!(Native Method)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:822)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:712)
分析
- app处于bg_non_interactive，schedstat=( 161587126622 89304032298 370948 )看出native层线程耗时，导致ANR
case 3
"main" prio=5 tid=1 Runnable| group="main" sCount=0 dsCount=0 cgrp=default handle=0x7f7f4faa98| sysTid=6181 nice=-10 sched=0/0 cgrp=default handle=0x7f7f4faa98| state=R schedstat=( 56665830978 410406153 28210 ) utm=5646 stm=20 core=7 HZ=100| heldMutexes= "mutator lock"(shared held)at java.util.HashMap.getEntry(HashMap.java:394)at java.util.HashMap.get(HashMap.java:348)at com.koubei.android.mist.core.expression.n.b(SourceFile:221)......
- 分析
- app在前台，schedstat=( 56665830978 410406153 28210 )说明主线程一直执行了很长时间；说明HashMap在在getEntry时，疑似出现了死循环导致的。将HashMap替换成为线程安全的ConcurrentHashMap来解决
TimedWaiting
"main" prio=5 tid=1 TimedWaiting| group="main" sCount=1 dsCount=0 cgrp=default handle=0x7fa92262c0| sysTid=24814 nice=-4 sched=0/0 cgrp=default handle=0x7fa92262c0| state=S schedstat=( 403952448660 201010160492 646405 ) utm=37206 stm=3189 core=2 HZ=100| heldMutexes=at java.lang.Object.wait!(Native Method)at java.lang.Thread.parkFor$(Thread.java:1220)at sun.misc.Unsafe.park(Unsafe.java:299)at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1011)at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1301)at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:249)at anetwork.channel.aidl.a.a.a(SourceFile:119)
- 分析
- 主线程CountDownLatch的await超时
Android ANR的trace文件基本信息解读相关推荐
- android trace文件分析ANR
为什么80%的码农都做不了架构师?>>> ANR定义与分类 ANR(Application Not Responding):应用程序无响应,是Android中AMS与WMS监测 ...
- Android ANR分析（trace文件的产生流程）
ANR信息获取(trace文件的产生流程) 首先收集需要dump trace的进程并给对应进程发送dump trace的信号 接着分析最后一步向收集到的进程发送信号 首先收集需要dump trace的 ...
- 【Android CPU 优化】Android CPU 调优 ( Trace 文件分析 | Android Profiler 工具 | CPU Profiler 工具 )
文章目录 一.Android CPU 优化 二.CPU Profiler 工具 三.相关资源 一.Android CPU 优化 在 Android 中 , 出现 动画掉帧 , 页面切换白屏 , 卡顿 ...
- 【Android 性能优化】应用启动优化 ( 阶段总结 | Trace 文件分析及解决方案 | 源码分析梳理 | 设置主题的方案总结 ) ★
文章目录 一. 常用的耗时方法优化方案 ( 重要 ) 二. 源码分析梳理 1. 应用启动时间计算相关源码分析 2. Launcher 应用中启动 Android 应用流程 三. 启动白屏解决方案 An ...
- 【Android 性能优化】应用启动优化 ( 方法追踪代码模板 | 示例项目 | SD 卡访问权限 | 示例代码 | 获取 Trace 文件 | Android Studio 查看文件)
文章目录 一. 方法追踪代码模板 二. 追踪 Launch 页面的 onCreate 方法执行情况 1. 示例项目 2. SD 卡访问权限问题 ( 动态权限申请 ) 3. MainActivity o ...
- android .trace 文件,android - 了解Android应用程序的.trace文件 - SO中文参考 - www.soinside.com...
我的应用程序给出ANR弹出窗口.为了找出使用此行生成sample.trace文件的原因:Debug.startMethodTracing("sample"); 在我的活动的onCr ...
- 【Android 性能优化】应用启动优化 ( Trace 文件分析 | 结合代码分析 Trace 文件 )
文章目录 一. Trace 文件查看 二. 结合代码分析 Trace 文件 一. Trace 文件查看 上一篇博客 [Android 性能优化]应用启动优化 ( 方法追踪代码模板 | 示例项目 | S ...
- anr trace文件分析
测试给的trace文件好几万行,怎么看? 1.搜索 你的包名,看它报错误报在你代码的哪里 2.在你代码里面分析 还有,synchronized 就是用来防止多线程调用的,没有那么神奇.
- android的dmtracedump工具生成trace文件图片 'dot' 不是内部或外部命令，也不是可运行的程序 或批处理文件。
http://jingyan.baidu.com/article/c910274bfa6c1fcd361d2df7.html http://www.cnblogs.com/albert1017/p/3 ...
- oracle trace文件解读
oracle trace文件解析 ===================== PARSING IN CURSOR #1 len=68 dep=0 uid=59 oct=42 lid=59 tim=12 ...
最新文章
- SaltStck 搭建Web集群运用示例 (一)
- Python基础教程：菱形继承问题
- Page directive: illegal to have multiple occurrences of contentType with different values
- 面趣 | 马云在面试中出的一道题，据说只有一个人答对……
- 【Java】百钱买百鸡问题
- dell笔记本外接显示器_使用笔记本电脑外接大屏幕液晶显示器的体验
- centos安装php
- 电子设计大赛可以用linux开发板嘛,【一转再转】电子设计大赛应该怎么准备？...
- secsetupwizard以停止_三星手机s3500c报价是多少【详细评测】
- Mac下驱动BCM20702A0 USB蓝牙
- 零基础使用vscode实现python爬取高德地铁数据
- 奔驰S400豪华型升级后排电动腿托系统，提升后排乘坐舒适性
- Android Context解析以及getContext()、getApplication()、getApplicationContext()和getBaseContext()区别
- QGIS插件python开发环境配置和PyCharm配置调试环境
- 词根、词缀笔记(一)
- 数据结构与算法实验报告——实验一 链表
- RF框架----基础
- CSS3系列 12 栅格布局
- react17同源iframe父子页面相互调用方法
- word排版图片的一种方法
热门文章
- 机器学习案例（三）：未来销售预测
- 河南师范大学python+学习笔记6 组合数据类型
- vue error The code generator has deoptimised the styling exceeds the max of 100KB
- PCI驱动学习总结-国嵌视频
- CE游戏修改器制作游戏修改器教程
- 另辟蹊径--极简Swifty路由
- Swift如何实现与JSON互转
- html去除背景颜色怎么设置,word文档背景颜色怎么去掉,文档背景颜色怎么去掉
- SpringCloud整合Feign和Nacos报错：No Feign Client for loadBalancing defined. Did you forget to include?
- ISE WARNING:ProjectMgmt - File /*filePath*/ is missing.解决方法