5 ms·

As a rule, performance of flagship Android phones lags iPhone by 2 years or so. Been that way as long as I can remember. Worse, floating point perf lags by abou

As a rule, performance of flagship Android phones lags iPhone by 2 years or so. Been that way as long as I can remember. Worse, floating point perf lags by about a factor of 3. I don’t know why Qualcomm and Samsung keep doing this to themselves. It’s not like they can’t design decent chips. They just choose not to. The situation is further exacerbated by Android being a disorganized, sloppily put together pile of excrement.

brokenmachine 9y ago
That's your opinion. I personally wouldn't touch an iphone with a ten-foot pole. I don't like Apple's business practices, and I don't like their hardware (no headphone socket/no SD card/smaller screen than I'd like). Android isn't perfect, but I find it to be much more usable and logical in the way it works. I have done some Android programming so maybe I just understand it better than most, but my partner and my mother also seem to be able to use it fine. I certainly wouldn't describe it as a "sloppily put together pile of excrement". I am able to work around Android's deficiencies, something I can't do when locked in the Apple jail. FWIW, when I think of a "sloppily put together pile of excrement", I think of itunes.
- throwaway84742 9y ago
  Try to use their camera2 api to see what I mean about sloppily put together. I’m with you on iTunes. Thankfully I haven’t had to use it in years.
  - brokenmachine 9y ago
    An enduser doesn't need to know about the camera2 api to take a photo. I was mistaken, I thought you were discussing usability for endusers, not about programming issues.
  - bitmapbrother 9y ago
    You mean the same camera2 API that's used by the Google Pixel 2 - the world's best smartphone camera?
    - throwaway84742 9y ago
      Let me assure you, this was possible in spite of, not thanks to this API. Words fail to describe how horrible and unusable it is.
      - londons_explore 9y ago
        When looking at the API, you have to take into account limitations the designers had. Specifically, the API is part of the android layer that Google writes and OEM's can customize. It must, however, support any underlying camera HAL and associated hardware. The software for that is typically written by SoC vendors, and therefore the camera2 API needs to work with existing HAL layers without modification. Camera API's also need to be performant. Specifically, converting the data from one form to another, compressing or decompressing it, adjusting colorspaces, rotating it, or copying it from one memory to another typically isn't possible to do as part of the abstraction. Simple things like rotating a 240fps video to be the right way up in real-time really aren't doable, which means those details have to be passed on to the application if the camera hardware is mounted the other way up. That means the API itself needs to get the application to handle those details if it wants to offer performance. All those possible hardware details which the API can't hide for performance reasons lead to a huge and complex API. If you want a simple API, you're free to build one on top (and some exist), but beware - performance will be atrocious on some hardware.
        throwaway84742 9y ago
        Excuses, excuses. Meanwhile iOS API for the same thing requires 1/10th the amount of code, is easy to use, and has great documentation.
        londons_explore 9y ago
        Except they can modify the hardware and HAL layers... Google cannot.
bitmapbrother 9y ago
Funny isn't it how an Android phone with an old Snapdragon 835 from last year can so easily beat an iPhone X. https://www.youtube.com/watch?v=uL99tRQR9W0 https://www.youtube.com/watch?v=uL99tRQR9W0 The "sloppily put together pile of excrement" iPhone X can't even keep apps in memory as it loses to an Android phone from last year. If a Note 8 can make the iPhone X look that bad just think what this year's S9 will do.
- londons_explore 9y ago
  Both apple and Google have people working on optimizing this type of speed test. You wouldn't believe how much pressure the Unity game engine Devs were put under to make loading fast and memory use low. A lot of work was put into letting textures be readonly, pageable and backed by flash when the app is in the background, which dramatically reduces the dirty set size of apps and lets you run many in the background at once. Therefore, I would suggest it's best to use other kinds of real world tests, like for example completing a specific set of tasks, or webpage loading tests, which aren't yet over optimized.

brokenmachine 9y ago

That's your opinion. I personally wouldn't touch an iphone with a ten-foot pole. I don't like Apple's business practices, and I don't like their hardware (no headphone socket/no SD card/smaller screen than I'd like). Android isn't perfect, but I find it to be much more usable and logical in the way it works. I have done some Android programming so maybe I just understand it better than most, but my partner and my mother also seem to be able to use it fine. I certainly wouldn't describe it as a "sloppily put together pile of excrement". I am able to work around Android's deficiencies, something I can't do when locked in the Apple jail. FWIW, when I think of a "sloppily put together pile of excrement", I think of itunes.

throwaway84742 9y ago
Try to use their camera2 api to see what I mean about sloppily put together. I’m with you on iTunes. Thankfully I haven’t had to use it in years.
- brokenmachine 9y ago
  An enduser doesn't need to know about the camera2 api to take a photo. I was mistaken, I thought you were discussing usability for endusers, not about programming issues.
- bitmapbrother 9y ago
  You mean the same camera2 API that's used by the Google Pixel 2 - the world's best smartphone camera?
  - throwaway84742 9y ago
    Let me assure you, this was possible in spite of, not thanks to this API. Words fail to describe how horrible and unusable it is.
    - londons_explore 9y ago
      When looking at the API, you have to take into account limitations the designers had. Specifically, the API is part of the android layer that Google writes and OEM's can customize. It must, however, support any underlying camera HAL and associated hardware. The software for that is typically written by SoC vendors, and therefore the camera2 API needs to work with existing HAL layers without modification. Camera API's also need to be performant. Specifically, converting the data from one form to another, compressing or decompressing it, adjusting colorspaces, rotating it, or copying it from one memory to another typically isn't possible to do as part of the abstraction. Simple things like rotating a 240fps video to be the right way up in real-time really aren't doable, which means those details have to be passed on to the application if the camera hardware is mounted the other way up. That means the API itself needs to get the application to handle those details if it wants to offer performance. All those possible hardware details which the API can't hide for performance reasons lead to a huge and complex API. If you want a simple API, you're free to build one on top (and some exist), but beware - performance will be atrocious on some hardware.
      - throwaway84742 9y ago
        Excuses, excuses. Meanwhile iOS API for the same thing requires 1/10th the amount of code, is easy to use, and has great documentation.
        londons_explore 9y ago
        Except they can modify the hardware and HAL layers... Google cannot.

bitmapbrother 9y ago

Funny isn't it how an Android phone with an old Snapdragon 835 from last year can so easily beat an iPhone X. https://www.youtube.com/watch?v=uL99tRQR9W0 https://www.youtube.com/watch?v=uL99tRQR9W0 The "sloppily put together pile of excrement" iPhone X can't even keep apps in memory as it loses to an Android phone from last year. If a Note 8 can make the iPhone X look that bad just think what this year's S9 will do.

londons_explore 9y ago
Both apple and Google have people working on optimizing this type of speed test. You wouldn't believe how much pressure the Unity game engine Devs were put under to make loading fast and memory use low. A lot of work was put into letting textures be readonly, pageable and backed by flash when the app is in the background, which dramatically reduces the dirty set size of apps and lets you run many in the background at once. Therefore, I would suggest it's best to use other kinds of real world tests, like for example completing a specific set of tasks, or webpage loading tests, which aren't yet over optimized.