努比亚技术团队
努比亚技术团队

Android卡顿掉帧问题分析之实战篇

努比亚技术团队原创内容，转载请务必注明出处。

  • Android卡顿掉帧问题分析之原理篇
  • Android卡顿掉帧问题分析之工具篇
  • Android卡顿掉帧问题分析之实战篇

本文是Android卡顿问题分析三部曲的最后一篇。在前面两篇文章的理论和工具的分析基础上，本文将结合典型实战案例，分析常见的造成卡顿等性能问题的原因。从系统工程师的总体角度来看 ，造成卡顿等性能问题的原因总体上大致分为三个大类：一类是流程执行异常；二是系统负载异常；三是编译问题引起。

1 流程执行异常

在前文Android卡顿掉帧问题分析之原理篇的内容中，我们以滑动场景为例完整的分析了Android应用上帧显示的全流程（默认开启硬件绘制加速条件下）。下面我们用一张图来看看这个流程上可能引起卡顿、反应延迟等性能问题的点。

jank_reason.jpg

从上图可以看出，在Android应用上帧显示的各个流程上都可能出现问题导致出现卡顿、反应延迟等性能问题。下面我们分类来分析一下各个流程上可能的引起卡顿等性能问题的点。

1.1 system_server引起应用卡顿

一、理论分析

框架system_server进程内部的各个核心服务AMS、WMS、PKMS等，都有各自的对象锁和工作线程，各个服务运行时相互之间存在交互，可能出现某个线程持锁执行耗时操作而其它线程陷入长时间锁等待的情况。某些情况下当系统框架负载过重或流程出现异常情况下，其工作线程之间相互等锁的现象会非常严重。如果此时应用App的UI线程中有Binder请求，而系统框架内部处理请求的实现又恰好需要持锁，就可能间接导致应用App的UI线程阻塞在Binder请求，而引起App应用的卡顿问题。
二、典型案例分析

问题描述：设备刚开机时，桌面左右滑动出现卡顿。

问题分析：结合Systrace工具分析问题原因如下：

launcher_jank.jpg

从以上问题Systrace的分析可以看出，出现桌面滑动卡顿的原因是：

  1. 桌面应用的UI线程（tid:4927）中通过Binder请求访问框架PKMS服务的getActivityInfo接口查询Activity的相关信息时出现长时间阻塞；
  2. 而框架PKMS服务中处理此Binder请求的线程（tid:5271）逻辑需要持锁执行，而当前此锁对象的“锁池”中至少已经有7个线程都已经在等待这把锁，所以此线程进入锁对象的“锁池”中阻塞等待锁释；
  3. 而此时持有该锁的线程为框架的android.bg工作线程（tid:2608），此线程中正持锁执行IO写磁盘等耗时操作，且线程的优先级较低，在刚开机阶段系统整体负载比较重的场景下，抢不到CPU执行时间片而长时间处于Runnable状态，导致运行时间较长。

三、优化思路

针对此类system_server内部的各种锁等待或流程异常导致的性能问题。Google在历年的Android版本上也在不断针对优化，通过优化流程尽量的减少流程中不必要的持锁或减小持锁范围。例如在Android P上推出的LockFreeAnimation无锁窗口动画，就实现了无需持有WMS锁播放窗口动画，从而极大减少窗口动画卡顿的概率；Android 12上在 PackageManager 中，引入只读快照减少了 92% 的锁争用。另外各大手机厂商也会在自家的ROM系统上针对这种情况对框架作出持续的优化，通过分析持锁等待的关系，找到问题源头的当前持锁线程，利用一些空间换时间的缓存方案或优化CPU、IO等资源的调度与分配，减少线程的持锁的时长，从而改善其它线程锁等待的时长。

1.2 Input事件处理引起卡顿

一、理论分析

从前面Android卡顿掉帧问题分析之原理篇文章中的分析我们知道，屏幕驱动上报的Input事件要经过框架的InputReader和InputDispatcher线程的读取与分发，然后通过Socket发送到应用进程中，再经过界面View控件树的层层分发后消费处理。这个过程中任意一个流程出现阻塞就能造成用户的触控操作得不到及时的响应，出现用户感知的系统反应延迟或卡顿现象。

二、典型案例分析

问题描述：微博应用界面手势滑动退出时，界面卡住几秒钟才有反应。

问题分析：结合Systrace工具分析问题原因如下：

input_jank.jpg

从以上问题Systrace的分析可以看出，退出应用界面时出现卡住几秒的原因：

  1. 首先看Systrace上system_server进程中标识Input事件分发的"iq"和“oq”队列的信息，可以看到框架InputDispatcher对事件的分发处理没有出现阻塞或漏报等异常情况；
  2. 从微博应用对应的“wq”队列可以看到，应用进程一直有没有完成处理消费的Input事件，说明问题在微博应用进程侧；
  3. 看Systrace上微博应用侧的信息，可以看到应用UI线程很长一段的deliverInputEvent的tag（大概持续2.5秒左右），且“aq：ime”队列中显示有持续很长一段时间的事件处理逻辑。说明应该是在应用进程UI线程中判断Input事件类型为返回键的Key事件，所以先交给输入法应用进行处理，但是输入法进程一直没有完成处理，导致应用UI线程一直处于等待状态无法及时处理此Input事件，说明问题出现在输入法应用侧；
  4. 然后我们用ps命令查看当前输入法进程信息，发现输入法进程（pid：5897）当前的状态为“D”，说明处于进程“冻结”的休眠状态，结合Systrace上显示的输入法进程的主线程信息显示，发现其确实是一直处于Sleeping状态。所以此问题出现的原因就是因为输入法进程被异常“冻结”导致的。和负责维护进程“冻结”功能的同事沟通并分析日志后发现，问题的原因是用户安装并设置了新的输入法应用，进程“冻结”模块没有成功识别，将其认定为普通后台进程所以进行了“冻结”从而导致了异常。

到此还剩一个疑问就是为什么输入法进程都被“冻结”而休眠了，应用UI线程在等待2.5秒后还是能继续往下处理Input事件，并成功退出应用Activity界面呢？原因就是应用UI线程进入等待输入法处理Input事件时会设置一个超时，这个时长就是2.5秒，如果超时后输入法进程还是没有处理完，就会强行结束等待的逻辑，由应用UI线程继续往下处理Input事件。相关源码如下所示：

/*frameworks/base/core/java/android/view/inputmethod/InputMethodManager.java*/
...
/**
* Timeout in milliseconds for delivering a key to an IME.
*/
static final long INPUT_METHOD_NOT_RESPONDING_TIMEOUT = 2500;
...
// Must be called on the main looper
int sendInputEventOnMainLooperLocked(PendingEvent p) {
        if (mCurChannel != null) {
           ...
            if (mCurSender.sendInputEvent(seq, event)) {
                ...
                Message msg = mH.obtainMessage(MSG_TIMEOUT_INPUT_EVENT, seq, 0, p);
                msg.setAsynchronous(true);
                mH.sendMessageDelayed(msg, INPUT_METHOD_NOT_RESPONDING_TIMEOUT);//1.处理Input事件时设置一个2500ms的超时检查
                return DISPATCH_IN_PROGRESS;
            }
            ...
        }
      return DISPATCH_NOT_HANDLED;
}
...
case MSG_TIMEOUT_INPUT_EVENT: {
     finishedInputEvent(msg.arg1, false, true);// 2.时间到之后如果输入法还是没有完成Input事件处理，则强行结束输入法对事件的处理逻辑
     return;
}
...

三、优化思路

对用户触控事件的响应速度直接关系到用户对交互设备性能体验的感知，所以一直以来都是系统性能优化工作的重中之重。多年来谷歌，包括SOC厂商都有针对系统Input事件的处理流程作出优化，以提升触控响应速度。例如高通基线上在2018年左右就有一笔提交，优化应用进程侧的Input事件处理流程，大概思路就是识别应用UI线程中收到第一个ACTION_DOWN的Touch事件后，调用sendMessageAtFrontOfQueue接口在应用UI线程的消息队列的最前面插入一帧doFrame绘制任务，这样界面不用等待下一个Vsync的信号的到来就能直接上帧显示，从而减少整个Input触控事件的响应延迟。从Systrace上表现如下图所示：

OPTS_INPUT.png

国内各大手机厂商也有各自的优化方案。比如硬件上采用触控采样率更高的屏幕，屏幕触控采样率达到240HZ甚至480HZ。再比如监控到触控事件后提升CPU主频，提升触控事件处理相关线程和渲染线程的优先级等方式，从而优化事件触控响应速度。而对于应用APP开发者来说，需要做的就是避免在Input触控事件的分发处理流程中执行耗时操作，以免引起触控延迟或卡顿等性能问题。

1.3 应用UI线程耗时引起卡顿

一、理论分析

这部分逻辑主要由应用APP开发者控制。根据前文Android卡顿掉帧问题分析之原理篇中的分析可知，UI线程耗时过长必然会导致Vsync周期内应用上帧出现超时。特别是屏幕高刷时代的到来，留给应用UI线程处理上帧任务的时长越来越短。例如120HZ的高刷屏幕配上，一个Vsync信号周期已经缩短到8ms左右。这要求应用APP开发者能写出更加高性能质量的代码。应用UI线程耗时引起的卡顿往往涉及的因素比较多，下面列举一些常见原因：

  1. UI线程消息队列中存在除doFrame绘制任务外的其它耗时任务，导致Vsync信号到来后，无法及时触发UI线程执行doFrame绘制上帧任务，而导致掉帧。例如界面布局XML文件的inflate解析，如果界面布局文件比较复杂，就到有大量的IO与反射等耗时操作。又或者UI线程中有decodeBitmap解析大图片的耗时操作。
  2. UI帧的doFrame绘制任务处理耗时过长导致掉帧。最常见的问题就是应用界面布局存在过度绘制，导致measure/layout/draw任务的计算复杂度成倍上升。再比如应用界面布局中的部分View控件层面如果关闭了硬件绘制加速，就会触发View#buildDrawingCache的耗时操作，从而导致整个draw动作耗时过长而引起掉帧。
  3. UI线程存在大量的阻塞等待导致上帧超时。UI线程陷入阻塞等待，常见的原因就是跨进程的Binder调用阻塞和进程内的同步锁竞争等待。还有一类情况就是频繁的GC内存回收引起(一般为进程内存抖动或内存泄露引起)。

二、典型案例分析

问题描述：三方应用书旗小说界面上下滑动严重掉帧卡顿。

问题分析：结合Systrace工具分析问题原因如下：

buildDrawingCache_jank.png

从Systrace上可以看到，应用UI线程上帧的doFrame流程中主要耗时点在buildDrawingCache的流程上。下面我们结合源码来看看什么情况下draw流程中会出现buildDrawingCache的动作： 

/*frameworks/base/core/java/android/view/View.java*/
...
public RenderNode updateDisplayListIfDirty() {
   ...
   if (layerType == LAYER_TYPE_SOFTWARE) { //判断View的layerType为LAYER_TYPE_SOFTWARE，也就是关闭了硬件绘制加速，执行buildDrawingCache
       buildDrawingCache(true);
       ...
    }else{
       ...
       draw(canvas); //走硬件绘制加速的流程
       ...
    }
    ....
}
...

从代码可以看出当判断某个View空间的layerType为LAYER_TYPE_SOFTWARE，也就是关闭了硬件绘制加速的情况下，就会触发走到buildDrawingCache的耗时逻辑中。所以此问题就是由于书旗小说应用的界面布局中一个名为OriWebViewEx 的View控件关闭了硬件绘制加速导致。

问题描述：Twitter应用界面上下滑动严重掉帧卡顿。

问题分析：结合Systrace工具分析问题原因如下：

app block.png

从Systrace上可以看到，三方应用Twitter出现掉帧的主要原因是：其UI线程中存在大量耗时的inflate解析xml布局文件的操作，且出现问题时UI线程已经持续Running到CPU 5大核心上但是还是出现严重的上帧超时。

三、优化思路

针对应用UI线程耗时引起卡顿的问题，原则就是尽量减轻UI线程的负担。针对不同的引起问题原因，常见的优化思路大致如下：

  1. 异步处理：各种耗时操作尽量放到子线程异步处理。比如使用View的异步线程inflate方案；decodeBitmap加载图片的耗时操作移到子线程统一处理等。
  2. 逻辑优化：必须要在主线程执行的逻辑应尽量优化，减少计算频次，避免重复计算。比如采用约束布局解决嵌套过多的问题，避免过度绘制；优化应用的内存占用，避免内存泄露、内存抖动等问题，从而减少GC触发的次数；优化内部代码逻辑，尽量减少主线程陷入同步锁竞争等待的状态；原则上不要主动去关闭硬件绘制加速。
  3. 流程复用：能复用的逻辑尽量复用，以避免多次调用产生的性能开销。比如ListView的Adapter中实现View的复用，减少View的inflate执行次数。另外UI线程中Binder请求框架查询一些系统信息，能够一次查完就不要分多次执行。且查询结果应尽量缓存在内存中实现复用，避免多次反复的查询造成主线程频繁陷入Binder阻塞等待。

1.4 SurfaceFlinger耗时引起卡顿

一、理论分析

从前文的分析可以知道，SurfaceFlinger在Android系统的整个图形显示系统中是起到一个承上、启下的作用，负责收集不同应用进程Surface的绘制缓存数据进行的合成，然后发送到显示设备。所以，如果SurfaceFlinger的处理流程上出现耗时或阻塞，必然会导致整个应用的上帧显示的流程出现超时而掉帧。特别是随着屏幕高刷时代的到来，Vsync周期不断缩短，留给SurfaceFlinger处理的时间也越来越短，对SurfaceFlinger的性能提出了更高的要求。这也是谷歌、SOC厂商包括各大手机厂商做系统性能优化的重点。

二、典型案例分析

问题描述：设置120HZ高刷模式下，手机录屏、投屏场景下出现帧率下降。

问题分析：结合Systrace工具分析问题原因如下：

sf_block.png

从Systrace上可以看到，开启录屏或投屏后，部分Layer需要采用效率更低的GPU合成方式（主要是因为高通平台HWC不支持回写），SurfaceFlinger的主线程中需要实现drawLayers的动作，还需要将图层数据写入到MediaCodec缓存中，总体负载较高，导致在8ms（120HZ高刷模式下）内无法完成一帧数据的处理而出现帧率下降的问题。

三、优化思路

针对SurfaceFlinger引起的性能卡顿问题，常见的优化思路有：

  1. 谷歌通过cpuset的配置，默认场景下SurfaceFlinger只能使用4个CPU小核心运行；部分厂商会在投屏或录屏等负载比较重的场景下放开这个限制，让SurfaceFlinger进程能跑到CPU大核心上。
  2. 部分厂商在开启录屏的情况下，会锁定屏幕刷新率最高不超过60HZ，以减轻SurfaceFlinger进程的压力。
  3. Android 12上，谷歌就将各个应用对应的BufferQueue的管理工作移动到应用进程侧处理，以减轻SurfaceFlinger进程的负载。

2 系统负载异常

CPU、GPU、内存、磁盘等都是系统内各个进程任务的运行所必需的公共系统资源。这就涉及到一个复杂的资源调度与分配的问题，实现将系统资源与各个不同进程的需求进行合理的匹配，以保证进程任务能够流畅的运行。这就涉及到两个问题：

  1. 这些系统公共资源是否充足。比如当进程需要时，当前CPU核心的运行主频算力是否足够高，系统剩余内存是否足够大，磁盘的读写速度是否足够快。
  2. 这些系统资源的分配是否合理。比如当前优先级更高的前台应用进程相对于后台进程是否能获得更多的CPU调度运行时间片和I/O带宽等资源，以保证界面的流畅运行。

从软件的角度出发，每个应用任务进程都希望自己获得无限的CPU算力、无限的内存资源分配等能力，以保证其能够流畅的运行。但是从硬件的角度出发，各种系统的公共资源配置都是有限的，不可能无限的提供给每个任务进程，且在移动设备上还要考量功耗与发热的问题，需要限制各种系统资源的供给。所以如何协调这种供需关系之间的矛盾，将宝贵的系统资源合理的分配给当前最需要的任务进程，以最小的资源开销保证系统的流畅运行，就是考验操作系统的设计者和性能优化工程师的功力的问题，弄不好就可能出现应用任务进程的运行受限于系统运行资源的分配而出现各种性能问题。

2.1 CPU调度引起卡顿

一、理论分析

CPU算力资源绝对是系统内最重要的公共资源之一，每个应用程序的正常运行都需要CPU的调度执行。目前的主流移动设备搭载的CPU基本上都是采用多核心架构设计，按照算力的大小设置有多颗CPU运算核心（以高通最新的骁龙8 gen 1处理器为例，其拥有8颗CPU运算核心，包含四个小核、三个中核和一个大核，算力依次递增，功耗也逐渐增大）。

8 gen 1.png

且Linux操作系统内核中会有相应的scheduler和governor调度器，来管理每颗CPU核心上当前运行的任务的排程，以及每颗CPU核心当前运行的主频（每颗CPU核心都有一个运行主频参数可以支持在一定的范围内动态调节，主频越高算力越强，相应的功耗也就越大）、节能状态等参数，以达到最佳的性能与功耗的平衡。但是很多时候由于CPU运行核心上的任务排布不合理，或运行主频过低导致的算力过低，无法满足应用进程的需求，就可能导致应用出现卡顿掉帧等性能问题。常见的一些原因如下：

  1. 后台应用进程任务持续运行抢占CPU运行资源，或者处于功耗管控直接关核，导致前台应用的UI线程任务无法及时的获得CPU运行算力执行，长时间处于Runnable状态，而出现上帧超时掉帧问题；
  2. 某些时候出于功耗与发热的考量，将CPU的运行主频压的过低，导致算力不足。应用的上帧线程上的任务需要Running很长一段时间，而出现上帧超时掉帧。

二、典型案例分析

问题描述：腾讯视频应用中观看视频时，播放弹幕卡顿。

问题分析：结合Systrace工具分析问题原因如下：

cpu block.jpg

从Systrace上可以看到：腾讯视频播放视频时出现掉帧卡顿的原因，是因为其负责弹幕上帧的线程无法获得CPU运行资源，而长时间处于Runnable状态，导致上帧出现严重超时。
进一步分析原因发现存在两个问题：一个就是看CPU Trace信息发现此时只有CPU 0-3四个小核心和一个CPU 4一个中核心在运行，而算力更强的CPU 5-7都处于关闭状态，导致系统总体算力受限；另一个问题就是前台应用腾讯视频进程内的所有线程运行任务都只分配到CPU 4上运行，其它几个小核心处于空闲状态也没有使用，导致腾讯视频应用的运行严重受限。
最终经过分析找到问题的根本原因就是：一、关闭算力更强的CPU 5-7的原因，是系统组为了降低用户全屏看视频场景下的功耗而故意为之；二、腾讯视频只能运行在CPU 4上的原因，是因为该项目使用的是高通最新的SM8450平台，该平台采用ARM V9架构设计，32位的应用只能使用CPU4-6三个中核运行，而应用商店提供的腾讯视频刚好就是32位的版本。
至此问题水落石出，后面解决问题思路就是：一方面推动应用商店上架腾讯视频64位版本；二是系统组那边需要针对32位的应用前台全屏看视频的场景下的CPU配置做出调整，不再全部关闭CPU 5-7三个算力较强的核心。

问题描述：桌面界面左右滑动出现卡顿掉帧。

问题分析：结合Systrace工具分析问题原因如下：

cpu block2.jpg

从Systrace上可以看到：前台应用桌面出现掉帧的原因是其UI线程抢不到CPU运算资源而长时间处于Runnable状态。而此时，CPU上分布有大量后台应用的任务持续运行。出现这个问题的原因是国内部分应用存在很多进程保活机制，会在后台持续运行，并想方设法提升其进程的优先级。所以在系统关闭了相关针对性的管控后就会出现问题。

三、优化思路

针对CPU调度问题引起的性能卡顿问题，常见的优化思路有：

  1. 基于cgroup的进程资源隔离。Android系统上继承了linux的cgroup机制，以控制进程的资源占用，让重要的进程获得更多的系统资源。涉及的系统资源如下图所示：

    cgroup.png

    其中cpuset（可以实现限制进程只能运行在指定的CPU核心上）、cpuctl（可以实现控制前后台进程的CPU用量）和freezer（可以实现控制进程处于冻结休眠状态，完全放弃CPU执行权）就是对进程CPU资源的控制。后面的top-app标识当前进程所属的资源分组。cgroup机制中会将不同的运行进程分成不同的资源组，比如前台应用属于top-app组，后台应用属于background组。不同的组可以支持配置不同的资源使用权限（比如通过cpuset的配置，background组中的进程被限制只能运行在cpu 0-3三个小核心上，而处于top-app组中的进程可以使用所有的cpu核心资源）。以cpuset为例，如下图所示：
    cgroup_2.png

    cgroup_3.png

    通过这种限制后台不重要的进程的CPU资源占用，从而让前台重要的应用进程获得更多的CPU资源（至于进程的前后台优先级定义，主要是由框架AMS服务来管理维护，通过写进程的oom_score_adj值来标识）。国内各大手机厂商的系统性能优化的策略中，有很大一部分工作都是依赖于cgroup机制来实现的，通过对系统资源精细的定义划分，和应用进程优先级与功能场景的精准识别，来实现对资源的合理分配，达到性能与功耗的最佳平衡。

  2. 基于场景识别的CPU调度策略配置。主要工作包括：

  • 对CPU基础配置影响各核的性能输出：包括CPU Frequency运行主频调节、排程器大核小核工作分配策略upmigrate/downmigrate/sched_boost的调节（根据CPU各核心的任务负载，对线程任务进行大小核分布的迁移调整），以上都是通过Soc厂商提供的Perf服务接口设置参数，去写相关的设备节点实现，以高通平台为例相关节点如下图所示：

    cpu节点配置.png

    还有温控策略的配置调整（出于功耗与发热的考量，移动设备上温控机制thermal-engine服务，会根据遍布设备内部的各个温度传感器读取的温度值，按照一定的温度阈值对CPU运行主频进行限制，以防止设备过热）；

    • 对场景的定义识别与策略配置：比如定义应用冷启动场景，在框架进行识别，并动态将CPU主频进行拉升一段时间，以提升应用打开速度；定义视频播放的场景，在框架进行识别，然后对CPU主频进行限频，在保证播放流畅的前提下，尽量降低功耗和发热；这块也属于国内各大手机厂商的系统性能优化的核心工作。如何实现精确的场景定义与识别，精准控制CPU的性能输出，用最小的功耗，保证应用界面的流畅运行，就是对厂商功力的考验。
  1. 对三方应用后台相互唤醒和进程保活机制的限制，防止其在后台持续运行抢占CPU算力资源。这块也是国内各大手机厂商系统优化的重点工作之一。

2.2 GPU调度引起卡顿

一、理论分析

GPU算力资源是继CPU算力外，系统内另一个重要的公共资源，从前文Android应用上帧显示的流程分析可知，应用对每一帧画面的渲染处理都离不开GPU算力的支撑。和CPU类似，设备的GPU也有自己的运行主频（运行主频越高，算力越强，同时发热也就越大），且支持在一定的范围内调节，以实现功耗和性能的最佳平衡。以高通SM8450平台所搭载的型号为Adreno 730的GPU为例，其参数信息如下图所示：

GPU.png

从上图可以看到，GPU支持在一定的范围内动态调节运行主频，Soc厂商和国内的手机厂商会根据任务负载和使用场景，动态调节GPU的工作频率以实现功耗与性能的最佳平衡。但是如果调节不合理，就可能引起性能问题，常见的一些原因如下：

  1. 部分大型游戏应用（如原神）需要大量的GPU算力进行游戏画面的实时渲染处理，如果系统的GPU运行主频算力没有及时的跟上来，无法满足应用对GPU算力的需求就会导致游戏应用上帧时出现阻塞超时而掉帧；
  2. 部分应用在后台利用GPU做一些图像处理的并行计算，抢占了系统的GPU算力资源；就可能导致前台应用绘制上帧时，由于GPU算力不足，使其渲染线程陷入长时间阻塞等待GPU渲染完成的Fence信号的状态，最终出现上帧超时卡顿的问题。

二、典型案例分析

问题描述：三方应用UC浏览器界面滑动卡顿。

问题分析：结合Systrace工具分析问题原因如下：

GPU block.PNG

从上图的Systrace可以看出，UC浏览器出现上帧超时的主要原因是，其RenderThread渲染线程长时间阻塞在queueBuffer上帧的流程上，而queueBuffer阻塞在SurfaceFlinger进程那边的Binder响应，而SurfaceFlinger进程中又需要等待GPU那边完成画面渲染处理的fence信号的（从应用进程侧的waiting for GPU completion的systrace tag也能看出）。如下简化代码所示： 

/*frameworks/native/libs/gui/BufferQueueProducer.cpp*/
status_t BufferQueueProducer::queueBuffer(int slot,
        const QueueBufferInput &input, QueueBufferOutput *output) {
        ATRACE_CALL();
        ...
         // Wait without lock held
    if (connectedApi == NATIVE_WINDOW_API_EGL) {
        // Waiting here allows for two full buffers to be queued but not a
        // third. In the event that frames take varying time, this makes a
        // small trade-off in favor of latency rather than throughput.
        lastQueuedFence->waitForever("Throttling EGL Production"); // 等待GPU fence信号
    }
    return NO_ERROR;
}

也就是说，问题出在系统的GPU算力资源比较紧张。后来分析应用掉帧的同一时间段系统的其它运行进程的systrace表现，发现系统的图库应用正在执行一些Bitmap图像处理的动作。再结合日志分析后与负责图库的同事沟通，最终找到问题的根本原因所在：图库应用中有一个事物分类相册的功能，当时正在后台使用GPU进行照片图像的特征识别与处理的逻辑，抢占了系统GPU算力资源，从而导致前台UC浏览器应用的渲染线程阻塞在等待GPU的fence信号的流程而出现掉帧。

三、优化思路

针对GPU调度问题引起的性能卡顿问题，常见的优化思路有：

  1. 基于场景的GPU调度策略配置。这块主要是结合前台应用场景的需求，动态调节GPU的运行主频等参数，以最小的功耗满足应用的性能需求。这块考验各大手机厂商的调教水平，也是厂商进行游戏优化调教的重点工作之一。
  2. 后台应用进程抢占GPU算力资源的管控。主要是限制后台应用的运行，防止其出现抢占GPU算力资源的行为，以保证前台应用的流畅运行。

2.3 低内存引起卡顿

一、理论分析

内存也绝对算的上是一个重要的系统公共资源，系统内任何进程的正常运行都需要消耗一定的内存资源。一般来讲设备的RAM硬件物理内存的大小是固定且有限的（4G、8G或12G等），而系统内运行的所有进程都需要共享这些有限内存资源。如何用有限的内存资源去满足系统各个应用进程无限的需求，这就涉及到一个系统内存管理的逻辑。这是一个复杂的问题，几乎贯穿了整个Android系统的各个层级。从Linux内核到Art虚拟机，再到Framework框架，甚至到APP应用，都会有各自的内存管理的策略。关于Android系统的内存管理的详细逻辑，由于篇幅所限本文就不详细展开。我们以systemui应用进程为例，来看看一个普通应用进程的内存占用分布：

app memory.png

合理的内存的分配与管理无论对系统和应用来讲都至关重要。因为内存问题既能引发稳定性问题，也能引发卡顿性能问题。下面我们分别来分析一下：

  1. 内存引起的稳定性问题：

    • 因为系统总的内存资源是有限的，为了防止单个应用进程无限制的占用内存资源，Android系统设计了很多机制来遏制这种情况的产生。比如在虚拟机层面，谷歌设计对每个应用进程占用的Dalvik Heap的内存大小做出了限制，超过一定的阈值（记录在dalvik.vm.heapgrowthlimit的property中，一般为256M），就会触发OutOfMemeory的异常，导致应用进程崩溃。此外Android系统还引入了lmkd低内存守护机制，当系统总的可用内存低于一定的阈值，就会按照进程优先级，将占用内存比较大的应用进程杀掉。
    • 32位的应用虚拟内存的寻址空间最大为4G，当应用进程的虚拟内存占用超过4G时，就无法继续为其分配内存，产生OOM类型的报错，出现应用崩溃或黑屏等问题。
    • 另外Android系统基于Linux内核，也绩承了Linux系统对应用进程的相关限制。如果应用进程中开启的线程过多（每创建一个空线程也会有一定的内存开销），超过/proc/sys/kernel/threads-max中定义的上限，也会报出OOM异常导致应用进程崩溃；再比如应用进程中打开的文件句柄过多，超过/proc/pid/limits节点中的定义上限，也会报出OOM异常导致应用进程崩溃。如下图所示：
      oom.png

  2. 内存引起的性能性问题：

  • 当应用出现内存抖动或内存泄露的问题时，就会导致虚拟机的GC频繁工作，甚至触发stop-the-world事件，造成应用的UI线程出现挂起阻塞，最终导致上帧出现超时而掉帧。

  • 当后台活跃运行的应用进程过多时，会造成系统总体的剩余内存偏低。此时主要有两个问题可能会造成应用的卡顿：

    a、当内存zone处于低水位时，内核会频繁唤醒kswapd的线程起来执行内存回收的动作；另外内核PSI内存压力信号也会频繁唤醒lmkd进程，进行扫描和杀进程。这些动作都会占用CPU运行资源，导致前台应用UI线程由于抢不到运行CPU资源而出现长时间处于Runnable的问题；

    b、当系统内存不足时，kswapd的线程被唤醒进行内存回收，会将page cache内存页中已经缓存的磁盘文件信息进行大量释放，导致应用进程中的一些IO读文件操作（比如 view 读文件，读配置文件、读 odex 文件等），由于page cache无法命中，触发缺页中断，陷入内核态阻塞等待，一直等到readahead机制从磁盘中将文件内容全部读取出来才能释放返回。当大量进程在进行IO操作时，又进一步加重底层IO的阻塞时长。最终导致前台应用的UI线程长时间处于Uninterruptible Sleep - Block I/O的状态而出现上帧超时卡顿问题。

二、典型案例分析

问题描述：在三方应用唯品会的首页界面上下滑动严重掉帧卡顿。

问题分析：结合Systrace工具分析问题原因如下：

lowmemory block.jpg

从Systrace上可以看到，唯品会应用出现掉帧卡顿的主要原因如下：

  1. 系统内存紧张，频繁唤醒kswapd0线程进行内存回收操作，其持续抢占CPU 5大核心运行，导致应用的UI线程和RenderThread渲染线程频繁出现抢不到CPU资源得不到执行，而处于Runnable的状态，从而导致应用上帧超时而掉帧；

  2. 系统内存紧张时，page cache磁盘文件缓存被内存回收，导致应用的UI线程和RenderThread渲染线程中的一些IO读文件操作无法命中page cache缓存而频繁陷入内核Uninterruptible Sleep - Block I/O的状态，导致应用上帧超时而掉帧。

三、优化思路

针对内存问题引起的性能卡顿问题，常见的优化思路有：

  1. 在应用进程侧：作为应用开发者：

    • 需要解决应用自身的内存泄漏问题，避免频繁的内存分配回收出现的内存抖动现象；

    • 并尽量优化应用的内存占用，包括优化图片加载占用、采用内存更高效的数据结构（如ArrayMap）、采用对象池和图片复用等内存复用机制、功能比较复杂的应用采用多进程方案、尽量优化应用APK包体积大小、监听onTrimMemory事件并及时释放内存中的不必要缓存等；

    • 尽量不要做一些应用进程保活的机制，以免增加系统总体的内存负担；

    • 将应用升级适配到64位版本，以免陷入虚拟内存耗尽而进程崩溃的局面。

    使用Android Studio自带的Profile分析工具进行内存分析与优化，具体用法可以参考这篇文章：https://www.jianshu.com/p/72b213fa6a26。

  2. 在系统总体层面：这部分内容主要属于谷歌和手机厂商的工作，常见的一些针对性优化手段有：

    • 调整lowmemorykiller的杀进程的门限值，让其提前介入清理掉一些低优先级的进程而释放内存，以免系统陷入低内存状态；

    • 适当提高 extra_free_kbytes 值，让kswapd线程能提前介入进行内存回收，以免系统陷入低内存状态；

    • 框架中设计后台应用查杀功能，定期清理后台低优先级应用进程，并限制三方应用的后台保活机制，从而释放内存，以免系统陷入低内存状态；

    • 通过cpuset配置限制kswapd不让其使用部分CPU大核，从而让出CPU资源给前台应用的UI和渲染线程使用；

    • 配置和启动ZRAM和app compaction后台内存压缩机制，从而减少应用进程后台的内存占用，腾出更多的系统可用内存；

    • 优化系统的磁盘IO性能，采用UFS3.1等性能更强的存储器，以减轻系统出现内存低的情况时，出现IO阻塞的时长。

2.4 磁盘I/O引起卡顿

一、理论分析

磁盘是现代计算机系统实现数据持久化存储的核心硬件模块。也是继CPU和内存外系统内另一个重要的公共资源。Android系统内应用程序的运行一般都会伴随有大量的磁盘I/O读写的操作，比如读写数据库、加载XML布局文件、读取配置文件等。但是相对于CPU和内存相比，磁盘的读写访问速度是比较慢的，很容易成为CPU运行的瓶颈，导致系统被拖累。当应用进程的线程中发生直接I/O磁盘读写时，就会导致线程进入Uninterrupt Sleep-Block I/O阻塞状态，如下图所示：

IO block.png

在开始分析磁盘I/O读写的瓶颈引起性能问题原因之前，我们先借用一张简化图来总体看看Linux系统的I/O栈：
linux IO.jpg

从上图可以看出，整个Linux 下的 I/O栈大致有三个层次：

  1. 文件系统层，以 write 为例，内核拷贝了 write 参数指定的用户态数据到文件系统 Cache 中，并适时向下层同步。
  2. 块层，管理块设备的 I/O 队列，对 I/O 请求进行合并、排序。
  3. 设备层，通过 DMA 与内存直接交互，完成数据和具体存储设备之间的交互。

可能存在的性能瓶颈问题如下：

  1. 为了优化文件读写的性能，减少磁盘的I/O 操作，Linux内核系统提供了页缓存（Page Cache）技术，以页为单位将磁盘上的文件内容缓存在内存中，从而提供了接近于内存读写速度的文件顺序读写速度，也就是Buffered I/O。但是当系统剩余内存不足时，系统会回收Page Cache页缓存内存，导致文件读写操作直接落到磁盘上，从而极大降低I/O性能。这也就前一小节中分析的低内存导致的性能卡顿问题。
  2. 上层所有的I/O 请求都会放入队列中进行合并排队处理，这样就可能引发不同应用进程之间的资源抢占问题。比如后台进程存在大量读写磁盘的操作请求，占用系统的I/O 资源，这就会导致前台应用的I/O 请求出现在队列中阻塞排队等待的现象，最终导致掉帧卡顿问题。
  3. 文件系统的性能瓶颈。比如针对NAND闪存特性设计的f2fs文件系统，相比于ext4文件系统，能够提升小文件的随机读写性能，并能减少碎片化的问题。再比如Android 11上引入的Fuse文件系统，增加I/O读写的开销，导致sdcard路径下的部分路径文件的I/O读写性能下降。
  4. 闪存的读写性能瓶颈。一个就是闪存硬件的读写性能差异，比如UFS 3.0相对于UFS 2.1来讲顺序读取速度快90%，顺序写入速度更是提升160%；另外一个问题就是闪存重复写入，需要先进行擦除操作，这样随着时间的推移，磁盘碎片变多，剩余空间少，一个内存页的写入会引起整个磁盘块的迁移，造成耗时操作，也就是早期Android手机给人形成“越用越卡”的印象的原因之一。

二、优化思路

针对I/O磁盘性能的瓶颈，总体优化思路从两个角度来看：

  1. 从手机厂商角度：
    • 采用更大的内存硬件配置，并从总体上优化系统的内存占用。以防止出现系统低内存状态下，Page Cache页缓存被回收后，应用直接写磁盘而导致的I/O阻塞卡顿问题；
    • 启用Linux的cgroup机制对I/O资源的进程隔离机制blkio，将进程按照优先级进行分组（分为前台进程、后台进程、甚至可以根据需求进行更详细的自定义划分），以分配不同的I/O带宽资源，从而解决后台应用进程抢占前台应用I/O资源造成的卡顿的问题；
    • 采用f2fs文件系统，替换ext4文件系统，以提升文件系统的性能；可以针对部分系统文件管理类的应用不走默认的fuse路径，而是走f2fs，以提升其读写性能表现；
    • 采用读写性能更强的闪存器件，比如最新的UFS 3.1；
    • 启用fstrim磁盘碎片整理功能，在息屏、充电等条件下触发磁盘碎片整理的动作，从而减少磁盘碎片，提升磁盘读写性能；系统手机管家模块可以引导用户定期进行垃圾文件的清理，以保证磁盘有充足的剩余空间；
    • 基于mmap内存映射机制，将系统运行常访问的文件Lock锁定到内存缓存中，以提升文件读写的性能，减少真正发生I/O磁盘读写的概率，减轻系统的I/O负载。Android系统框架中的PinnerService服务主要职责就是这个，如下图所示：
      pinner.png

2.从应用开发者角度：

  • 选择合适的文件读写操作。对读写速度有较高的要求，并允许低概率的数据丢失问题，就采用系统默认的基于Page Cache的缓存I/O；对文件读写的速度要求不高，但是需要严格的保证数据不会丢失就使用Direct I/O；如果需要对同一块区域进行频繁读写的情况，对读写性能要求极高，可以采用mmap 内存映射机制实现读写文件，比如腾讯开源的用于改善原生SharePreferences机制性能的存储工具MMKV就是这个原理实现的。
  • I/O 方式的选择。一个是对于阻塞I/O操作尽量放入子线程执行，以免阻塞UI线程；二是适当采用异步I/O减少读取文件的耗时，提升CPU整体利用率，比如Okio就支持异步I/O操作。
  • 优化数据结构，建立内存缓存，尽量减少不必要的I/O；

3 编译引起卡顿性能问题

编译引起的性能问题主要分为两类：一类是代码的解释执行耗时，运行时VerifyClass执行耗时等引发卡顿；二类是编译本身引起的卡顿问题，比如dex2oat编译抢占CPU算力资源，进程中的Jit编译线程抢占CPU算力资源。

3.1 代码解释执行耗时

一、理论分析

Art虚拟机有两种代码执行模式：quick code 模式和 Interpreter 模式。对于dex字节码文件采用的是Interpreter解释执行的模式，每次执行代码，虚拟机需要将代码转换成机器指令集，然后交给CPU去执行，所以执行效率比较低（早期Android系统被诟病性能差的原因之一）。而对于经过编译（AOT的dex2oat编译或JIT运行时及时编译，都需要消耗一定的磁盘空间存储编译出来的机器码文件）后生成的ELF格式机器码文件（如.oat格式文件、.art格式文件），采用quick code模式，直接执行arm 汇编指令，执行效率较高。为了做到性能、磁盘空间占用以及应用安装速度之间的最佳平衡，从Android 7.0 开始，采用AOT+JIT+解释执行的混合模式，其特点如下：

  1. 应用在安装的时候dex中大部分函数代码不会被编译。
  2. App运行时，dex文件先通过解析器被直接执行，热点函数会被识别并被JIT编译后存储在 jit code cache 中并生成profile文件以记录热点函数的信息。
  3. 手机进入 IDLE（空闲） 或者 Charging（充电） 状态的时候，系统会扫描 App 目录下的 profile 文件并执行 AOT 过程进行编译。

所以ART虚拟机在执行一个函数过程中会在 Interpreter 解释器模式和quick code模式切换，具体切换规则如下图所示：

JIT工作流程.png

从上图可以看出，有些时候应用部分代码还是按照Interpreter 模式执行，运行效率较低，从而产生一些性能问题。

二、典型案例分析

问题描述：淘宝等三方应用冷启动速度慢于同平台竞品机型。

问题分析：结合Systrace工具分析问题原因如下：

with_jit.jpg

without_jit.jpg

从与竞品机器的对比Systrace分析可以看到：同一个应用，且在两台手机CPU型号和运行主频一致的情况下，竞品机器上应用冷启动期间，UI线程的Running时长更短，且Jit工作线程上的热点代码编译任务明显少很多。从而可以推断出，问题原因在于竞品机器上的应用代码大部分是以机器码直接执行，而我们是以字节码解释执行，所以效率更低，运行时间更长。为什么会出现这个差异呢？后来对比日志分析发现，原因是竞品机上应用第一次安装打开后一段时间后，系统会触发一次speed-profile模式的dex2oat编译，会根据应用运行期间JIT搜集到的热点函数信息保存后生成的Profile描述文件进行编译，从而将应用启动期间的大部分代码函数编译成了机器码.oat文件，后续再启动应用时即可直接以quick code 模式执行机器码，所以执行效率更高。

三、优化思路

针对代码解释执行造成的性能问题，大致优化思路是尽量让应用代码以机器码形式运行，部分有效的手段有：

  1. 部分手机厂商，在手机预置的应用商店中下载的三方应用，除了APK文件外，还会包含保存有应用热点函数信息的Profile描述文件，这样在应用dex2oat安装时，选择speed-profile模式，就会根据Profile描述文件，将应用的大部分热点函数直接编译成机器码，从而极大的提升应用的性能表现。
  2. 在手机息屏充电，进入Idle状态后，通过JobScheduler机制，启动后台服务，扫描 App 目录下的 profile 文件并执行 AOT 过程进行编译，以达到手机越用越快的效果。

3.2 编译本身耗时

一、理论分析

在dex2oat进程编译应用的过程中，系统会启动很多线程，消耗大量的CPU算力资源。可能会导致前台应用由于抢不到CPU算力资源，其UI线程长时间处于Runnable状态而卡顿。另外应用进程内部，Jit工作线程动态编译时持续运行，如果负载较重，持续跑到CPU大核上，也会造成CPU算力资源抢占。

二、典型案例分析

问题描述：抖音应用界面严重卡顿。

问题分析：结合Systrace工具分析问题原因如下：

dex2oat block.jpg

从上图可以看出：抖音应用界面卡顿的原因是因为其UI线程抢不到CPU算力资源而长时间处于Runnbale状态，而导致这个问题的很大一部分原因就是此时后台dex2oat进程创建多个线程持续执行应用编译动作抢占CPU算力资源。

三、优化思路

针对编译本身耗时引起的性能问题，部分有效的手段有：

  1. 通过cpuset配置，限制dex2oat进程和Jit工作线程对CPU的使用，使其不抢占CPU大核心算力资源，并设置参数限制其创建的线程数。
  2. dex2oat编译应用的动作尽量放在设备息屏，设备处于Idle状态下进行，以免影响前台用户的操作；
  3. 限制三方应用在后台触发执行dex2oat编译动作（从Android 10 开始，谷歌官方通过Selinux权限的管控，禁止了三方应用触发dex2oat的权限）；

参考

Linux系统中I/O操作的数据读写流程介绍 https://zhuanlan.zhihu.com/p/435406445
一文读懂直播卡顿优化那些事儿 https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==&mid=2247491520&idx=1&sn=dbd14f1d0d6107c87c137433ef435b5b&chksm=e9d0d422dea75d34e9788b0355a08132f84e558a6a7fc46bfb8a730f8be80ea77abee1c66e63&mpshare=1&scene=1&srcid=0328FFMqSCGN58JthxnZbEVw&sharer_sharetime=1648435053999&sharer_shareid=3accc00cd7dff7038611325ccc9f75bd&version=4.0.2.6061&platform=win#rd

你可能感兴趣的:(Android卡顿掉帧问题分析之实战篇)

  • android系统selinux中添加新属性property 辉色投像
    1.定位/android/system/sepolicy/private/property_contexts声明属性开头：persist.charge声明属性类型：u:object_r:system_prop:s0图12.定位到android/system/sepolicy/public/domain.te删除neverallow{domain-init}default_prop:property
  • 扫地机类清洁产品之直流无刷电机控制 悟空胆好小 清洁服务机器人单片机人工智能
    扫地机类清洁产品之直流无刷电机控制1.1前言扫地机产品有很多的电机控制，滚刷电机1个，边刷电机1-2个，清水泵电机，风机一个，部分中高端产品支持抹布功能，也就是存在抹布盘电机，还有追觅科沃斯石头等边刷抬升电机，滚刷抬升电机等的，这些电机有直流有刷电机，直接无刷电机，步进电机，电磁阀，挪动泵等不同类型。电机的原理，驱动控制方式也不行。接下来一段时间的几个文章会作个专题分析分享。直流有刷电机会自动持续
  • 2018-07-23-催眠日作业-#不一样的31天#-66小鹿 小鹿_33
    预言日：人总是在逃避命运的路上，与之不期而遇。心理学上有个著名的名词，叫做自证预言；经济学上也有一个很著名的定律叫做，墨菲定律；在灵修派上，还有一个很著名的法则，叫做吸引力法则。这3个领域的词，虽然看起来不太一样，但是他们都在告诉人们一个现象：你越担心什么，就越有可能会发生什么。同样的道理，你越想得到什么，就应该要积极地去创造什么。无论是自证预言，墨菲定律还是吸引力法则，对人都有正反2个维度的影响
  • 《大清方方案》| 第二话 谁佐清欢
    和珅究竟说了些什么？竟能令堂堂九五之尊龙颜失色！此处暂且按下不表；单说这位乾隆皇帝，果真不愧是康熙从小带过的，一旦决定了要做的事，便杀伐决断毫不含糊。他当即亲自拟旨，着令和珅为钦差大臣，全权负责处理方方事件，并钦赐尚方宝剑，遇急则三品以下官员可先斩后奏。和珅身负皇上重托，岂敢有半点怠慢，当夜即率领相关人等，马不停蹄杀奔江汉。这一路上，和珅的几位幕僚一直在商讨方方事件的处置方案。有位年轻幕僚建议快刀
  • 《庄子.达生9》 钱江潮369
    【原文】孔子观于吕梁，县水三十仞，流沫四十里，鼋鼍鱼鳖之所不能游也。见一丈夫游之，以为有苦而欲死也，使弟子并流而拯之。数百步而出，被发行歌而游于塘下。孔子从而问焉，曰：“吾以子为鬼，察子则人也。请问，‘蹈水有道乎’”曰：“亡，吾无道。吾始乎故，长乎性，成乎命。与齐俱入，与汩偕出，从水之道而不为私焉。此吾所以蹈之也。”孔子曰：“何谓始乎故，长乎性，成乎命？”曰：“吾生于陵而安于陵，故也；长于水而安于
  • Goolge earth studio 进阶4——路径修改与平滑 陟彼高冈yu Googleearthstudio进阶教程旅游
    如果我们希望在大约中途时获得更多的城市鸟瞰视角。可以将相机拖动到这里并创建一个新的关键帧。camera_target_clip_7EarthStudio会自动平滑我们的路径，所以当我们通过这个关键帧时，不是一个生硬的角度，而是一个平滑的曲线。camera_target_clip_8路径上有贝塞尔控制手柄，允许我们调整路径的形状。右键单击，我们可以选择“平滑路径”，这是默认的自动平滑算法，或者我们可
  • 高端密码学院笔记285 柚子_b4b4
    高端幸福密码学院（高级班）幸福使者：李华第（598）期《幸福》之回归内在深层生命原动力基础篇——揭秘“激励”成长的喜悦心理案例分析主讲：刘莉一，知识扩充:成功=艰苦劳动+正确方法+少说空话。贪图省力的船夫，目标永远下游。智者的梦再美，也不如愚人实干的脚印。幸福早课堂2020.10.16星期五一笔记:1，重视和珍惜的前提是知道它的价值非常重要，当你珍惜了，你就真正定下来，真正的学到身上。2，大家需要
  • 2020-04-12每天三百字之连接与替代 冷眼看潮
    不知道是不是好为人师，有时候还真想和别人分享一下我对某些现象的看法或者解释。人类社会不断发展进步的过程，就是不断连接与替代的过程。人类发现了火并应用火以后，告别了茹毛饮血的野兽般的原始生活（火烧、烹饪替代了生食）人类用石器代替了完全手工，工具的使用使人类进步一大步。类似这样的替代还有很多，随着科技的发展，有更多的原始的事物被替代，代之以更高效、更先进的技术。在近现代，汽车替代了马车，高速公路和铁路
  • 398顺境，逆境 戴骁勇
    2018.11.27周二雾霾最近儿子进入了一段顺境期，今天表现尤其不错。今天的数学测试成绩喜人，没有出现以往的计算错误，整个卷面书写工整，附加题也在规定时间内完成且做对。为迎接体育测试的锻炼有了质的飞跃。坐位体前屈成绩突飞猛进，估测成绩能达到12cm，这和上次测试的零分来比，简直是逆袭。儿子还在不断锻炼和提升，唯恐到时候掉链子。跑步姿势在我的调教下，逐渐正规起来，速度随之也有了提升。今晚测试的50
  • 东南林氏之九牧林候选父系 祖缘树TheYtree
    渊源介绍东晋初年晋安林始祖林禄公入闽，传十世隋右丞林茂，由晋安迁居莆田北螺村。又五世而至林万宠，唐开元间任高平太守，生三子：韬、披、昌。韬公之孙攒，唐德宗立双阙以旌表其孝，时号"阙下林家"。昌公字茂吉，乃万宠公第三子，官兵部司马，配宋氏，生一子名萍。萍于唐贞元间明经及第，官沣洲司马(后追赠中宪大夫)。唐太和年间归隐后，迁居仙游游洋，世称“游洋林”；其后裔居游洋后迁移漳州漳浦路下，由路下林第四房平和
  • 大伟说成语之唉声叹气 求索大伟
    ＊大伟说成语＊【唉声叹气】叹气：因心里不痛快或不如意而吐出长气，发出声音。因为痛苦、憋闷或感伤而发出叹息的声音。【大伟说】情绪外露，非人类所特有，动物亦有情绪，悲哀和欢乐所表示的情绪亦是不一样的，会嗷嗷大叫也会低吟痛哭。不同的是，人类的情绪更复杂，更多样，更丰富。唉声叹气，可以说是最基础的情绪，因为无奈而举足无措，不知该如何如何化解，只有独自一人慢慢承受，长吁短叹不知如何是好，其实是无能无力的表现
  • libyuv之linux编译 jaronho Linuxlinux运维服务器
    文章目录一、下载源码二、编译源码三、注意事项1、银河麒麟系统（aarch64）（1）解决armv8-a+dotprod+i8mm指令集支持问题（2）解决armv9-a+sve2指令集支持问题一、下载源码到GitHub网站下载https://github.com/lemenkov/libyuv源码，或者用直接用git克隆到本地，如：gitclonehttps://github.com/lemenko
  • 怎么做淘客赚钱(2022最新免费淘客盈利的方法) 高省_飞智666600
    很多人都不知道什么是淘宝客，今天小编为大家解答一下吧。淘宝客，现在简称淘客，是时下比较流行的一个词语，特质为淘宝店推广商品获取提成的人，这些人没有自己的产品，只是在淘宝里面选择适合自己的产品，在自己比较熟悉的领域推广，把产品卖出去之后，会从淘宝店家那里获得百分之五到百分之五十左右的佣金。淘宝客付出的是什么呢？时间。你需要花时间去选适合自己推广的产品，需要花时间去选自己的推广方法，如果你打算自己做个
  • Python爬虫解析工具之xpath使用详解 eqa11 python爬虫开发语言
    文章目录Python爬虫解析工具之xpath使用详解一、引言二、环境准备1、插件安装2、依赖库安装三、xpath语法详解1、路径表达式2、通配符3、谓语4、常用函数四、xpath在Python代码中的使用1、文档树的创建2、使用xpath表达式3、获取元素内容和属性五、总结Python爬虫解析工具之xpath使用详解一、引言在Python爬虫开发中，数据提取是一个至关重要的环节。xpath作为一门
  • 锁之缘 尘缘诗词原创作品
    是谁追寻梦的足迹，是谁在偷偷的哭泣，日月隔离在黑白天地情感在心中蔓延的痕迹天与地的距离有多远流失的星晨落入哪片空间不要让泪水模糊双眼心牢中一样充满温暖谁说爱情没有永远白娘子又为何爱许仙蝴蝶墓地展翅翩翩轻歌慢舞袖卷人间传奇千古留爱万年…………月落星飞徘徊是选择不去问自已为合舍不得寂寞本就是痛苦的不在追寻梦中的痕迹才不会失去真实的自已
  • ARM驱动学习之基础小知识 JT灬新一 ARM嵌入式arm开发学习
    ARM驱动学习之基础小知识•sch原理图工程师工作内容–方案–元器件选型–采购（能不能买到，价格）–原理图（涉及到稳定性）•layout画板工程师–layout（封装、布局，布线，log）（涉及到稳定性）–焊接的一部分工作（调试阶段板子的焊接）•驱动工程师–驱动，原理图，layout三部分的交集容易发生矛盾•PCB研发流程介绍–方案，原理图(网表)–layout工程师（gerber文件）–PCB板
  • ARM驱动学习之5 LEDS驱动 JT灬新一 嵌入式C底层arm开发学习单片机
    ARM驱动学习之5LEDS驱动知识点：•linuxGPIO申请函数和赋值函数–gpio_request–gpio_set_value•三星平台配置GPIO函数–s3c_gpio_cfgpin•GPIO配置输出模式的宏变量–S3C_GPIO_OUTPUT注意点：DRIVER_NAME和DEVICE_NAME匹配。实现步骤：1.加入需要的头文件：//Linux平台的gpio头文件#include//三
  • ARM驱动学习之4小结 JT灬新一 嵌入式C++arm开发学习linux
    ARM驱动学习之4小结#include#include#include#include#include#defineDEVICE_NAME"hello_ctl123"MODULE_LICENSE("DualBSD/GPL");MODULE_AUTHOR("TOPEET");staticlonghello_ioctl(structfile*file,unsignedintcmd,unsignedlo
  • C++ | Leetcode C++题解之第409题最长回文串 Ddddddd_158 经验分享C++Leetcode题解
    题目：题解：classSolution{public:intlongestPalindrome(strings){unordered_mapcount;intans=0;for(charc:s)++count[c];for(autop:count){intv=p.second;ans+=v/2*2;if(v%2==1andans%2==0)++ans;}returnans;}};
  • 2020-12-24 我和我的天使们
    阅读《老子的心事》391—403“将欲取之，必固与之”：想要得到什么，首先就要送出什么。我常常对孩子们说，你希望别人怎样对你你就怎样对待别人。想要得到别人的尊重，首先要尊重别人。我希望她们可以不迟到，因为不迟到是对别人的尊重，我就自己就先做到不迟到。哪怕是约朋友逛街，我尽量准时赴约。我严格要求孩子们，也同样严格要求自己，我跟孩子们一起把好的品格变成习惯。“是谓微明”：这就是微妙的智慧。看起来很少很
  • 18、架构-可观测性之聚合度量 大树~~ 架构javapython后端架构
    聚合度量聚合度量是指对系统运行时产生的各种指标数据进行收集、聚合和分析，以了解系统的健康状况和性能表现。聚合度量是可观测性的关键组成部分，通过对度量数据的分析，可以及时发现系统中的异常和瓶颈。以下是对聚合度量各个方面的详细解析，并结合具体的数据案例和技术支撑。指标收集收集系统运行时产生的各种指标数据是聚合度量的基础。常见的指标包括CPU使用率、内存使用率、请求处理时间、请求数、错误率等。以下是指标
  • 学习“论语”-第59天 春峰轩
    12.14子张问政。子曰：“居之无倦，行之以忠。”子张问为政之道。孔子说：“在位尽职不懈怠，执行政令要忠诚。”12.15子曰：“博学于文，约之以礼，亦可以弗畔矣夫！”孔子说：“君子广泛地学习文献，并且用礼节约束自己，也就不会离经叛道了。”12.16子曰：“君子成人之美，不成人之恶。小人反是。”孔子说：“君子成全别人的好事，而不助长别人的坏处。小人则与此相反行事。”知识点:“成人之美，不成人之恶”贯
  • 2021-11-15 宙火
    我给宋小姐写了首诗，是我在课上因思恋宋小姐而写的。“自古多情是唐宋，从来双飞归巢燕。邻家小女相聘婷，常使春意荡漾我。不知单思可为爱，惟愿一心付之汝。”我拿给宋小姐看了，她说我写得很棒。我很开心，但又不是那么开心。宋小姐是回复我了，但也只是说我写得很棒，对我诗句中蕴藏的真切感情，不知道是真的没发现，还是装作没发现。但我不深究，只是这样，我就很开心了。我答应宋小姐，一天给她写一首诗。
  • 2019-10-24 柒月的可可
    今日上班无事，人又懒怠动，不知道如何打发这个下午，终于打开了。我大概是把当日记来写的。重庆的天气骤然凉了。早上出门的时候，满地都是落叶，脚踩上去，却是刚下过雨，叶子已润掉，走不出声响。白天在办公室不见天日，对温度也无甚感觉，晚上一个人回到家，屋子里窗户都开着，被冷风吹了一天，一迈进屋，便觉冷气森然。将近二十度的天气，竟要裹着毯子才觉温暖。再过一周，就到十一月。扛过十一月，就可以开暖气了。然而我真的
  • 《我的青葱岁月之缘来是你》 第二章 迎新晚会 思源思缘思怨
    “怎么你也来了这里？”我愉快的问到，想着这是上天给的缘分吗？我还没去找他竟然就相遇了。那个让我开心的老乡。“你好，我也是舞蹈社的新人啊！”他说，笑起来回答我，眼睛弯弯的。“这么巧，我叫吴倩，你叫啥？”“我叫韩欢，你也是B市人吧，c中毕业的？”“我不是，我是f中的，不然肯定会认识你的”“是吗？以后多多关照了”他还冲我眨了眨眼睛。内心一阵悸动，这是……回到寝室，我兴奋的告诉我的室友这个事情，我再次觉得
  • 数据结构之哈希表 X同学的开始 数据结构数据结构散列表
    哈希表(散列表)出现的原因在顺序表中查找时，需要从表头开始，依次遍历比较a[i]与key的值是否相等，直到相等才返回索引i；在有序表中查找时，我们经常使用的是二分查找，通过比较key与a[i]的大小来折半查找，直到相等时才返回索引i。最终通过索引找到我们要找的元素。但是，这两种方法的效率都依赖于查找中比较的次数。我们有一种想法，能不能不经过比较，而是直接通过关键字key一次得到所要的结果呢？这时，
  • 厦门自由行之第一天: 大苏子在广漂
    厦门三人行之杂记出发前一天:12️28日下午15:00从广州粗发，来深圳集合！但是中间发生一个小插曲，验票时候发现车票不见了，或许也是一场恶作剧，对于不排队的人，忍不住说了一下，接下来就发现车票不见了，已经是拿在手上！不过还好，可以凭借购票订单查看到信息，所以有惊无险，顺利进站！晚上三个人一起去吃了柠檬鱼，说实话，那会，感觉美吃饱，啊哈哈！晚上回来，两个人又开始彻夜长谈，发现身边优秀的人，一大把，
  • “这才好”麻辣香锅 能够增加人身体的免疫能力 小补文知
    我就来介绍一种香锅，那就是“这才好”麻辣香锅，它产出于著名的蜀地文化，具有悠久的历史土家风味，麻辣鲜香，健康安全。采用传统秘制麻辣香锅油辣子，还有贴心加料“孜然包”满足人们的不同口味需求，香锅底料辣椒，微辣且香，含有丰富微量元素和维生素，具有辣而不躁，味道纯正，醇厚温和。花椒采用历史悠久，被列为宫廷供品的“贡椒”的汉源花椒。我们还挑选了“川菜之魂”郫县豆瓣的鼻祖品牌豆瓣，保留最原始的郫县豆瓣味道，
  • 《太虚游》第六十二章。玄牝之威。 古楼臭道士
    “好好好，流云这孩子深得我心，想必长爻知道是你的话定然会惊喜不已的。”白玄牝听得风流云应了下来，脸色慈和，伸手在他头顶轻轻抚了抚，如同抚在怀中九尾小狐一样自然，极其温柔。身后的四位青丘长老同时一怔，嘴角微动，似要开口劝阻。风流云只感到一道霞光瑞气如有实质一般顺着头顶百会大穴直沉在下丹田内，随后这股气息又逐渐凝聚，似乎给自己吃了什么东西一般。啊喔不好，这祖奶奶该不会是看中我这肉身，像人魔一样，要给她
  • 2.2.6 通知类控件 Toast、Menu 常思行
    本文例程下载：WillFlow_Toast、WillFlowMenu一、什么是Toast？Toast也被叫做吐司，是Android系统提供的一种非常好的提醒方式，在程序中可以使用它将一些短小的信息通知给用户，它有如下两个特点：Toast是没有焦点的Toast显示的时间有限过一定的时间就会自动消失所以一般来讲Toast的使用并不会影响我们的正常操作，并且它通常不会占用太大的屏幕空间，有着良好的用户体
  • 用MiddleGenIDE工具生成hibernate的POJO（根据数据表生成POJO类） AdyZhang POJOeclipseHibernateMiddleGenIDE
    推荐:MiddlegenIDE插件,   是一个Eclipse   插件.     用它可以直接连接到数据库,   根据表按照一定的HIBERNATE规则作出BEAN和对应的XML ，用完后你可以手动删除它加载的JAR包和XML文件!     今天开始试着使用
  • .9.png Cb123456 android
      “点九”是andriod平台的应用软件开发里的一种特殊的图片形式，文件扩展名为：.9.png 　　智能手机中有自动横屏的功能,同一幅界面会在随着手机(或平板电脑)中的方向传感器的参数不同而改变显示的方向,在界面改变方向后,界面上的图形会因为长宽的变化而产生拉伸,造成图形的失真变形。 　　我们都知道android平台有多种不同的分辨率，很多控件的切图文件在被放大拉伸后，边
  • 算法的效率 天子之骄 算法效率复杂度最坏情况运行时间大O阶平均情况运行时间
    算法的效率 效率是速度和空间消耗的度量。集中考虑程序的速度，也称运行时间或执行时间，用复杂度的阶(O)这一标准来衡量。空间的消耗或需求也可以用大O表示，而且它总是小于或等于时间需求。   以下是我的学习笔记：   1.求值与霍纳法则，即为秦九韶公式。   2.测定运行时间的最可靠方法是计数对运行时间有贡献的基本操作的执行次数。运行时间与这个计数成正比。
  • java数据结构 何必如此 java数据结构
    Java 数据结构 Java工具包提供了强大的数据结构。在Java中的数据结构主要包括以下几种接口和类： 枚举（Enumeration） 位集合（BitSet） 向量（Vector） 栈（Stack） 字典（Dictionary） 哈希表（Hashtable） 属性（Properties） 以上这些类是传统遗留的，在Java2中引入了一种新的框架-集合框架(Collect
  • MybatisHelloWorld 3213213333332132
    //测试入口TestMyBatis package com.base.helloworld.test; import java.io.IOException; import org.apache.ibatis.io.Resources; import org.apache.ibatis.session.SqlSession; import org.apache.ibat
  • Java|urlrewrite|URL重写|多个参数 7454103 javaxmlWeb工作
     个人工作经验！ 如有不当之处，敬请指点 1.0  web -info 目录下建立     urlrewrite.xml  文件 类似如下： <?xml version="1.0" encoding="UTF-8" ?>   <!DOCTYPE u
  • 达梦数据库+ibatis darkranger sqlmysqlibatisSQL Server
    --插入数据方面 如果您需要数据库自增... 那么在插入的时候不需要指定自增列. 如果想自己指定ID列的值, 那么要设置 set identity_insert  数据库名.模式名.表名; ----然后插入数据; example: create table zhabei.test( id bigint identity(1,1) primary key, nam
  • XML 解析 四种方式 aijuans android
    XML现在已经成为一种通用的数据交换格式,平台的无关性使得很多场合都需要用到XML。本文将详细介绍用Java解析XML的四种方法。 XML现在已经成为一种通用的数据交换格式,它的平台无关性,语言无关性,系统无关性,给数据集成与交互带来了极大的方便。对于XML本身的语法知识与技术细节,需要阅读相关的技术文献,这里面包括的内容有DOM(Document Object
  • spring中配置文件占位符的使用 avords
    1.类 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.o
  • 前端工程化-公共模块的依赖和常用的工作流 bee1314 webpack
    题记： 一个人的项目，还有工程化的问题嘛？   我们在推进模块化和组件化的过程中，肯定会不断的沉淀出我们项目的模块和组件。对于这些沉淀出的模块和组件怎么管理？另外怎么依赖也是个问题？ 你真的想这样嘛？   var BreadCrumb = require(‘../../../../uikit/breadcrumb’); //真心ugly。  
  • 上司说「看你每天准时下班就知道你工作量不饱和」，该如何回应？ bijian1013 项目管理沟通IT职业规划
    问题：上司说「看你每天准时下班就知道你工作量不饱和」，如何回应         正常下班时间6点，只要是6点半前下班的，上司都认为没有加班。   Eno-Bea回答，注重感受，不一定是别人的         虽然我不知道你具体从事什么工作与职业，但是我大概猜测，你是从事一项不太容易出现阶段性成果的工作
  • TortoiseSVN，过滤文件 征客丶 SVN
    环境： TortoiseSVN 1.8 配置： 在文件夹空白处右键 选择  TortoiseSVN -> Settings 在 Global ignote pattern 中添加要过滤的文件： 多类型用英文空格分开 *name ： 过滤所有名称为 name 的文件或文件夹 *.name ： 过滤所有后缀为 name 的文件或文件夹 --------
  • 【Flume二】HDFS sink细说 bit1129 Flume
    1. Flume配置   a1.sources=r1 a1.channels=c1 a1.sinks=k1 ###Flume负责启动44444端口 a1.sources.r1.type=avro a1.sources.r1.bind=0.0.0.0 a1.sources.r1.port=44444 a1.sources.r1.chan
  • The Eight Myths of Erlang Performance bookjovi erlang
    erlang有一篇guide很有意思： http://www.erlang.org/doc/efficiency_guide 里面有个The Eight Myths of Erlang Performance： http://www.erlang.org/doc/efficiency_guide/myths.html   Myth: Funs are sl
  • java多线程网络传输文件(非同步)-2008-08-17 ljy325 java多线程socket
    利用 Socket 套接字进行面向连接通信的编程。客户端读取本地文件并发送；服务器接收文件并保存到本地文件系统中。 使用说明:请将TransferClient, TransferServer, TempFile三个类编译，他们的类包是FileServer. 客户端: 修改TransferClient: serPort, serIP, filePath, blockNum,的值来符合您机器的系
  • 读《研磨设计模式》-代码笔记-模板方法模式 bylijinnan java设计模式
    声明： 本文只为方便我个人查阅和理解，详细的分析以及源代码请移步 原作者的博客http://chjavach.iteye.com/ import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.ResultSet;
  • 配置心得 chenyu19891124 配置
    时间就这样不知不觉的走过了一个春夏秋冬，转眼间来公司已经一年了，感觉时间过的很快，时间老人总是这样不停走，从来没停歇过。 作为一名新手的配置管理员，刚开始真的是对配置管理是一点不懂，就只听说咱们公司配置主要是负责升级，而具体该怎么做却一点都不了解。经过老员工的一点点讲解，慢慢的对配置有了初步了解，对自己所在的岗位也慢慢的了解。 做了一年的配置管理给自总结下： 1.改变 从一个以前对配置毫无
  • 对“带条件选择的并行汇聚路由问题”的再思考 comsci 算法工作软件测试嵌入式领域模型
    2008年上半年，我在设计并开发基于”JWFD流程系统“的商业化改进型引擎的时候，由于采用了新的嵌入式公式模块而导致出现“带条件选择的并行汇聚路由问题”(请参考2009-02-27博文)，当时对这个问题的解决办法是采用基于拓扑结构的处理思想，对汇聚点的实际前驱分支节点通过算法预测出来，然后进行处理，简单的说就是找到造成这个汇聚模型的分支起点，对这个起始分支节点实际走的路径数进行计算，然后把这个实际
  • Oracle 10g 的clusterware 32位 下载地址 daizj oracle
    Oracle 10g 的clusterware 32位 下载地址 http://pan.baidu.com/share/link?shareid=531580&uk=421021908 http://pan.baidu.com/share/link?shareid=137223&uk=321552738 http://pan.baidu.com/share/l
  • 非常好的介绍：Linux定时执行工具cron dongwei_6688 linux
    Linux经过十多年的发展，很多用户都很了解Linux了，这里介绍一下Linux下cron的理解，和大家讨论讨论。cron是一个Linux 定时执行工具，可以在无需人工干预的情况下运行作业，本文档不讲cron实现原理，主要讲一下Linux定时执行工具cron的具体使用及简单介绍。 新增调度任务推荐使用crontab -e命令添加自定义的任务（编辑的是/var/spool/cron下对应用户的cr
  • Yii assets目录生成及修改 dcj3sjt126com yii
    assets的作用是方便模块化，插件化的，一般来说出于安全原因不允许通过url访问protected下面的文件，但是我们又希望将module单独出来，所以需要使用发布，即将一个目录下的文件复制一份到assets下面方便通过url访问。 assets设置对应的方法位置 \framework\web\CAssetManager.php   assets配置方法 在m
  • mac工作软件推荐 dcj3sjt126com mac
    mac上的Terminal + bash ＋ screen组合现在已经非常好用了，但是还是经不起iterm＋zsh＋tmux的冲击。在同事的强烈推荐下，趁着升级mac系统的机会，顺便也切换到iterm＋zsh＋tmux的环境下了。 我为什么要要iterm2 切换过来也是脑袋一热的冲动，我也调查过一些资料，看了下iterm的一些优点： * 兼容性好，远程服务器 vi 什么的低版本能很好兼
  • Memcached(三)、封装Memcached和Ehcache frank1234 memcachedehcachespring ioc
    本文对Ehcache和Memcached进行了简单的封装，这样对于客户端程序无需了解ehcache和memcached的差异，仅需要配置缓存的Provider类就可以在二者之间进行切换，Provider实现类通过Spring IoC注入。 cache.xml <?xml version="1.0" encoding="UTF-8"?>
  • Remove Duplicates from Sorted List II hcx2013 remove
    Given a sorted linked list, delete all nodes that have duplicate numbers, leaving only distinct numbers from the original list. For example,Given 1->2->3->3->4->4->5,
  • Spring4新特性——注解、脚本、任务、MVC等其他特性改进 jinnianshilongnian spring4
    Spring4新特性——泛型限定式依赖注入 Spring4新特性——核心容器的其他改进 Spring4新特性——Web开发的增强 Spring4新特性——集成Bean Validation 1.1(JSR-349)到SpringMVC  Spring4新特性——Groovy Bean定义DSL Spring4新特性——更好的Java泛型操作API  Spring4新
  • MySQL安装文档 liyong0802 mysql
      工作中用到的MySQL可能安装在两种操作系统中，即Windows系统和Linux系统。以Linux系统中情况居多。   安装在Windows系统时与其它Windows应用程序相同按照安装向导一直下一步就即，这里就不具体介绍，本文档只介绍Linux系统下MySQL的安装步骤。   Linux系统下安装MySQL分为三种：RPM包安装、二进制包安装和源码包安装。二
  • 使用VS2010构建HotSpot工程 p2p2500 HotSpotOpenJDKVS2010
    1. 下载OpenJDK7的源码：      http://download.java.net/openjdk/jdk7      http://download.java.net/openjdk/      2. 环境配置     ▶
  • Oracle实用功能之分组后列合并 seandeng888 oracle分组实用功能合并
    1       实例解析 由于业务需求需要对表中的数据进行分组后进行合并的处理，鉴于Oracle10g没有现成的函数实现该功能，且该功能如若用JAVA代码实现会比较复杂，因此，特将SQL语言的实现方式分享出来，希望对大家有所帮助。如下： 表test 数据如下： ID,SUBJECTCODE,DIMCODE,VALUE 1&nbs
  • Java定时任务注解方式实现 tuoni javaspringjvmxmljni
    Spring 注解的定时任务，有如下两种方式： 第一种： <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"  xmlns:xsi="http
  • 11大Java开源中文分词器的使用方法和分词效果对比 yangshangchuan word分词器ansj分词器Stanford分词器FudanNLP分词器HanLP分词器
    本文的目标有两个： 1、学会使用11大Java开源中文分词器 2、对比分析11大Java开源中文分词器的分词效果 本文给出了11大Java开源中文分词的使用方法以及分词结果对比代码，至于效果哪个好，那要用的人结合自己的应用场景自己来判断。 11大Java开源中文分词器，不同的分词器有不同的用法，定义的接口也不一样，我们先定义一个统一的接口： /** * 获取文本的所有分词结果, 对比
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他