Author: GSYTech
Recently, after chatting (yu) with some “old Androd” who had switched jobs, I felt quite touched. Having been in Android development for so many years, everyone has begun to rethink the future development, more or less the “bottleneck” of their career. As for worries, there is a feeling of "cannot stay" lingering in my mind.
Recalling the development process of Android development in the past six years, Android now has a mature development system, and the technical framework has also undergone generations of updates:
- HttpClient、Volley 、OkHttp、Retrofit ；
- ImageLoader、Picasso、Fresco、Glide；
- OrmLite、LitePal、GreenDao、Realm、Room；
In addition to the familiar "three major pieces" of networks, pictures, and databases, there are also such as xUtils, EventBus, Dagger, RxJava, MultiType, etc., for the old Android, it can be said that they are memories that run through the entire "adolescence".
From the beginning of MVC to MVP to MVVM and even the official AAC architecture, Android’s technology stack has been “refreshing”. With the promotion of Kotlin and the introduction of Android Jetpack, a new generation of perfect development system is also available to old developers. We brought some extra "irritability".
"Isn't AS 2.3 unavailable?!"
"The project will continue to be compatible with version 4.4?!!!"
"RxJava started playing coroutines before they even used it?!!!"
Because of the maintenance of old projects or the impact of the working environment, many times there is no condition for the implementation of the new framework, and even the emergence of Flutter will be a wave of anxiety.
Let us talk about this anxiety or anxiety.
"Unused" anxiety
For the old Android, there is a kind of "anxiety" emotion from "I haven't used it" , because the new framework and technology are constantly iterating, and the emotion of "I can't keep up with the times if I haven't used it" will always It is repeatedly amplified during the iteration of technology updates, which is probably the source of some Android anxiety.
For example, the current Android Jetpack, coroutines, Jetpack Compose, Flutter, etc., every time they see these words, they will inexplicably appear "anxious", just like I heard Dagger, RxJava, and React Native at the beginning of the year.
So how can (tao) relieve (bi) this anxiety? This requires understanding the reasons why these "new technology" terms continue to appear. I understand this "I haven't used it" anxiety as "wrench upgrade side effects".
Here is an interesting example, as shown in the figure below are different stages of wrenches, you can see:
- From 1 to 2 the number of wrenches that users need to prepare for screwing nuts is reduced;
- From 2 to 3 wrenches have become more handsome and powerful, and the accompanying "attack power" has also increased;
Here comes the question:
1. Since there is a convenient wrench like 2, is it necessary for a wrench to exist?
- The answer is yes, because the wrench in 1 is more cost-effective and lighter in certain scenarios.
2. Since Wrench 2 satisfies most scenarios, is Wrench 3 necessary?
- The answer is also yes, because the wrench in 3 is more handsome and more reliable from a robust point of view.
The two questions here are actually meant to express: Under the circumstances, with the development of technology, the new framework and technology are to make development more convenient, while lowering the development threshold to facilitate the entry of newcomers.
So as an old Android developer, after experiencing the era of manual gear that requires a "pile of wrenches" for development projects, now in this era of semi-automatic gear that only needs a "wrench" to work, how can it be impossible to screw the nut?
In the past, we have screwed countless nuts, but now we just need to change a "wrench", and this wrench may be 3, the first time I picked it up may be "too heavy", the switch is not skilled, but once The nut needs to "tighten how deep" and "what position to hold", which for us is actually not much different from before.
So as long as we still "tighten the nut", we should not worry about too many categories of "wrench", or we should "grate" that this field is still developing healthily.
The healthy evolution of technology will only make it easier to understand and use, and the barriers to development will become lower and lower:
- Changes from RxJava1 to RxJava2;
- From Dagger to the official Koin;
- From Java's AsyncTask to Kotlin's coroutine;
- From ButterKnife to KTX;
So using a new "wrench" is definitely more convenient than using a bunch of old "wrenches". In fact, the code and logic that developers need to maintain will become less and less. This is a manifestation of an increasingly mature community, and thus the threshold for development. It is getting lower and lower.
As for the anxiety that the new technology cannot be implemented into the project, we can change our thinking: there is no condition to land, but we can try to understand the nature of this new framework or technology, so as to alleviate the fear of the unknown.
For example, Dagger simply generates code based on annotations and templates, so if you can't understand various "jerky" annotations, you can directly look at the generated code to understand how Dagger uses "bloated" code to decouple us.
In addition, in the next Android Studio 4.1, the direct jump of the Dagger class has been supported, and we can easily navigate between Dagger's associated code.
Therefore, the cost of learning to change a "wrench" is not high, as long as you have the knowledge to twist the nut . "I haven't used it now" don't panic, maybe wait until the technology is more mature and easier to learn, not to mention wait for the article of the big prostitute, right?
Of course there is another interesting misunderstanding here:
Wrench 2 is better than Wrench 1 after the upgrade, so as the one who uses Wrench 2 is better than Wrench 1?
However, the truth is: the great person is the maker of the wrench, and as a user, the direct use of OkHttp may not be as "profound" as the development of HttpClient.
The framework lowers the barriers to development and improves the maintainability of the code. However, while enjoying the convenience as users, it is not the use at all to become awesome, but the need to understand why the framework is easy to use!
For example, OkHttp's usefulness lies in its excellent interceptor design, while Retrofit uses annotations to generate template code to improve development efficiency, but Retrofit itself still needs OkHttp to support the network request part.
Eat the excellent parts of the framework, then you will become awesome. The design of OkHttp is perfectly reproduced by the Dio framework in Flutter, and the Dio framework has become one of the popular network request packages under Flutter.
Competitiveness anxiety
There is also the anxiety of competitiveness. We will compare ourselves with the younger generation of developers from time to time. It is obvious that young people are cheaper, more resistant to C, and more stamina . This makes us who are about to become the first wave of career anxiety.
Because of the lowering of the threshold brought by the maturity of the development system, the requirements for developing Android applications are indeed not as high as before, but "usable" and "easy to use" are two stories!
Compared with young people, we have some disadvantages, but as an old developer, we still have some other advantages in competitiveness, such as business understanding and landing ability .
To give a simple example, the product puts forward a requirement on Android:
"Add a playback function, the effect is similar to iQiyi."
What a "reasonable" demand. At this time, the old Android who has "eaten salt" believes that they will "tremble in their hearts". While silently "greeting" the product, they begin to think about the "pits" that need to be discussed before development:
- Does the video need to specify a good encoding format, such as H264/AAC, MPEG/MP3?
- Is MP4 or M3U8 as the encapsulation protocol?
- Do bitrate and frame rate need to adapt to the network?
- Use soft decoding FFMPEG or MediaCodec?
- Does the video need to support AES128 encryption?
- Do you want to increase the offline cache locally?
- Do you want to support reconnection after disconnection?
- Will we support the expansion of live broadcast and advertising in the future?
Although the code written in the above part can be used regardless of the above, there are some open source projects that provide "nanny" support, but when you encounter a pit, can you continue to advance the project, and how to reasonably avoid the pit during the project cycle? Test the comprehensive ability of a development.
Naturally, this comprehensive ability does not only include code, but it takes time to develop and step on the pit to get it.
Yes, from my point of view, development is not just about writing code. Our competitiveness is not only about code. For example, the ability to implement business is the result of long-term experience, such as:
- What will happen from the initiation to the end of a work order;
- What needs to be considered for the flow of a shopping order from initiation to after-sales;
- What needs to be paid attention to when a reservation system is concurrent;
- What kind of technology stack does a live broadcast system need to support;
What pitfalls should these businesses face in specific scenarios? Why is this business written like this? Even if you know that such a design is unreasonable, how do you organize the code to avoid the burden of frequent modifications in the future.
After all, there are millions of good codes, and bad codes are ruthlessly modified many times under the high pressure of business.
After talking so much, I actually want to express: as ordinary people, technology will not become our barrier under normal circumstances, because many positions in the IT industry now turn brain-intensive into physical-intensive, and 996 and 007 require Physical strength requires a sleek mentality to gain a firm foothold. The young and energetic are teenagers, and industry experience allows us to better preserve our physical strength to face the "surging" of the workplace .
Of course, if the profession has been fishing in deep water for several years, then there is no fuck~
Therefore, I have always had a suggestion: When conditions permit, try to choose an industry, not to engage in education this year, do catering next year, and jump to the Internet of Things the next year .
The perennial “crossovers” may be just “big heads” everywhere. Networking in an industry is a resource. We may not be good at communication, but we always say that the xxx circle is small or our ability is not particularly outstanding, but we have been doing it for a long time. I know more people in the circle.
After the age of 35, 10 years of e-commerce industry experience may be a little more useful than 10 years of mobile development experience .
Of course, this belongs to standing and talking about back pain. Conditions allow it to mean that under the condition of not great economic pressure, no matter what the bullshit theory, survival is the first element.
At last
Returning to the theme, from the Jetpack proposed by Android in 2018, the changes in 2020 are actually not big, and there are more updates like ViewPager2, CameraX, Motionlayout, etc., and Android 10 and Android 11 have begun to focus on privacy and Scoped Storage partitions. Wait, this is probably also the performance of Android development towards maturity and stability.
So Android now has a very mature development system. The maturity also shows that the development dividends brought by this system have faded. The popular point is that there are fewer jobs to quit.
As a non-technical boss, I will choose some other things to try to break through, such as front-end, RN, Flutter and other technical fields to try.
Of course, everyone's ideas and choices may be different. Maybe my method is not suitable for you. I just want to express this: when you feel that you are in a "bottleneck" and anxious, or you can choose to toss in another direction. T-shaped talent, you know
In addition, a friendly reminder, don’t make a random plan for yourself. If you want to "more articles per week" or "how many books per month", you must complete it as much as possible, otherwise you will increase anxiety because you cannot complete the plan. It's enough.
Finally, most of the words here belong to the family, for reference only, and mainly sent out with feelings, I hope it can help you a little bit, so that you can continue to fish with peace of mind in the daily development!
Here I am going to share an Android learning PDF+architecture video+interview document+source notes , advanced architecture technology advanced mind map, Android development interview topic data, advanced advanced architecture data collected and organized by several big guys .
If you have a need, you can point it to receive
If you like this article, you might as well give me a thumbs-up, leave a message in the comment area or forward and support it~