0

I'm in development of an Android library module.

My library : https://github.com/sangeethnandakumar/TestTube

Rather than re-inventing the wheel, I'm depended on some of the other libraries to make my work done. After including 6 libraries inside my library namespace, My library reached around 1.8 MB.

My library depends only on specific features of other libraries but the complete library is importing and massed up right now.

Is there a way to reduce my library size even after including all of 6? My library is already optimized.

Sangeeth Nandakumar
  • 1,362
  • 1
  • 12
  • 23
  • In case the library you are using is packaged (not sources) - you cannot. In case there are source codes and the library is under some public licenses (MIT or so) and you can reuse this library license in your own - you can remove and compile parts of the code that you are interested in. – Oleg Novosad May 26 '17 at 13:50
  • "After including 6 libraries inside my library namespace" -- what exactly do you mean by this? Are you referring to the seven `compile` dependencies in your `testtube/build.gradle` file? – CommonsWare May 26 '17 at 13:52
  • Yes. I'm referring to Gradle compile dependency on testtube/build.gradle – Sangeeth Nandakumar May 26 '17 at 13:54

1 Answers1

4

After including 6 libraries inside my library namespace, My library reached around 1.8 MB.

Your library is not 1.8 MB. It is possible that your library and its 8 dependencies combined (with transitive dependencies) is 1.8 MB. After all, one of those 8 dependencies is appcompat-v7, and that's over 1 MB on its own, the last time I looked.

My library is already optimized.

No, it is not. You are depending on both Volley and OkHttp. These do the same thing. Get rid of one. Since you are also using Picasso, I recommend getting rid of Volley.

Is there a way to reduce my library size even after including all of 6?

Get rid of dependencies that you do not need (e.g., Volley).

If consumers of your library might not need all of the functionality of your library, split your library into pieces. For example, if some consumers of your library might want your networking code but not your UI code, you might create testtube-core and testtube-ui or something. testtube-core would jettison things that are pure UI (e.g., appcompat-v7), so for consumers that only need testtube-core functionality, they get a smaller library. testtube-ui would depend upon testtube-core, so consumers using testtube-ui would get all the dependencies, and your testtube-ui code can call testtube-core code to do what needs to be done.

Beyond that, you will have to rely on minification at the app level (e.g., ProGuard) to get rid of things that are unnecessary. Bear in mind that app developers might use your library and need things from your dependencies themselves. appcompat-v7 is a great example of this: just because you might need only a slice of appcompat-v7 does not mean that the app only needs that same slice.

This is why the comment advising you to clone the code and get rid of pieces is not very wise. At best, that might work for obscure libraries that app developers using your library might not need (e.g., whatever gun0912.ted:tedpermission is). But creating your own hacked copy of appcompat-v7 or gson or something will make the size issue worse, if the app also is using those libraries for other purposes.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Great answer CommonsWare. You explained everything at a glance. Since I'm intended to use my library on legacy Android, appcompat v7 can't be ignore. Comming to Volley and OkHttp, you are right and I will check it out . Also Picasso and Volley are different, I can't make server calls with Picasso but Volley can. Now I'm planned to split my library into a group of intermediate libraries. Anyway #You solved me #Upvoted – Sangeeth Nandakumar May 26 '17 at 15:29
  • @Kannan: "I can't make server calls with Picasso" -- sure you can. Here is [a sample app](https://github.com/commonsguy/cw-omnibus/tree/master/HTTP/Picasso) from [my book](https://commonsware.com/Android) that shows using Picasso to download the avatar images associated with people asking recent questions here in Stack Overflow on the `android` tag. – CommonsWare May 26 '17 at 15:41
  • Reviewed your sample app. I know its possible to download images from URL's provided to Picasso, But what about Http GET/POST? That is why I'm integrated Volley. I felt Volley is far better than okHttp even others are against this strand. – Sangeeth Nandakumar May 26 '17 at 15:59
  • I wan't my library to make Android tasks simpler as much as possible. I need to run my library for image downloads, http get/post calls, ftp uploads/downloads/fetches and almost anything. That's why everything massed over. Thus how can I terminate Volley & Picasso? I'm confused – Sangeeth Nandakumar May 26 '17 at 16:01
  • @Kannan: "But what about Http GET/POST? That is why I'm integrated Volley. I felt Volley is far better than okHttp even others are against this strand." -- I disagree. But, regardless, you do not need *both* Volley *and* OkHttp. If you want to use Volley, that is your decision, but then get rid of OkHttp. "That's why everything massed over" -- then quit complaining about the size. If you want to do everything, you have to have code that does everything, and that will be big. Personally, I prefer lots of small, tightly-focused libraries to large ones like the one you appear to be creating. – CommonsWare May 26 '17 at 16:05
  • You are on the point friend. So, I've decided to split my library to small segments. Also while I've done a tree analysis of transitive dependencys on a paper, I found most other libraries makes use of okHttp, not Volley. Now there is no way to keep my statement to make things smaller by keeping Volley. Fragmenting my library is my next goal. Anyway I'm satisfied on your comments, Thank you – Sangeeth Nandakumar May 26 '17 at 16:23
  • Creating a legacy version with appcompat v7 and a higher version without appcompat v7 is also in my considerations for those devoloping on different build target SDK's. Am I doing any foolish thing? – Sangeeth Nandakumar May 26 '17 at 16:27
  • @Kannan: I suggest that you start simple and continue from there. Few libraries get thousands of developers using them. Focus on what you need the library to do first, and slowly expand from there. So, if your app needs `appcompat-v7`, focus on `appcompat-v7` support now, and add in direct `Theme.Material` support at some future time. – CommonsWare May 26 '17 at 16:30
  • Latest Gradle does the magic at user end. Here it is : https://stackoverflow.com/questions/33112527/how-do-i-remove-unused-resources-from-third-party-libraries-i-ve-included-on-and – Sangeeth Nandakumar May 30 '17 at 05:50