1. Performance optimization (1) APP startup optimization -https
://juejin.im/post/5cc19374e51d456e781f2036 - Optimization scheme in Appcation:
open child threads, no Handler is created in the thread, no UI is operated, and there is no high requirement for asynchronous
lazy loading , Initialize when used, such as network, database, picture library, or some third-party libraries.
Use the IntentService onHandleIntent () method to initialize some time-consuming operations to
optimize FlashActivity
2. Performance optimization (2) UI rendering optimization -https://juejin.im/post/5cc2dfc7e51d456e845b4260
How to reduce the time consumption of these two things to meet the requirements of 16ms rendering to complete the
CPU and reduce the time to convert xml into objects. 2. GPU reduces the time of repeated drawing.
3. Performance optimization (3) APP memory abnormal problem-https
://juejin.im/post/5cd82a3ee51d456e781f20ce Common memory analysis tools: top/procrank; meinfo; Procstats; DDMS; MAT; Finder-Activity; LeakCanary; LeakInspector;
memory leak , The reason: A long-lived object holds a reference to a short-lived object. In layman's terms, it is the object that should be recycled. Because the reference problem is not recycled, OOM will eventually occur.
How does JAVA GC determine memory reclamation?
At present, virtual machines basically use reachability analysis algorithms. Why not use reference counting algorithms? Let's talk about the reference counting method, if it counts the reference count of all objects, and then compare how the reachability analysis algorithm solves the deficiencies of the reference counting algorithm.
Reference counting algorithm: Each object has a reference counter. When the object is referenced once, the counter is increased by one, and when the object reference is invalid once, the counter is decreased by one. When the counter is 0, it means garbage and can be recycled by GC .
Start the search from GC Roots as the starting point, then the edges of the objects in the entire connected graph are all live objects. Objects that cannot be reached by GC Roots become garbage collection objects and may be collected by GC at any time.
It can be used as the object of GC Roots: the reference used by the virtual machine stack is running; the static property constant; the object referenced by JNI.
If an object has a strong reference, the garbage collector will never reclaim it. When the memory space is insufficient, the Java virtual machine would rather throw an OOM error to make the program crash, and will not recycle objects with strong references to solve the memory. Insufficient problem. If the strongly referenced object is no longer used, it needs to be weakened so that the GC can reclaim it.
Java reference types: strong reference; soft reference; weak reference; phantom reference.
Memory jitter: Frequent memory allocation and recovery (when the allocation speed is greater than the recovery speed) will eventually produce OOM.
4. Performance optimization (4) ubuntu perfectly compiles the libjpeg image compression library , which is comparable to the WeChat image compression algorithm-https://juejin.im/post/5ce15d0ce51d45106e5e6dac I
believe that some of the pictures are only 1M when using the iPhone to send pictures via WeChat. , But the resolution is clearer than that of an Android phone's 5 M picture size, so why is this? .
When Google was developing Android at that time, it considered that the configuration of most mobile phones was not that high, so Skia was used for image processing. Of course, the bottom layer of this library still uses jpeg image compression processing. But in order to be able to adapt to low-end mobile phones (the low-end here refers to the previous mobile phones with low hardware configuration, the CPU and memory are very tight on the mobile phone, and the performance is poor), because the Huffman algorithm is more CPU-intensive and codec Slow, forced to use other algorithms. Therefore, Skia did not turn on the Huffman algorithm in the lower version of the image processing.
So, what exactly is JEPG? JEPG (the full name is Joint Photographic Experts Group) is a common image format. Why do I mention JEPG here? It is because a C/C++ library is open sourced. The bottom layer is based on the Huffman algorithm for image compression (libjpeg).
libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2, AVX2, NEON, AltiVec) to Accelerate baseline JPEG compression and decompression on x86, x86-64, ARM and PowerPC systems, and progressive JPEG compression on x86 and x86-64 systems.
Use Huffman algorithm to compress pictures.
JEPGLIB image compression, Huffman algorithm image compression LIBJPEG_SAMPLE-https://github.com/yangkun19921001/LIBJPEG_SAMPLE
5. Performance optimization (5) Long image optimization, imitating Weibo loading long image method-https://juejin.im/post/5ce96da06fb9a07ee4633f50
loading long image control, anti Weibo loading method-https://github.com/yangkun19921001 /long_picture_view
6. Performance optimization (6) The boss asks you about the power consumption of our APP- https: //juejin.im/post/5ce9088f6fb9a07ee4633ef3
Power optimization part of the code- https:
//github.com/yangkun19921001/battery Google's open source power analysis tool battery- historian- https://github.com/google/battery-historian
Battery Historian is a tool for checking battery-related information and events on Android devices running Android 5.0 Lollipop (API level 21) and higher, and the device is not plugged in.
7. Performance optimization (7) Dex
encryption and decryption of APK reinforcement -https: //juejin.im/post/5cf3ee295188256aa76bb1e1 APK reinforcement dex encryption and decryption- https:
//github.com/yangkun19921001/DexEncryptionDecryption ClassLoader is still very important, hot Repairing and hot loading are based on this principle.
8. Performance optimization (8) Dynamic replacement of APK reinforcement Application-https: //juejin.im/post/5cf69d30f265da1b897abd53
ActivityThread.java
mian() -> thread.attach() -> attachApplication() -> Receive AMS sent After the parameters, sendMessage (H.BIND_APPLICATION) -> process BIND_APPLICATION -> handleBindApplication() Prepare application here -> Application app = data.info.makeApplication() -> mInitialApplication = app;
The principle of the reinforcement process: subcontract from dex -> encryption -> alignment> signature -> package and compress into APK.
9. Performance optimization (9) Exploration of the hot repair principle of APP stability -https
:
//juejin.im/post/5cfce989f265da1b6c5f6991 Instrumentation principle: It is known from the source code that findClass finds the class by traversing dexElements, if we reflect to get the DexPathList Private array dexElements, we change the internal order index of this array externally, and put the repaired dex into the position of [0], then can the repaired dex be used first? Obviously, it is established.
10. Performance optimization (10) Process keep-alive implementation of APP continuous operation - https: //juejin.im/post/5cffe4d4f265da1b695d55d4
Process keep-alive solution - https: //github.com/yangkun19921001/KeepAlive
keep-alive component- https:/ /github.com/fanqieVip/keeplive
monitors mobile phone lock screen unlock events, starts 1 pixel transparent activity when the screen is locked, and destroys the activity when the user unlocks, thereby achieving the effect of improving the process priority.
Reliable (Activity + Service escalation + Service mechanism activation + JobScheduler timing check whether the process is running + background playback of silent files + dual-process guarding), and then constitute an ultimate process keep-alive program.
11. Performance optimization (11) ProGuard compresses code and resources -https:
//juejin.im/post/5d05dab06fb9a07ea9446e21 What is ProGuard? ProGuard can be understood as a tool for code and resource compression. It can provide compression, optimization, obfuscation, and pre-verification of Java class files. The compression step is to detect and remove unused classes, fields, methods, and attributes. The optimization step is to analyze and optimize the bytecode of the method. The obfuscation step is to rename the remaining classes, fields, and methods with short, meaningless names. Compression, optimization, and obfuscation make the code smaller and more efficient.
12. Performance optimization (12) APK extreme compression -https
:
//juejin.im/post/5d0627f7f265da1bd4247e76 The latest version of WeChat 6.5.7 (except for the image selector) -https://github.com/GitLqr/LQRWeChat AndResGuard Yes A tool to reduce the size of the APK, its principle is similar to Java Proguard, but only for resources. It shortens the originally lengthy resource path, for example, res/drawable/wechat becomes r/d/a.