A heaven, a hell.

One: Development environment

Xcode of iOS is rubbish in rubbish, especially the support for Swift now. When I used it before, the code crashed every three times. Xcode must crash several times as many times as Android IDE, and it's really stuck. I feel that dragging up and down is not 60 frames.

Eclipse before Android was also rubbish, and later Intelijia/Android Studio was much better. There are too many codes, so it will be much better if I simply allocate 3G memory to him (my computer is 16G 13 inch rmbp). However, since Android was completely cut to Gralde, I feel that Gradle compilation is really slow, especially when multiple modules depend on it. It is a nightmare when the method that needs multidex exceeds 6k5, because incremental compilation is not supported after opening multidex. In this respect, iOS is much better. IOS uses cocopod to manage dependencies, and the compilation speed of changing a few lines of code is really faster than Gradle.

However, iOS can use AppCode, but this thing can't keep up with the release speed of Xcode, such as iOS9 and Xcode7, but writing AppCode is too old, and various grammatical errors can get a new development version, but the development version's support for new functions of iOS is definitely incomplete.

Second, develop languages.

IOS OC grammar is weird and tedious, but it's a good habit This thing calls C/C++ much better than Java used by Android. Later, Swift improved too much, which is not mature at present, mainly because Xcode is too rubbish, but now more and more iOS App are written in Swift. The Android version of Java died at 1.7. It is impossible to access Lambda of 1.8, although there are third-party libraries to do so. Kotlin of Jetbrain just started supporting Android, and doesn't even have 1.0. If you want to write Android in Kotlin, you have to wait at least 2 or 3 years.

Three: page navigation and saving the scene

IOS uses ViewController, Android uses Activity, VC's push==Android's startActivity, and VC's present==DialogFragment.show

No matter which system has the problem of insufficient memory, when the application is cut to the background, Android natively supports serializing and saving the scene, so that the app can be recovered after recycling (of course, you can not do it, for example, a version of Baidu map is like this, and it is overloaded every time it is cut out). Fragments are so complicated that iOS doesn't support them by default, and developers need to write very complicated code themselves. So you can see that basically no iOS App can be restored to the scene after being destroyed in the background. Generally, iOS apps with complex overloaded pages need to use ViewController to embed each other, which is called ViewController container. On Android, it is an active embedded fragment embedded sub-fragment.

Because there is no need to save data between VCS, just assign a value to an attribute of VC object directly. Androd must pass through Intent, and the data must support serialization. Of course, if you don't want to save the scene, just like iOS. In fact, I don't know which is better, because some people in iOS complain that the practice of iOS makes the two VCS couples too strong.

Four: App memory

After the iOS App starts, almost 1/2 of the total system memory is available, but there is a big gap between Android and Android, ranging from 32mb to 195mb+(2G of total memory), which is related to the total memory of the whole mobile phone. I don't know what the stack size of Android phones that have never used 3G or 4G memory is? This makes the memory of Android more prone to problems. Anyway, there is a problem that the code is not well written and the memory is leaked because of strong reference.

Five: UI, compatibility adaptation

IOS goes from the earliest manual frame, which is automatically resized to adapt to ip4 ip5, to the later AutoLayout, and then to the later Size class. But the automatic layout of StoryBoard is very, very difficult to use. A slightly complicated interface and a bunch of constraints on the left are impossible to change. In contrast, now let me vomit, my eyes hurt. So many people use third-party code AutoLayout library, such as Masonry, but I still feel verbose when using it. In order to adapt, iOS9 added UIStackView, which is actually the LinearLayout of Android. Another problem with AutoLayout is cards, so basically no one will use AutoLayout in cells of UITableView, and all of them are manual frame layout.

During the development of iOS, there have been many arguments, such as code drawing layout (either manual framework or various third-party layout libraries) or full storyboard /Xib, both of which are disgusting. Code drawing, VC is layout and business, the latter is not for people to use. StobyBoard/Xib is unreadable at all, which is a disaster for version management. And I personally doubt that Xcode can open a complicated storyboard and keep it from crashing.

Android generally uses XML to draw layout and code to do business, which is much better. XML is very easy to read and write. ListView writes a cell much faster than UITableView. IOS needs you to calculate your own height. Of course, you don't have to. As I said above, if you are not afraid of cards, the trouble with Android compatibility is Rom compatibility, especially for domestic manufacturers. Because there are too many changes to the frame layer, it is easy to step on the pit.

For the pit of system Api and system version update, my impression is that both iOS and Android will not be lacking and cannot escape. I honestly accept my fate and find a solution.

Six: multithreading

GCD operation of iOS and Java's Executor multithreading framework. As far as client development is concerned, I don't think there is any trouble or difficulty in both, and both can meet the demand. Of course, maybe I'm too shallow.

Seven: storage

Although iOS has CoreData, no one uses it. Everyone likes SQLite. Androd officially has no ORM plan. To be honest, SQLite, a third-party ORM, I feel guilty about several folders that iOS has assigned to the App anyway. If you write in a folder that you shouldn't write, such as a folder that will be backed up by iCloud, it will be rejected by the AppStore. But Android is very casual, and the whole SD card can be read and written. A certain version of Android forbids writing a second storage space (mostly SD card), but I remember changing it back later.

Eight: Animation

RunLoop for iOS is Handler/Looper/MessageQueue for Android. IOS has multiple modes of RunLoop, which can suppress other UI messages when scrolling, much like MessageQueue. IdleHandler on Android Because iOS shares code with OS X***, it is split-screen display and event handling (mobile phone touch screen, computer is mouse and keyboard), so there are CALayer and UIView. Because Android has no historical burden, it is handled by View itself. IOS animation can be operated directly with CALayer, while Android generally operates View with Animator. However, due to the compatibility of versions, many people still use 2.x animation to do Android animation, which is much more scum. One advantage of Animator is that it can change attributes at will over time. I remember the same thing about Facebook's Pop for iOS, otherwise you'll have to use it yourself.

CADisplayLink package.

TimingFunction is responsible for the speed in the animation process on iOS, and Android is the path corresponding to the interpolator Bezier curve UIBezier.

The view controller cutscene uiviewcontroller transition corresponds to the ActivityTransition of Android5, but it can't keep up with the general Android phone version. . . . Few people use ActivityTransition. Androd doesn't have the UIKit dynamic library of iOS, so he can only write some special effects himself.

Nine: On the shelf.

Let me take the domestic situation as an example. If you have a new application, you need a month to prepare to put it on the AppStore. Uncle Apple reviews your app once a week. If there is one failure, please wait another week. Comments will only give you screenshots and explanations. It can be corrected, and then there will be new problems next week, so it will take about a month to go back and forth four times.

There is no Google Play in China, so going to Xiaomi Store, pea pods and App Store for 4 days is much easier than Apple's, but there are many channels, which is more annoying. Generally, it is necessary to change the Gradle script to package packages from different channels to determine how much the corresponding application market has really distributed, all of which are related to money.

Ten: I feel that writing iOS is fucked by Apple and writing Android is fucked by mobile phone manufacturers.