“What will be hot and what to learn in 2022? This article is participating in the” Talk about 2022 Technology Trends “essay campaign.

What is “good” technology and why is “hot”

Preface: This is a personal point of view, technology should be used in the appropriate business scenarios to reflect its advantages, rather than blindly to learn, to see

Solve the technical pain points developed today

coroutines

Callback hell, switching threads and other functions

a()// Time-consuming task

b()
Copy the code

When the code blocks executed by method A and method B are not dependent on each other, the time-consuming task can be executed asynchronously. By starting a thread or Posting a Runnable to method A, METHOD B can run directly without waiting for the completion of method A.

However, if a and B are dependent, method B needs to use the data returned by method A for processing, but in order not to affect the code blocking after method B, so a callback will be passed into method A. After the execution of method A, the callback interface will be called, and method B will be executed in the callback method

If your business has very complex dependencies, you can go to callback hell in a way that is either not elegant or the code is not intuitive (the logic is too complex)

Comparatively speaking:

Coroutines are “elegant” in this respect; Switching threads also requires only one line withContext (); The code is more intuitive (Sen has experience, used to be a point here and then there, the discovery of the point is dizzy, rest dishes)

By the way, these features are not unique to coroutines, but can be implemented by other tools or by building your own wheels. But while the functionality of the technology is important, so are its platform-based and native apis (discussed later in the technology ecology section).

pluggable

While the technology isn’t “new,” everyone knows the benefits and pain points it solves:

1. Dynamically update the APP

(It’s an entire APP update, not a hotfix that fixes a single issue. At present, the implementation method is to store the latest plug-in APK in the cloud, and check the version number every time to see whether it needs to be updated. Of course, it is necessary to ensure the security of APK, which can be guaranteed through some encryption and decryption.)

2. Reduce package size

(The host only needs a small space and only has one purpose. Pull up the APK under Assets and dynamically load the four components and plug-in code in the plug-in.)

3. When the business scale becomes larger and larger, it may not only load our app, but also load other people’s app.

Express company prior to refactor the code is the use of plug-in package, but the plug-in solutions have restrictions on the version of the SDK, can only use low version of the SDK to develop, and a whole and not to the strong dependence of (only four modules is not necessary to separate into an app), so after reconstructing abandoned the plugin. So it depends on the actual project.

What can be learned from this technology

As the saying goes: Know what you know. If blindly used as a tool alone, but ignore the mystery of its internal implementation; Of course it is not impossible, just feel some regret.

Choose the right data structure, choose the right algorithm, suit the design pattern of the actual scene

For example, the data structure used to store context in coroutines (linked lists), the tree structure used in exception handling mechanisms…… Wait (why is there so little of this because I’ve only scratched the surface….)

What can we learn from plugins? That’s a lot to learn,

If you are using HOOK method, you can learn four components of the startup mechanism, startup process, Android native resource handling mechanism, class loading mechanism, APK installation process….. And so on.

If you implement bytecode Transform, you can learn Gradle build process, Gradle custom TASK, Android packaging process, ASM for bytecode Transform,JavaAssist framework, Class structure, Dex structure. And so on.

How’s that？ Looking at these knowledge, is not ready to move ha ha, and the system source code but Google engineers to write, the data structure and algorithm is also bound to be excellent, and can learn a lot of knowledge.

performance

Coroutines are officially recommended, and Kotlin’s official documentation says they’re better than threads, but you’ll actually find that in the single-threaded case, there’s really no difference. (Remember to look at the thread pool they use first if you have multiple threads.)

For plugins, different implementations are bound to perform differently. The Hook method wastes more performance than the Transform method because it uses reflection. The performance of reading the ContentProvider from the manifest file XML at run time is going to be a little bit more wasteful than the performance of reading the ContentProvide from the manifest file into the metadate from the manifest file at compile time and having a native API to support lookup, and so on and so forth and the performance is going to be different depending on how these are implemented.

Development efficiency

Using coroutines is a great way to write asynchronous code synchronously, but it’s not the only one available. Other tools can also provide it. However, flow, Kotlin, and so on can be used with coroutines to encapsulate low-level operations and provide more friendly support.

Plug-in efficiency this is not a big touch, may not have experienced.

Strong platform support

Coroutines are more kotlin friendly and can be written in Java, but not as friendly in terms of writing code (you pass arguments every time you call a pending function, etc.).

As with hotfixes, the Android patch pack upgrade is not available on ios, and it’s fun to Hook the FrameWork.

Rich API

Many of the APIS in coroutines, if you do not understand some of the principles of the mechanism, the probability of problems is very large… Here is a pit (simplified version) we met before:

//withTimeoutOrNull this method means that when the timeout period expires it will return null (I returned 0).
valResult = withTimeoutOrNull(specifies the timeout period to be5Second) {// Create a coroutine
    suspendCoroutine{
        // Block code here
        }
    }?:0

// represents subsequent operations
val a=0
Copy the code

At this point he’s not going to return zero, so it’s blocked, and a equals zero never goes to zero. Why is that? This is where the exception cancellation mechanism for coroutines comes in.

When a child coroutine is created in a coroutine, the parent-child relationship is established by default. When the parent coroutine is cancelled, all its child coroutines must be cancelled to complete the cancellation. The subcoroutine you just created does not support cancellation, so it is blocked.

How did you solve it? Can change the sub coroutines to cancel is ok, is replaced by suspendCancellableCoroutine is good,

Also, there are few articles on the web that correct coroutine usage errors, so there will be an opportunity to document common errors later.

Here’s what I think the tech trends are:

Yes, the two haha mentioned above: coroutine plugins

Finally, a few days ago in the group saw a big man said a good sentence, to share with everyone:

Technology is constantly changing, volume is constant.