I'm participating in the "Nuggets · Sail Project"
In order to attract attention, I really did everything I could, and I wrote all the titles I could think of. You can see it...
Let’s talk nonsense first :
I heard that there are more and more Android jobs recently. Have you gone for an interview?
Interviewer : You mentioned Caton optimization in your resume. What optimizations have you done? Let’s talk about it.
You : Oh, my mind quickly flashed through articles on the Internet, and then said memory leaks, memory jitter, startup optimization, layout optimization, image optimization, network optimization...
Interviewer : Details, more details.
You : Oh, ah, hahaha...\
The original intention of the article :
There are a lot of optimization articles on the Internet, with various topics. Every time I read those great articles, I think it makes sense. Ah, I know it, but when it is actually applied to the project, I don’t know where to start... What
? , is that you? Anyway, that's really me. So I wanted to share some small optimizations I made, try to make the theme as clear as possible, make it easier to get started after reading it, and make the world a better place "polish for future interviews"...
Do not introduce third-party libraries such as Matrix, 本文宗旨：先从简单处入手，尽量主题明确.
Android Profiler
The Master said: "If a worker wants to be good at his work, he must first sharpen his tools. Living in a state, he will serve the sages of his officials, and befriend the benevolent men of his scholars."
If you are just starting to optimize, then don't come up and talk about systrace and traceview "has been abandoned", take a look at the Android Profiler first. See what it can do:
- The CPU Profiler helps pinpoint runtime performance issues.
- Memory profiler helps to track memory allocations.
- Network Performance Analyzer monitors network traffic usage.
- Energy Profiler tracks energy consumption, which can help analyze issues with fast battery drain.
memory leak
ps: If you are proficient in this paragraph, you can skip it. In addition, only the java layer is involved, and the native layer leakage is not involved.
A few years ago, when it came to memory leaks, many people would think of LeakCanary, which is easy to get started, and often asked LeakCanary's implementation principle/why it can't be applied online, etc... Now the times have changed, and the official direct blood
relatives coming.
The Studio version used in this article: Android Studio Giraffe | 2022.3.1 Beta 1
Let me talk about the positioning steps first
-
Create a leaky environment: Click
on several more pages in the App, complex pages can perform multiple entry/exit operations, and then return to the App home page; -
Open the Profiler interface:
- Click the green box below to select the icon
- As shown in the figure below, you need to enter the memory module to troubleshoot memory problems
- Capture the heap dump "that is, select the content in the green box", and click record, and the analysis will automatically start, just wait
- After automatic stop, the following display will appear:
- Select the green box option to filter out memory leaks at the activity/fragment level
Caton "drop frame/ANR"
Applicable scenario: It is known that a certain behavior will trigger a freeze, eg: click on a tab to enter a certain page
Let me talk about the positioning steps first
- Enter Profiler, click to enter CPU module
- Select the fourth "Java/Kotlin Method Sample" and click record
- After clicking stop, wait for the file to be generated. If necessary, you can right-click and save it as a trace file; double-click the main module, and click to analyze what the UI thread has done.
Seeing the picture above, I have probably realized that things are not so simple...Why? Look at the color:
- Calls to system APIs are shown in orange;
- Calls to the app's own methods are shown in green;
- Calls to third-party APIs, including Java language APIs, are shown in blue
tip: You can also zoom in/out by adjusting the positions of the two arrows in the green box below
The next step is to focus on the green part and see why the green length is so obvious due to its own method.
解决的问题
下面列出来的，都是我通过上面的方式，解决的部分问题。
声明：以下数据均比生产环境的值要小...
1.PackageInfo 相关的问题
通过 CPU Profiler 可以看到下图
/**
* App 通过 PackageManager 去获取应用信息，是卡顿操作，若多个地方调用应存储为常量
*/
val packageInfo: PackageInfo? by lazy { PackageUtils.getPackageInformation(App.context) }
val applicationInfo: ApplicationInfo? by lazy { packageInfo?.applicationInfo }
val packageName by lazy { packageInfo?.packageName }
val packageVersionCode by lazy { packageInfo?.versionCode }
val packageVersionName by lazy { packageInfo?.versionName }
val firstInstallTime by lazy { packageInfo?.firstInstallTime ?: 0L }
val lastUpdateTime by lazy { packageInfo?.lastUpdateTime ?: -1L }
2.Websocket 使用问题
如下图，发现 UI 线程里面有大量 GSON 解析的操作，再跟踪，发现 App 中对于 WebSocket 的数据接收和处理，基本上是 UI 线程，造成掉帧 or 卡顿 or ANR。其实也惭愧，这个问题竟然之前没注意...
对于我们的 App 来讲，更致命，因为场景主要是歌房，消息基本都是通过 ws 来处理的，里面有各种UI的频繁更新、各种动效、各种动画、歌曲演唱...
所以凭借这个优化了整个App 对于 ws 的使用，改完后经住了测试组的压测、发热/卡顿等都好了很多，具体方法思路在这里 Android性能优化实战 - 直播间场景
3.EmojiManager.renderEmoji 方法
4.图文混排
项目中应该都有这种形式，text+icon 这种，如果在 RecyclerView 中使用，那卡顿就比较明显了
5.骨架屏耗时
这是之前的业务需求，后来一跑太耗时，直接下掉了...
6.获取通知是否可用
业务中很多关于是否获取通知权限的判断，这种case 应该存为全局常量，必要情况再去重新获取值。
Profiler 部分小结
这里说的只是初步使用，还有更细节且更精准定位某个方法的方式，需要去继续探索了。不过虽是初步使用，但是在我公司的项目里解决了不少问题，大家也开始吧 ～ 在一些场景下用 Profiler 去定位卡顿是不方便的，所以有很多优秀的框架 Matrix、Booster、KOOM 等。
线程优化
这个主题很大，开始的话，时间也比较长，前期储备较多知识点，具体应用还要结合自己的项目，我在这里只是提一下主题。
这个文章可以让你上手，并且认识到所需要的知识点：AOP 面向切面编程, 字节码插桩, 自定义 Gradle Plugin + Transform + ASM「小白操作版」
这个文章可以让你了解的多一些：AOP / 面向切面编程 / 字节码插桩 / ASM / 字节码扫盲学习 / 解读版
最后说点
- 上面关于 LeakCanary 的问题，不会的话去查一查吧，再深入的话会接触到 Matrix ，关于 Matrix 的记录我也写过，看这里Matrix-TraceCanary 实际使用
- 本文重点是在整理，提到的东西不新，但是比较经典。
- 整理这个过程挺好的，过程中会锻炼自己的总结概括能力，仔细审视自己提及到的知识点是否正确，所以你也开始吧。
知识体系非常重要，零散接受知识点的话比较被动，所以学习过程中就需要整理自己的知识体系，这样面试的时候就可以从点到面展开了「我假设的」。- 多看 Android 官方文档，看 Android 官方文档提到的项目，比如你想
系统学习最近很火的 MVI/Compose。 - 身处旋涡，就再挣扎一下。
- 其实这些乱七八糟的写的不是我本意，但是逼着自己写一下。为什么我会这么费尽心思的想写点啥? 因为掘金姐告诉我了，只要我好好写，就给我一个证书，然后我就想用那个证书发个朋友圈... 你会帮我点赞的对么？