跳到內容
  • 版面
  • 最新
  • 標籤
  • 熱門
  • 使用者
  • 群組
  • 搜尋
  • Get Qt Extensions
  • Unsolved
Collapse
品牌標誌
  1. 首頁
  2. Qt Development
  3. Mobile and Embedded
  4. Qt Android 5.3 Application Size
Forum Updated to NodeBB v4.3 + New Features

Qt Android 5.3 Application Size

已排程 已置頂 已鎖定 已移動 Mobile and Embedded
23 貼文 6 Posters 15.6k 瀏覽 1 Watching
  • 從舊到新
  • 從新到舊
  • 最多點贊
回覆
  • 在新貼文中回覆
登入後回覆
此主題已被刪除。只有擁有主題管理權限的使用者可以查看。
  • GianlucaG 離線
    GianlucaG 離線
    Gianluca
    寫於 最後由 編輯
    #7

    If the size it's a problem for you, there is an alternative: use Ministro.
    Ministro is an android service that provides Qt libraries.
    In this case, your app will be very very small, and when someone install the app from google play automatically he/she will be asked to install also Ministro service.

    1 條回覆 最後回覆
    0
    • S 離線
      S 離線
      sonyericsson0819
      寫於 最後由 編輯
      #8

      Yeah,I also think the size is too large.My app was about 7~8 MB ,when I used Qt5.2.1,but now I use Qt5.3.0 to deploy the same application,its size is about 8~9 MB,become larger.And I also find that it has a "white screen" when the application starts or quit,which is never appear in Qt5.2.1 application.

      1 條回覆 最後回覆
      0
      • GianlucaG 離線
        GianlucaG 離線
        Gianluca
        寫於 最後由 編輯
        #9

        Just to continue the discussion about the size of an app: what's the problem if the app is something like 30Mb ? I really don't understand what bother you.
        I've never read a statistic telling that the users choose app depending on the dimension they occupy on their mobile phone. Typically the users doesn't care about the dimension of an app. And almost all mobile phone of 3-4 years ago have enough space to install hundreds of apps.

        Or I'm underestimating the size problem ??

        1 條回覆 最後回覆
        0
        • R 離線
          R 離線
          rschalch
          寫於 最後由 編輯
          #10

          More size, more memory, less chance of the app run fine when other software is on. I think we cannot undersetimate the size at least for now

          1 條回覆 最後回覆
          0
          • GianlucaG 離線
            GianlucaG 離線
            Gianluca
            寫於 最後由 編輯
            #11

            That's not true. (I think). Because the size is due to the Qt library that cannot be splitted at a very fine grained level... but that doesn't means that your app need to have all library symbols on memory (RAM) at the same time to run fine.

            If you did a very simple app that use only the 10% of exported symbols of the Qt libraries, that in memory (RAM) there will be only the 10% of the dimension totally occupied on the disk.

            So, If we want to discuss the problem of the size, we should really check how much is the effective needed RAM in order to run the app without affecting the performances.

            For Android I don't know how to check it, but for iOS Xcode display the RAM memory needed by the app at runtime.
            And for example, my app that on iOS is ~40Mb of .ipa, when it runs it occupies only ~5Mb of RAM.

            1 條回覆 最後回覆
            0
            • R 離線
              R 離線
              rschalch
              寫於 最後由 編輯
              #12

              Yeah, perhaps who made the tests of the latest Qt on an average android device can tell us how the app reacts in a situation when other apps are open. If the performance still goes well I think we can forgive the size app.

              1 條回覆 最後回覆
              0
              • GianlucaG 離線
                GianlucaG 離線
                Gianluca
                寫於 最後由 編輯
                #13

                My android devices as testbed are an LG L7 bought 4 years ago, and a 7'' inch tablet without brand imported from china one years ago and payed about 50€

                I didn't do performances checks because I don't know how to profile an android app regarding CPU and RAM usage.

                I'll came back after I did more tests and profiling.

                1 條回覆 最後回覆
                0
                • GianlucaG 離線
                  GianlucaG 離線
                  Gianluca
                  寫於 最後由 編輯
                  #14

                  Some news about memory usage of the Qt app on Android.
                  Following this guide:
                  https://developer.android.com/tools/debugging/debugging-memory.html
                  I checked some usage of my application.
                  Consider that is an application using Qt Quick (Layout, Controls), Qt Network, Qt Multimedia, Qt Svg and all modules on which these depends on.

                  The memory on disk of this APK is about 40Mb.

                  When the app runs, the maximum space seen on the heap is 2966K/3468K (active_used / totally_for_the_app )
                  And the private dirty memory on RAM (the very important for keeping the phone reactive) goes up and down around the 6800K / 2100K (Native / Dalvik ).

                  So, this definitely prove my assumption that the RAM needed is very different from the space needed on disk.

                  1 條回覆 最後回覆
                  0
                  • R 離線
                    R 離線
                    rschalch
                    寫於 最後由 編輯
                    #15

                    Yes, its reasonable. Thanks for the tests !

                    1 條回覆 最後回覆
                    0
                    • R 離線
                      R 離線
                      rjklindsay
                      寫於 最後由 編輯
                      #16

                      I'm sorry, but such HUGE executables are completely unacceptable.
                      Keep in mind the entire Win95 operating system required only 55Mb of hard-drive space, which was already big and bloated, compared to RiscOS (4Mb). I see some apps in the Google Play app store are only 24kb or smaller. Now Gianluca is trying to convince us that a Hello-world app of more than x1000 that size is acceptable? I think not! I certaintly won't be using Qt for my next Android project, unless they can SIGNIFICANTLY reduce the APK size.

                      1 條回覆 最後回覆
                      0
                      • R 離線
                        R 離線
                        rschalch
                        寫於 最後由 編輯
                        #17

                        I would say that for small apps we can go with pure Java, but man, developing in QtQuick is so much fun ... the main libraries may encapsulate all the things that we commonly dont use. but for a richer app, maybe the 32-33 mb can be acceptable

                        1 條回覆 最後回覆
                        0
                        • R 離線
                          R 離線
                          rjklindsay
                          寫於 最後由 編輯
                          #18

                          I'm no fan of Java, which is why I'm looking for alternatives.
                          I must admit, I really like QtQuick, but the APK size makes it a non-starter. On my Samsung SII, a simple QtQuick app takes between 5 and 20 seconds to start, whereas a ADT+NDK app starts up in under a second. Also, Google Play has an APK size limit of 50MB, and a 'richer' app could easily exceed that limit. To make things worse, many devices have a 30MB download cache limit, so even if you get your 32-33 MB app uploaded to Google play, many devices would not be able to download it. Btw. FireMonkey on Delphi/C++ Builder is another excelent RAD tool for developing Android apps, but unfortunately it also suffers from over-size APK's. So, for now I see no choice but to stick to Eclipse ADT+NDK.

                          1 條回覆 最後回覆
                          0
                          • R 離線
                            R 離線
                            rschalch
                            寫於 最後由 編輯
                            #19

                            Well, we still have the option of deploy the "small" app and have users to download Ministro from Google Play. None of this would be an ideal solution but answer me honestly: Whats better and more fun than QtQuick for development ? I think we can also believe in its future :)

                            1 條回覆 最後回覆
                            0
                            • H 離線
                              H 離線
                              hmbright
                              寫於 最後由 編輯
                              #20

                              i can kind of see both sides. i understand how this may be a problem for some. for example in the US on some phone providers on some contracts, 30 mb of mobile-network data can incur a significant cost. and it can be quite slow.

                              on the other hand, Podcasting has become extremely popular in the US, and an ordinary podcast mp3 can frequently be 30MB to 50MB. Videos of course are much much more. i have a feeling most people download these podcasts over wifi to their phone and listen later. this is relatively speedy and works well for many people.

                              1 條回覆 最後回覆
                              0
                              • H 離線
                                H 離線
                                hmbright
                                寫於 最後由 編輯
                                #21

                                i can kind of see both sides. i understand how this may be a problem for some. for example in the US on some phone providers on some contracts, 30 mb of mobile-network data can incur a significant cost. and it can be quite slow.

                                on the other hand, Podcasting has become extremely popular in the US, and an ordinary podcast mp3 can frequently be 30MB to 50MB. Videos of course are much much more. i have a feeling most people download these podcasts over wifi to their phone and listen later. this is relatively speedy and works well for many people.

                                1 條回覆 最後回覆
                                0
                                • R 離線
                                  R 離線
                                  rjklindsay
                                  寫於 最後由 編輯
                                  #22

                                  honestly: Whats better and more fun than QtQuick for development ?
                                  Delpih / C++Builder XE6!

                                  1 條回覆 最後回覆
                                  0
                                  • R 離線
                                    R 離線
                                    rjklindsay
                                    寫於 最後由 編輯
                                    #23

                                    honestly: Whats better and more fun than QtQuick for development ?
                                    Delpih / C++Builder XE6!

                                    1 條回覆 最後回覆
                                    0

                                    • 登入

                                    • Login or register to search.
                                    • 第一個貼文
                                      最後的貼文
                                    0
                                    • 版面
                                    • 最新
                                    • 標籤
                                    • 熱門
                                    • 使用者
                                    • 群組
                                    • 搜尋
                                    • Get Qt Extensions
                                    • Unsolved