文章目录
- 1. 崩溃优化
- 2. 内存优化
- 2.x 内存优化工具
- 2.x 查看内存的相关命令
- 参考资料
- 3. 卡顿优化
- 3.1 基础知识
- 3.2 Andorid 卡顿排查工具
- 3.3 可视化方法
- 3.4 如何监控应用卡顿
- 3.5 卡顿现场与卡顿分析
- 3.6 总结
- 3.7 参考资料
- 4. UI优化
- 4.1 硬件加速
- 4.2 Projbect Buffer
- 相关工具
- 参考资料
- 5. 启动优化
- 6.存储优化
- 7. 网络优化
- 8. 耗电优化
- 9. I/O 优化
- 10. 体积优化
- `11. 安全`
- `性能配置`
- `APM平台支持`
- 参考资料
1. 崩溃优化
2. 内存优化
内存的主要索引
Native Heap
对象 = null，内存会减少占用么？
https://www.zhihu.com/question/21356272
2.x 内存优化工具
Android Studio/Memory-Profiler
1 强制内存回收按钮
2 Dump the Java heap
3 开始／停止记录内存分配情况
4 缩小／放大时间线
5 实时播放内存分配情况（这个按钮点下试试便清楚了）
6 发生一些事件的记录(如Activity的跳转，事件的输入，屏幕的旋转)
7 内存使用时间线
关于顶部的几种内存类型介绍：
Java : java代码分配的内存
Native:c/c++代码分配的内存(有时候其实并没有使用到c/c++代码,但还是会有Native的内存分配，因为Android Framework会去通过java代码访问一些需要使用Native的资源，如图像资源Bitmap)
Graphics:图像缓存等，包括GL surfaces, GL textures等.
Stack:栈内存（包括java和c/c++）
Code:代码的内存分配（例如代码，资源，libs等等），处理代码和资源（如 dex 字节码、经过优化或编译的 dex 代码、.so 库和字体）的内存。
Other:这个是连系统都不知道是什么类型的内存，放在这里.
Allocated: jave分配的对象个数 (在Android7.1和以下的设备，这个计数是在设备连接后开始，所以并不是app启动时候的计数。Android8.0或更高，在系统里面内置的Profiler工具，所以无论什么时候连接，都是app启动时候的计数)
参考文档资料:https://www.jianshu.com/p/e75680772375
参考资料：https://developer.android.com/studio/profile/memory-profiler
Android Studio/Memory Monitor 观察 Dalvik内存
dumpsys meminfo 观察整体内存
smaps 观察整体内存的详细组成
Eclipse Memory Analyzer 详细分析 Dalvik 内存
2.x 查看内存的相关命令
https://blog.csdn.net/bigconvience/article/details/35553983
procrank
dumpsys meminfo <package_name>
PSS：表示一个进程在RAM中实际使用的空间地址大小，它按比例包含了共享库占用的内存。假如有3个进程使用同一个共享库，那么每个进程的PSS就包括了1/3大小的共享库内存。这种方式表示进程的内存使用情况较准确，但当只有一个进程使用共享库时，其情况和RSS一模一样。
USS：表示一个进程本身占用的内存空间大小，不包含其它任何成分，这是表示进程内存大小的最好方式！
可以看到:VSS>=RSS>=PSS>=USS
参考资料
https://developer.android.google.cn/topic/performance/memory
3. 卡顿优化
对用户来说，内存占用高，耗费电量，耗费流量可能不容易被发现(放屁)，但是用户对于卡顿特别敏感；对于开发者来说，卡顿的问题确实非常难以排查定位，产生的原因错综复杂，跟 CPU，内存，磁盘I/O 等都有可能有关，与系统环境也有很大关系；
流畅度（左右切换，上下滑动列表的时候掉帧、窗口动画不连贯、重启机器 进入桌面卡顿）、响应速度（应用启动白屏过长、点击电源键亮屏慢、按键后 界面 不跟眼/卡）、稳定性（界面操作没有反应然后闪退、点击图标没有响应）这三个大的分类
到底如何定位卡顿呢？本地有哪些工具能帮助我们更好的发现和排查问题呢？工具之间的差异又是？
3.1 基础知识
造成卡顿的原因千百种，不过最终都反应在CPU时间上；CPU时间分为 用户时间(执行用户态应用程序代码所消耗的时间) 和 系统时间(执行内核态系统调用所耗费的时间，包括I/O，锁，终端以及其它系统调用的时间)。
1.CPU性能
投影仪品牌包括极米投影仪、坚果投影仪、米家投影仪、酷乐视投影仪、明基投影仪、神画投影仪、索尼投影仪、微鲸投影仪、当贝投影仪；电视的话包括 小米电视，TCL，海信，康佳，创维 等
CPU的性能 需要看 主频，核心，缓存等参数，具体 表现 在 计算能力 和指令执行能力；
智能电视有以下厂商：
台湾：晨星 Mstar、联发科MTK、瑞昱 Realtek
内地：晶晨 Amlogic、海思 Hisilicon、全志 Allwinner、瑞芯微 Rockchip
晨星 Mstar是目前智能电视的芯片主流品牌，对智能电视的画质有着先进处理基础。
比较主流的芯片为 Mstar，MTK，Amlogic.
好像近几年，Amlogic 又异军突起了，性能不仅不错，而且售价更加低廉… …我们公司最近也准备采用 Amlogic方案；
Mstar 6A938 > Mstar 6A848 > Amlogic T968 > Mstar 6A838 > MSD 6A638 > Mstar 6A628
可以通过下面的方法获得设备的CPU信息：
获取CPU核心数
/sys/devices/system/cpu/possible
获取某个CPU的频率
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
Mstar 6A848 属于一款中高端芯片，四核64位CPU，好像是 大小核心(大核心用来支持高负载场景，小核心用来日常使用).
从848平台获取的相关信息：
/sys/devices/system/cpu/possible 核心数 0~3
/sys/devices/system/cpu/cpu2~3/cpufreq/cpuinfo_max_freq CPU频率 1500000
cpu0~1/cpufreq/cpuinfo_max_freq CPU频率 1350000
system-background/cpus 0~1 # 低优先级的任务会被划分到这里，只能跑到小核心里面
background/cpus 0 # 后台进程
foreground/boost/cpus 2~3 # 前台 boost 进程，通常是用来联动的，现在已经没有用到了，之前的时候是应用启动的时候，会把所有 foreground 里面的进程都迁移到这个进程组里面
foreground/cpus 2~3 # 前台进程
top-app/cpus 2~3 # 目前正在前台和用户交互的进程
tasks # 获取节点下有哪些 进程 和 线程 跑在这个组
随着机器学习与AI的崛起，电视的CPU不仅有强大的GPU，还携带了NPU。
所以，在电视开发中，可以根据设备的CPU性能写代码以及优化，例如线程池使用线程数根据CPU的核心数，一些高级的AI功能只在主频比较高或者带NPU的设备开启。
线程池的大小经验值一般这样设置：（其中N为CPU的核数）
如果是CPU密集型应用，则线程池大小设置为N+1
如果是IO密集型应用，则线程池大小设置为2N+1
2.卡顿问题分析指标
回到CPU时间，也就是用户时间和系统时间
3.2 Andorid 卡顿排查工具
从全局到局部
可以先使用 Bootchart 查看开机的时候，哪些应用比较耗时.(如果已经知道那个应用耗时，可以不使用)
或者直接 使用 Systrace 通过APP的主线程 或 SurfaceFlinger的主线程信息确定卡顿现场.
TraceView + 源码分析，能快速定位代码哪里耗时.
Bootchart
http://www.bootchart.org/
在系统启动过程中自动收集 CPU 占用率、磁盘吞吐率、进程等信息，并以图形方式显示分析结果，可用作指导优化系统启动过程。
rm -rf /data/bootchart/*
touch /data/bootchart/enabled
echo 60 > /data/bootchart/start
sync # 执行完后，重启机器，跑了一段后，执行下面的命令
cd /data/bootchart;tar -zcf boochart.tgz *
adb pull /data/bootchart/boochart.tgz // 将文件拷贝出来
java -jar bootchart.jar boochart.tgz // 生成 bootchart 图片，就是下面的图片
整个图表以时间线为横轴，图标上方为 CPU 和 磁盘的利用情况，下方是各进程的运行状态条，显示各个进程的开始时间与结束时间以及对 CPU、I/O 的利用情况，我们关心的各个进程的运行时间以及 CPU 的使用情况，进而优化系统，当然也可以知道那些应用启动比较耗时，进而选择优化.
1.TraceView 寻找卡主主线程的地方
关注两个点：1.很耗时的函数 Incl Cpu Time(CPU占用时长) 2. 调用频繁的函数. Calls + Recur Calls / Total(调用次数)
// 代码可以插入:
Debug.startMethodTracing("TestApp");
...
Debug.stopMethodTracing();
// 会在sdcard上生成一个”TestApp.trace”的文件.
// android 9.0 在 /sdcard/Android/data/xxx.xxx.xxx/files
使用 monitor ，打开 导出的 files 下面的文件
也可以直接使用 Android Studio 的 profiler 工具
2.Nanoscope
3.systrace
界面使用说明: https://source.android.google.cn/devices/tech/debug/systrace?hl=zh-cn
# 需要PC端配合TV端使用.
platform-tools/systrace 目录下的 systrace.py
命令行使用文档: https://android-doc.github.io/tools/help/systrace.html# demo:
python systrace.py -o mynewtrace.html sched freq idle am wm gfx
view binder_driver hal dalvik camera input respython systrace.py -b 32768 -t 5 -o mytrace.html wm gfx input view sched freq
./systrace.py -b 32768 -t 5 -o mytrace.html wm gfx input view sched freq //等价python systrace.py -a com.xgimi.home -b 16384 \-o my_systrace_report.html sched freq idle am wm gfx view binder_driver hal \dalvik camera input res# 如果出现 "Invalid trace result format for HTML output" 就添加下面的命令选项 --no-compress
systrace.py --time=10 --no-compress -o=trace.html sched gfx view -a com.xgimi.home# 如果还有问题，直接机器内使用命令atrace -b 10240 -t 10 -z sched idle view disk > /sdcard/trace_output3python systrace.py --from-file trace_output3
| 参数 | 说明 |
|---|---|
| -o | 输出的目标文件 |
| -t N, -time=N | 执行时间，默认5s |
| b N, -buf-size=Nbuffer | 大小（单位kB),用于限制trace总大小，默认无上限 |
| -k ，-ktrace= | 追踪kernel函数，用逗号分隔 |
| -a <APP_NAME>, -app=<APP_NAME> | 追踪应用包名，用逗号分隔 |
| –from-file=<FROM_FILE> | 从文件中创建互动的systrace |
| -e <DEVICE_SERIAL>,–serial=<DEVICE_SERIAL> | 指定设备 |
| -l, –list-categories | 列举可用的tags |
| category | 说明 |
|---|---|
| wm | Window Manager |
| am | Activity Manager |
| freq | CPU Frequency |
| idle | CPU Idle |
| disk | Disk input and output |
| view | View |
| input | Input |
| gfx | Graphics |
shell dumpsys gfxinfo com.miui.home 查看 framestats 数据输出
| Janky frames | 95th percentile | |
|---|---|---|
| 848 | 10(0.81%) | 14ms |
| 958C | 22(0.09%) | 6ms~8ms |
从数据来看，明显958C比848要好很多.
4.Simpleperf
3.3 可视化方法
1.Call Chart
2.Flame Chart
3.4 如何监控应用卡顿
3.5 卡顿现场与卡顿分析
3.6 总结
3.7 参考资料
Android Systrace 基础知识(1) – Systrace 简介
Android Systrace 基础知识(2) - Systrace 预备知识
Android Systrace 基础知识(3) – Why 60 fps ？
Android Systrace 基础知识(4) - SystemServer 解读
Android Systrace 基础知识(5) - SurfaceFlinger 解读
Android Systrace 基础知识(6) - Input 解读
Android Systrace 基础知识(7) - Vsync 解读
Android Systrace 基础知识(8) - Vsync-App ：基于 Choreographer 的渲染机制详解
Android Systrace 基础知识(11) - Triple Buffer 解读
Android Systrace 基础知识(12) - Kernel 中的 CPU Info 解读
Systrace 流畅性实战 1 ：了解卡顿原理
新的流畅体验，90Hz 漫谈
4. UI优化
UI渲染 依赖两个核心硬件：CPU 与 GPU；
Rasterization（栅格化）操作 是一个非常耗时的操作,GPU可以加快 栅格化 操作；
绘制过程主要是由 CPU 来进行 Measure、Layout、Record、Execute的数据计算工作，GPU 负责 栅格化、渲染。
所谓的栅格化就是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操作；
官方长期重视 Android UI 渲染性能，基本每次I/O大会啰嗦一番；每个开发者都希望自己的应用 可以做到 60 fps 如丝般顺滑，相比IOS系统，渲染性能 一直被吐槽；
Android为了弥补和IOS的差距，每个版本都做了大量的优化；了解 Android 图形 系统 整体架构，以及它包含的主要组件；
绘制过程各个图形组件的作用：
- 画笔：Skia(绘制2D图形，使用CPU绘制) 或 OpenGL(绘制2D/3D图形，使用GPU绘制)；
- 画纸：Surface。所有的元素都在 Surface 这张画纸上进行 绘制 和 渲染。在 Android 中，Window 是 View 的容器，每个窗口都会关联一个 Surface。而 WindowManager 则负责管理这些 窗口，并且把它们的数据传递给 SurfaceFlinger。
- 画板：Graphic Buffer。Graphic Buffer 缓冲用于应用程序图形的绘制，在 Android 4.1 之前使用的是双缓冲机制；在 Android 4.1 之后，使用的是三缓冲机制
- 显示：SurfaceFlinger。它将 WindowManager 提供的所有 Surface，通过硬件合成器 Hardware Composer 合成并输出到显示屏。
4.1 硬件加速
Android 3.0 之前，没有硬件加速时，系统会使用软件方式来 渲染UI
整个流程如上图所示：
- Surface：每个 View 都由某一个窗口管理，而每一个窗口都关联有一个 Surface。
Canvas。 - Canvas：通过 Surface 的 lock 函数获得一个 Canvas，Canvas 可以简单理解为 Skia 底层接口的封装。
- Graphic Buffer：SurfaceFlinger 会帮我们托管一个BufferQueue，我们从 BufferQueue 中拿到 Graphic Buffer，然后通过 Canvas 以及 Skia 将绘制内容栅格化到上面。
- SurfaceFlinger：通过 Swap Buffer 把 Front Graphic Buffer 的内容交给 SurfaceFinger，最后硬件合成器 Hardware Composer 合成并输出到显示屏。
CPU 对于图形处理并不是很高效，过程完全没有利用到GPU的高性能；所以从 Android 3.0开始 支持硬件加速，Android 4.0时，默认开启；
硬件加速 与 软件绘制 差异非常大，最核心是通过 GPU 完成 Graphic Buffer 的内容绘制；
硬件绘制 还引入 DisplayList 的概念，每个View内部都有一个 DisplayList，当某个View 需要重绘时，标记为 Dirty。
当需要绘制时，硬件绘制 仅仅只需要重绘一个 View 的 DisplayList，软件绘制时 需要向上递归。
硬件加速大大减少绘图的操作数量，所以提高了 渲染效率。
如下图所示：
每日一问 | 属性动画与硬件加速的相遇，不是你想的那么简单？
4.2 Projbect Buffer
2012 I/O 大会宣布 Project Butter(包含两个部分：1. VSYNC，2. Triple Buffering) 黄油计划，并在 Android 4.1 正式开启这个机制。
VSYNC信号
对于 Android 4.0，CPU繁忙，可能会导致UI绘制来不及处理；
为了解决此问题，Project Buffer 引入 VSYNC(官方文档)
三缓存机制 Triple Buffering
GPU 渲染模式分析演示
相关工具
工欲善其事必先利其器
我们优化RecyclerView之前，肯定需要先找到相关原因，这里就需要借助一些工具.
Android Studio 查看布局层级(Layout Inspector)
Show GPU Overdraw(检测过渡绘制（Overdraw）的工具)
Profile GPU Rendering 检查界面的渲染性能。该工具以滚动柱状图呈现渲染界面每帧所花费的时间(16ms的速度作为对比基准)
谷歌官方资料
Systrace 性能分析工具
Tracer for OpenGL ES
Graphics API Debugger
dumpsys
gfxinfo 命令(dumpsys gfxinfo packageName)，获取 渲染相关的内存和 View Hierarchy 信息
谷歌官方(https://developer.android.com/training/testing/performance)
重点关注
Total frames rendered: 39 # 一共多少帧
Janky frames: 12 (30.77%) # 有12帧超过16ms，掉帧的概率为 30.77%
50th percentile: 10ms
90th percentile: 77ms
95th percentile: 150ms
99th percentile: 250ms
Number Missed Vsync: 2 # 垂直同步失败的帧
Number High input latency: 0 # 处理input时间超时的帧数
Number Slow UI thread: 12 # 因UI线程上的工作导致超时的帧数
Number Slow bitmap uploads: 1 # 因bitmap的加载耗时的帧数
Number Slow issue draw commands: 4 # 因绘制导致耗时的帧数
dumpsys gfxinfo packageName framestats ，gfxinfo命令新增 framestats参数(拿到最近120帧每个绘制阶段的耗时信息)
SurfaceFlinger(dumpsys SurfaceFlinger)，查看 Graphic Buffer 占用的内存
Choreographer(帧率)
参考资料
深入浅出 Android 屏幕刷新原理
Android绘制优化（一）绘制性能分析
Android性能优化第（四）篇—Android渲染机制
Android的UI底层是用CPU绘图的还是GPU绘图的呢？以及surfaceview,window,普通view是如何实现的？
深入Android渲染机制
手机屏幕的前世今生 可能比你想的还精彩
具体可以参考《Android 屏幕适配全攻略》
Why 60 fps？
https://www.jianshu.com/p/ca7abd7fad77
Vulkan 和 OpenGL 区别
https://developer.android.com/studio/build/shrink-code.html
Android 图形系统的整体架构，以及它包含的主要组件。
https://source.android.com/devices/graphics
硬件加速绘制
https://developer.android.google.cn/guide/topics/graphics/hardware-accel
RenderThread:异步渲染动画
https://mp.weixin.qq.com/s?__biz=MzUyMDAxMjQ3Ng==&mid=2247489230&idx=1&sn=adc193e35903ab90a4c966059933a35a&source=41&scene=21#wechat_redirect
OLED 和 LCD 有什么区别？
https://www.zhihu.com/question/22263252
Android UI 渲染机制的演进，你需要了解什么？
https://www.jianshu.com/p/279f727b00bc
5. 启动优化
6.存储优化
7. 网络优化
8. 耗电优化
9. I/O 优化
10. 体积优化
apkchecker
11. 安全
反破解包括几个方面：静态分析，动态调试，防止重编译
11.1.静态分析：
- 代码混淆技术
- NDK保护，Native代码；
- 外壳保护(代码加密技术)，UPX加壳工具，市面上也有相关的加固平台；
11.2.动态调试：
- 检测调试器，android:debuggable=“false”，让程序不可以调试，代码判断如下：
if ((getApplicationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE) != 0) {android.os.Process.killProcess(android.os.Process.myPid());
}
// 也可以判断是否有调试器连接
android.os.Debug.isDebuggerConnected()
- 检测模拟器
ro.product.model: sdk，手机的值为 手机的型号；
ro.build.tags：test-keys，手机的值为 release-keys；
ro.kernel.qemu：模拟器为 1，正常手机没有该属性；
DroidBox 一款开源的Android程序动态分析工具
在线Android软件的静态与动态分析 http://mobilesandbox.org
11.3.动态调试：
- 检查签名
- 校验保护：判断classes.dex文件的Hash值
性能配置
CPU 的性能
APM平台支持
俗话说的话，剩下还得靠监控(卡顿，网络，帧率，)的
市场上有很多商业化的 APM 平台，比如著名的 NewRelic，还有国内的 听云
、OneAPM 等等。
参考资料
Android 性能优化必知必会(2020-5-16)
