Malicious Spit on Android (don't Look, poison)

CSDN Blog: Http://blog.csdn.net/niu_gao

I think the Android system has a very disgusting person's big failure. It was this big failure that caused the card of the Android system to stop.

This big failure is the design of the activity.

Android's design principle for activity is that it must be run-time independent.

You cannot create the activity directly and start it, and the system must help you do so. To start the activity, you must use a intent request system to help. So you want to declare each activity in the app in the manifest file. If you have more than one activity declared to be bootable and you specify Intent-filter, then each activity is likely to be the portal to your app.

Since each activity can be a portal, each activity must be functionally independent and self-fulfilling. In other words, the concept of the process is diluted, and if an activity is destroy, even if the app process does not exit and starts a new activity, it should be considered as the activity's app exiting.

CSDN Blog: Http://blog.csdn.net/niu_gao

However the ideal is too plump, the reality does not bird you. How many people can have such a Communist mind and energy to put their every activity in the imaging system of the phone texting such an app? Most of the activity is used internally, each is made very independent too laborious, especially in the app internal activity sharing data between more trouble, according to its principle should put the data into intent additional data, in order to Startactivityforresult () Starts the next activity and receives the data returned by the next activity in Onactivityresult (), but how much easier is it to make global static data?

Isn't that too much of a design? You can kill activity or processes unrelated to the foreground app, but how can you kill activity in the foreground app? Rather than letting the system murder it, let the programmer kill it himself. Besides, if the system memory doesn't keep up with the normal operation of an app, is the app too poorly designed?

There is also a more chaotic situation: The latest Android system to promote navigation bar (to learn from the Apple, save a key?) ), you have a return button in the navigation bar. But when you start B from activity A and then return a button on the nav bar of B to return a (dad named a B in the manifest file), actually a is not the original a, but it's re-created, is it too ridiculous? In this case a onactivityresult () is never executed! So be aware that the return button on the point navigation bar and the point device return key, the effect is different, different, different ... Say three times about the thing that tore the egg!

Also, the Android development documentation explicitly says that if the activity has a background thread open, it should be closed in OnDestroy. Well, generally an app is a multi-page navigation to complete the operation process, that is, open multi-threaded activity in the hidden and display between the switch to switch on and off switch multi-threaded?

Is there any way to solve the problem? Yes! A separate, self-fulfilling component that can take advantage of another function: service. The use of service to do background transactions, activity in the explicit will not affect the background tasks, but also do activity and service communication between, good trouble.

But there is always a solution better than none!

Not yet, as this design principle brings about a more chaotic activity lifecycle management problem! Look at this diagram, the life cycle of activity how horrible!

And here's the picture:

(for the life cycle of activity, see: http://blog.csdn.net/niu_gao/article/details/7101178)

CSDN Blog: Http://blog.csdn.net/niu_gao

Complex even, the more fucked up is the inconsistency! Originally we thought onstop () must correspond to OnStart (), who knew halfway to kill a Onrestart (). OnStart () is not running after the state, but also to Onresume () to calculate! OnCreate () is not actually corresponding to OnDestroy (), but corresponds to OnStop (), I x, can curse?

But the most ridiculous thing is, if you want to save the state of the controls on the activity, you need to do it in OnPause ()! Crossing said, not OnPause (), but Onsaveinstancestate (). Yes, it is actually onsaveinstancestate (), but Onsaveinstancestate () is immediately followed by OnPause (), so there is not much difference from timing to OnPause (). That's why the Android interface card is stuck! The bones of the belt, can not be solved! As long as the OnPause () call is generated, it will inevitably accompany the hard disk (memory) operation! That is, the small activity switch, will cause the hard disk operation! But in fact, in the process of running an app, 99 of this operation is not necessary, because the activity and Ben did not destroy! All the controls keep their state in memory! Why is the iOS interface smooth? Because there's no such fucking design in iOS. Viewcontroller in iOS is similar to activity, but does not require the need to maintain runtime independence.

Android now has a place to copy iOS than a ListView alternative: Recycleveiw, whose item's weight and mechanism are very similar to the iOS UITableView cell, why not just learn about the design of the activity to iOS?

There is also a design of the egg: when the screen rotates, the activity will be destroy again create. As you can see earlier, it is possible to know how much the cost of destroy and the create process is. This process of app process with Ben did not quit, for Mao I want to turn off the thread in the screen rotation process and then open? I'm going to turn off the network and re-connect? And what about iOS? Just by a callback method to give a notification, it does not turn off the view controller and rebuild. Of course, because rebuilding activity,android has the ability to be more bull B than iOS: horizontal and vertical screens can have completely different layout. In fact, iOS can also ah, as long as you implement a callback method to respond to the screen rotation, in which the code to adjust the layout of the line.

I think Android has been aware of this error, so the introduction of fragment this thing. Fragment Although there is a life cycle, but it will not be actively killed by the system, as long as its activity is not dead, it has been there, and in fact you can let it leave the activity is still alive, and you can also decide fragment life and death, if you want to save memory, You can take the initiative to kill fragment.

With fragment, your app can have only one activity, build multiple fragment, page switch is fragment switch between. This way, in addition to screen rotation, there are no destruction and rebuild problems in most cases. Don't you believe me? You can see the management fragment API, there is a way to add fragment to the back stack, the back stack and the back button on the navigation bar does not exactly fit to write an efficient wizard-type interface? So everyone later to use fragment less with activity,android launch fragment, is to let you do, but embarrassed to own the original design global negation, hit their face bar. (To learn more about fragment, see: http://blog.csdn.net/niu_gao/article/details/7163263)

These are personal prejudices, people outside the heavens beyond heavens, I hope to have a master to hit my face.

CSDN Blog: Http://blog.csdn.net/niu_gao

Finally, let's talk about optimizations for Android programs:

• First of all, according to the above: more use of fragment, less use of activity. In fact, this one is enough. Other optimizations are specific to the logic of their own application optimization, specific problem analysis.
• Second, with the latest APIs, new development packages will always bring some optimizations or provide new, more efficient components, such as Recycleview instead of ListView and GridView.
• Again, you can use C and C + + in C and C + +. In fact, this one I do not recommend, because from a code maintenance point of view, still can use Java in Java. But if you want to optimize to the limit, then use C and C + +(like the NDK and C + + and the poor basic students can join this group:*535807023) *.
• Finally, if you are not afraid of trouble, just handle the screen rotation yourself, roughly as follows:
  Add attributes to the activity element in your manifest file:

android:configChanges=“orientation|keyboardHidden”

然后在activity中响应回调方法：

publicvoidonConfigurationChanged

CSDN Blog: Http://blog.csdn.net/niu_gao

Hope in the new version, Andorid re-pick up the concept of the process, so that everyone can freely decide whether the activity into a run-time independent, further to iOS learning, the activity of pause to "into the background", the resume to "become the foreground", In addition to the most important create and destroy in the life cycle, the rest of the renaming, the removal of the removed. So it's good for us, anyway, it's great.

Malicious Spit on Android (don't Look, poison)