Android Development yesterday, today and tomorrow

Original link: The beginning of http://www.gracecode.com/posts/the-past-present-and-future-of-android-development.html chaos

It is hard to believe that such a system will have 80% of the market share! In my personal view, Android can do so successfully in the early days not because it was good enough, but the competitor did it better than it did in the same period.

Why? My dear reader, at that time there were questions everywhere:

Bad development tools (even IDE included)

Have you ever tried to fix a car with a shovel? Or, drive a girl with a 40-year-old Yugo that your grandfather used to ride? In that era Android developed and had only one "relative" official development tool: Eclipse.

Please believe me, Eclipse has a variety of problems that can even make you mad in 10 minutes! Eclipse's ADT plugin is simply "bug and Crash Fei Qi, restarting and turning off the common". Especially in the relatively complex development of the project, the acid is too cool to believe!

To a large extent, the light is the Eclipse development tool that scares a lot of starter developers into the arms of other development camps (for example, XCode).

Fragmentation of

The fragmentation of Android is so severe that it can be described with acne on the face of Mace, we first say software. Gingerbread (2.3.7) is a relatively old system version, compared to the same period of the IOS 4.x series, there are currently 百分之15-20 points (may have a slightly different share of the region).

As you may already know, the Android 4.0 (Ice Cream Sandwich) is a hugely innovative version of the new UI, new APIs, and new screen resolutions, all of which look wonderful. However, the slow user migration process has allowed us to face these excellent new system features while still needing to be compatible with the old system. So in order to be compatible with the new and old two systems, the project development more than a lot of compatible code, which will make the application everywhere is Bug and crash.

(This translator himself added, Spit groove I'm best at it.) In addition to software, the problem of fragmentation of hardware is even more serious. You don't even know what kind of hardware your app will run on, you need to get the user's location, sorry the device may not have GPS or even no base station location; you need to turn on the camera to scan the QR code, sorry the device may not have a webcam, even if there is a webcam but running memory is not enough, crashes! This time the user is to abandon their own hardware, or that your application has a problem ...

Hardware is the most headache is the screen resolution problem, Android development process in the resources (Resource) directory has a variety of directories (drawable-xxhdpi, drawable-xhdpi, drawable-mhdpi, etc ... ), you need to adjust your own resource files for different resolutions, and trust me that this piece is sometimes longer than the encoding time!

Slow simulator

When you're done with an app, you'll first test how it works on different Android versions and screen resolutions, so we've purchased no less than 20 Android devices for testing.

It sounds a little exaggerated? Well, thank God we have an Android simulator!

Then, you excitedly run to build an Android simulator and try to make it run, and you'll find that half an hour later you'll cry! Not to mention its slow speed, even when you start to think about your life during the commissioning process.

Since then you have no courage to open it, it is just a piece of the file system in your machine occupies a place in the file.

Ui

"How boring it is to design Android apps!" "If you compare IOS apps over the same period, then Android apps will be so dull and colorless." Compare the smooth animations, interactions, and details of IOS, and you'll feel that Android apps are all "stationary"!

When you're going to add a little bit of anger to Android, you'll find that old systems (such as gingerbread) imprison your ideas and thoughts, and even expectations.

New

We pushed the time down to 2013, and these terrible things finally changed.

At that time the problem was bad enough that even Google could not see it, even though Android 4.0 was released so far with a little bit of relief, but not enough to be able to solve the problem completely.

Until the release of Android 5.0 (LOLLIPOP).

Everyone is thinking-Google, device providers, developers. Everyone will ask the question, "when we have a relatively stable system, tens of millions of applications and corresponding users." So how do we make Android the Big Mac to simplify? How to make the process of development elegant and attract more people to join the ranks? 」

Android 5.0 (LOLLIPOP) has a huge change, and those very many features for the sake of space I can only list a few points that I personally consider important:

Android Studio

Android Studio has become very stable after the 1.0 release. I can't describe the great changes that this application can bring to us from a few words. If you would like to know more, you can see the original two articles I wrote (here and here).

This IDE is so good that the Eclipse ADT plugin has stopped the official maintenance, so it is highly recommended that if the students who developed Android migrated to the IDE.

Life is short and instant.

Gradle

Gradle is a fully automated build tool that has completely replaced Apache Ant as the main building system in Android Studio.

This new system will bring a whole new experience to building Android apps (sounds familiar?). ）。 Once you've set up your build configuration script, you won't have to worry about all the rest of it.

Translator Note: Gradle in the mainland to use the proposal or need to hang agent, sigh ...

Lollipop

Google said that Lollipop is the most transformative system version of all time (it says so every once), and I hope they are right.

At the same time, it is hoped that the current mainstream models can be upgraded to this version (translator: The original author feel somewhat optimistic).

Outside Lollipop-Material Design

As a matter of course, as one of the key points raised by Lollipop, there will naturally be a lot of ink to elaborate the new design concept of Material. I personally agree with one of Material design's philosophy that "everything is important (everything is important)".

For example, animation, for a long time, our view is that animation is only part of the effect, and Material Design argues that animation also has meaning, like the article fragment of the spacer.

We redesign and re-develop applications that conform to Material design, and the ultimate goal is to apply it not just as part of life, but as water and air as enough to make it fit everywhere in life, to make it ubiquitous.

This is so that in the future, even on different platforms, different applications look like style and experience are unified.

Within Lollipop-ART

For the external design elements provided by Material, our developers are most concerned about their internal changes. One of the new runtimes (runtime system) called ART is within it.

In fact, ART is not something new, it should be in Android 4.4 (Kitkat) for the first time. We re-introduced it because ART has completely replaced Dalvik as the system's default runtime (runtime System) in Lollipop.

ART has a lot of good features, and I'm just saying two of them in the space.

• Use the pre-compiled AOT (ahead-of-time). This means that in ART mode, the code is compiled directly into a machine instruction, and the program executes the machine instruction directly when it is run. This can result in faster execution times, less CPU loss, and longer battery time, and the other side is that the installation time may become longer.
• More methods are supported (Multidex support). Each dex byte file for Dalvik supports only 65,356 methods. This makes it impossible for our individual apps to support more than this number of methods. While this number looks very large, if we add to the project such as Google Play and other libraries, the number of methods we can use in the remainder will be greatly reduced or not enough. This problem is avoided by splitting the defragmentation file into different Dex files in ART and consolidating them into a single APK installation file.

For this piece, there are comments below, you can refer to

Note that ART still has the same 65k method limit. Multidex support applies to Dalvik as well.As an addition to the improvements you mentioned, I would add the unit testing support they just released with version 1.1.0 of AS. Hopefully it‘s a fresh start for better testing of Android apps out of the box. It also works great with Robolectric.

It's all over Android.

Now we can start writing apps for smart watches, TVs, and even cars. Imagine us sitting down and cooking a cup of hot coffee, looking around at least four or five devices will be running on Android: TVs, laptops, tablets, cameras, and even kitchen appliances.

Android began to occupy all devices with microprocessors, like water and air.

High-quality smartphones

Android's core platform is still its smartphone, but for a long time it has been plagued by the poor quality of the smartphones that run its system. Old anroid devices are running up against their contemporaries ' iPhone devices-and IOS is still much smoother. This "benefits from" the many low-end models offered by domestic manufacturers. (Translator Note: Original This is especially true for cheaper devices produced by a multitude of Chinese manufacturers. Huaqiang North is again black).

Thankfully, with the Moore Law of hardware devices, the current Android smartphone device provider is changing this situation gradually. It is likely that in the near future we will be able to get an Android smartphone that is powerful enough to perform at the same time.

For example, I personally like Motorola's smartphone (although it is now a subsidiary of Lenovo), and they produce Moto X, Moto G, Moto E and other models of mobile phones have a good price/performance ratio.

At the same time, a project called Ara can provide a PC-like modular hardware solutions and assembly solutions, in the future believe that the Android smart phone hardware platform this piece can be very optimistic development.

Next? Away from Java

After solving the system and development tool-level issues, we continue to gather Android-related issues elsewhere.

With all due respect, I think the core issue for Android will be Java, especially Java6 or Java7. Java is a very good language, but sometimes we might consider jumping out of the circle to think about it-we may need to update the language for Android.

In contrast to Apple, their Swift offers updates and more modern features. This makes it possible for IOS developers to develop apps more easily. Obviously, Java is more bloated than modern language in this respect.

It's time we need something a little bit fresher, and there's actually an alternative to Java, like the Groovy I was looking at. It's very close to Java in terms of syntax (it's actually Java), and we've got some prototypes for this development. Of course, there is no forgetting that it is Gradle's main implementation language-so why not use it directly for Android development?

At the same time, Scala (the use of numbers is growing rapidly) and Kotlin (here is an article that may make you passionate) is also a very good object to consider.

Better data management

Another issue that must be pointed out is the Data Management API (database management API). If you have comparisons, such as IOS (which should technically be Core data), they provide a number of very good abstract methods, graphical data management, objects, data observers (database change listeners), and so on. Compared to the API provided by Android, it's like a turtle-we're still writing SQL statements and expecting the right results.

Debugging SQL Statements is a very difficult task, the first thing to face is that we do not have an intuitive graphical interface to track these transactions. Although there are already some very good ORM libraries for us to use (such as Greendao, activeandroid, or sugarorm), in fact they still have their own problems.

I still expect to be able to manipulate databases like IOS, such as a data watcher (database change listeners), to help with similar tools. What we can find today is similar to third-party libraries such as Dbflow, and at least for now they can reduce and relieve me a lot of work.

China's situation (translator Plus)

Obviously, the domestic Android development environment is much colder than abroad. In addition to the problems mentioned above, there are a variety of localization issues due to policies and characteristics.

Missing Google Component Pack

Or it's completely impossible to use the services Google offers. We just push the service, Google is officially providing push service, but for various reasons, domestic developers are basically not used. This makes it possible for families to implement push programs themselves, resulting in a vicious cycle that reduces the quality of the application.

Unreasonable optimization

Domestic Android users have the "clean memory, kill process" habit, so a lot of normal running Service will be nameless kill, and developers in order to avoid being killed and frequently start the background Service, vicious circle.

At the same time, the firmware manufacturers to do optimization can not be law, randomly change the bottom of the system. For example, if a firmware changes the TextView and so on causes the application to display "strange" situation to appear.

Design aspects of IOS

Needless to say, Material Design even comes out for some time, but there are few signs of follow-up. Even some vendors offer Android versions of apps that are almost as interactive as they are visually and iOS versions.

I personally am pessimistic that this situation will continue for a long time.

Low-end models raging

As the original author said, domestic and especially Huaqiang North produced a large number of low-end Shanzhai machine further shattered the Android system experience. Imagine the apps developed by Android developers that need to face a few years ago, which is unthinkable on the IOS platform, and this creates a huge waste of resources and a decline in application quality.

Summarize

So where is the way to Android development? This problem may not have a standard answer until the end of this article. I believe that the ability to provide a good Android experience is often a small development team, and their innovative thinking, trial-and-error ability, and responsiveness will be stronger and faster than those of big-company teams.

And the Android system itself after several major versions of the evolution of the route is also gradually clear, I believe that in addition to the current field of smart phones, other platforms will gradually have to exert force.

This, can be seen.

Android Development yesterday, today and tomorrow