After installing application on a testing device, the size of app increases as I use it daily. But I would like to limit my application size, let's say up to 100mb. Means new data must overwrite old data when app size reaches to 100 mb, i.e. app size must not exceed 100mb anyways.
This is possible, altough it would be a little harder, as you'd have to do 2 things simultaneously:
Learn the exact app size after installation
Constantly monitor and control the app cache and storage
You may have noticed already, that the .apk or .aab (bundle) size is far less than the actual size of the app after it's installed on the device. But you can use org.reflection API and PackageManager to get it with a few lines of code at runtime:
PackageManager pm = getPackageManager();
Method getPackageSizeInfo = pm.getClass().getMethod("getPackageSizeInfo", String.class, IPackageStatsObserver.class);
getPackageSizeInfo.invoke(pm, "com.android.mms", new IPackageStatsObserver.Stub() {
#Override
public void onGetStatsCompleted(PackageStats pStats, boolean succeeded)
throws RemoteException {
Log.i(TAG, "Size of the installed app: " + pStats.codeSize);
}
});
This would be the code you'd want to run just after the installation, and save the value, as you'll use it later to calculate the size on the disk by combining it with other cache you have.
Secondly, each time you are going to persist something - either using SharedPreferences, a database (SQLite) or saving to a file, you'd have to count the bytes of the data saved, and calculate the sum of the saved data and the app size after installation.
Also, I'd suggest a best way to go for precision is be to save everything to a file, and avoid using databases and SharedPreferences, as it's much easier and consistent to get the exact file size. As your file size + the app size after installation > 100mb, you can tell the user, that he cannot save any more data, and has to free some space, etc.
I hope you got the idea..
Can we Limit our application size after installation?- NO
App size is one of the biggest factors that can affect your app’s install and uninstall metrics, so it’s important to regularly monitor and understand how you can reduce your app’s download and install sizes. Since the two sizes are related, here’s how they’re different from each other:
Download size: The size of your app that users download on Google
Play. When an app has a larger download size, it takes longer to
download.
Size on device (at install time): The amount of space required to
install your app. Since apps are compressed when they’re downloaded,
it can make install sizes larger than download sizes. When an app has
a larger install size, more space is required on a user’s device to
complete installation. After the app is opened, its size on disk
varies depending on app usage.
Related
I play modded Minecraft a fair bit. One downside to that is it takes a lot of time for all the mods to compile whenever I launch Minecraft. It can take around 15 minutes or so, which is too much time in my opinion. When a computer is running applications, everything it does is based off of inputs and data in RAM. I'm fairly certain that if one was to copy the RAM of their computer at a point in time and put that data back into RAM at another time, the computer would return to its former state. Though things may break down if the data in RAM doesn't actually agree with the data on the hard drive(like if windows explorer was open in the loaded RAM and showed files and folders which may not really be there on the hard drive).
I think it might be possible to copy the RAM data of an application(in my case a few GB of RAM after everything compiles and loads). I also think that if it were to be inserted back into the RAM at a later time, the application would appear already loaded without waiting for code to compile. How would I go about doing this? I think it's similar to save-state loading in emulators.
I'm fairly certain that if one was to copy the RAM of their computer at a point in time and put that data back into RAM at another time, the computer would return to its former state.
This is very perceptive of you; and this is precisely what happens when a computer "hibernates" [1]. You are also correct that unless the total state of RAM is saved and restored, or if the computer is allowed to operate in between the store and the restore, odd things are very likely to happen.
It is conceivable to store / restore the RAM state for a single application, but this would be a complex operation, and even with 25+ years of a career in IT, I have not heard of an application that can do this.
... Except for Phil Brubaker's comment, which mentions virtual machines. If you run Minecraft inside a virtual machine running on your physical machine, you can do just as Phil mentions : store and restore the running state of the VM at any point -- say, at the end of a Minecraft session. 'Snapshots' (again, as Phil mentions) are how this is done.
(VM applications might offer a 'suspend' feature, and while this might in some details be different from that VM application's 'snapshot' feature, the effect is the same, and it's just like hibernation for a physical machine : the running state (i.e., the contents of RAM and some details of what the CPU is doing at that exact moment) are saved to disk, and can be restored later to bring the VM back to exactly where it was at the point it was snapshot-ed / suspended.)
So I'd recommend a web search for "virtual machine applications for [fill in your operating system here]". VMWare and VirtualBox will be top hits; there will be others, depending on your operating system and such.
[1] Note that "sleeping" is different: in sleep, only some components are shut down, such as the hard drive, which is normally always spinning, whether or not it's actually reading/writing data. So sleep is a partial shutdown to save energy. Hibernation is a longer-term, very low power mode.
I am running a Java web app.
A user uploads a file (max 1 MB) and I would like to store that file until the user completes an entire process (which consists of multiple requests).
Is it ok to store the file as a byte array in the session until the user completes the entire process? Or is this expensive in terms of resources used?
The reason I am doing this is because I ultimately store the file on an external server (eg aws s3) but I only want to send it to that server if the whole process is completed.
Another option would be to just write the file to a temporary file on my server. However, this means I would need to remove the file in case the user exits the website. But it seems excessive for me to add code to the SessionDestroyed method in my SessionListener which removes the file if it’s just for this one particular case (ie: sessions are created throughout my entire application where I don’t need to check for temp files).
Thanks.
Maybe Yes, maybe No
Certainly it is reasonable to store such data in memory in a session if that fits your deployment constraints.
Remember that each user has their own session. So if all of your users have such a file in their session, then you must multiply to calculate the approximate impact on memory usage.
If you exceed the amount of memory available at runtime, there will be consequences. Your Servlet container may serialize less-used sessions to storage, which is a problem if you’ve not programmed all of your objects to support serialization. The JVM and OS may use a swap file to move contents out of real memory as part of the virtual memory system. That swapping may impact or even cripple performance.
You must consider your runtime deployment constraints, which you did not disclose. Are you running on a Raspberry Pi or inexpensive little cloud server with little memory available? Or will you run on an enterprise-class server with half a terabyte of RAM? Do you have 3 users, 300, or 30,000? You need to crunch the numbers and determine your needs, and maybe do some runtime profiling to see actual usage.
For example… I write web apps using the Vaadin Framework, a sophisticated package for creating desktop-style apps within a web browser. Being Servlet-based, Vaadin maintains a complete representation of each user’s entire work data on the server-side in the Servlet session. Multiplied by the number of users, and depending on the complexity of the app, this may require much memory. So I need to account for this and run my server on sufficient hardware with 64-bit Java tuned to run with a large amount of memory. Or take other approaches such load-balancing across multiple servers with sticky sessions.
Fortunately, RAM is quite cheap nowadays. And 64-bit hardware with large physical support for RAM modules, 64-bit operating systems, and 64-bit JVM implementations ( Azul, others ) are all readily available.
There are some nice I/O & Files methods in LibGDX but I can't find any way to check the available space remaining on a device (Android, iOS, PC).
I'm downloading some files from the web and I need to tell the user how much space he needs.
Is it possible somehow? I've checked each of the methods connected with a Files interface. (I don't mean memory, I mean the physical space)
Thanks vm!
This is a little related to my previous question Solaris: Mounting a file system on an application's handlers except this question is for a different purpose and is simpler as there is no open/close/lock it is just a fixed length block of bytes with read/write operations.
Is there anyway I can create a virtual slice, kinda like a RAM disk or a SVM slice.. but I want the reads and writes to go through my app.
I am planning to use ZFS to take multiple of these virtual slices/disks and make them into one larger one for distributed backup storage with snapshots. I really like the compression and stacking that ZFS offers. If necessary I can guarantee that there is only one instance of ZFS accessing these virtual disks at a time (to prevent cache conflicts and such). If the one instance goes down, we can make sure it won't start back up and then we can start another instance of that ZFS.
I am planning to have those disks in chunks of about 4GB or so,, then I can move around each chunk and decide where to store them (multiple times mirrored of course) and then have ZFS access the chunks and put them together in to larger chunks for actual use. Also ZFS would permit adding of these small chunks if necessary to increase the size of the larger chunk.
I am aware there would be extra latency / network traffic if we used my own app in Java, but this is just for backup storage. The production storage is entirely different configuration that does not relate.
Edit: We have a system that uses all the space available and basically when there is not enough space it will remove old snapshots and increase the gaps between old snapshots. The purpose of my proposal is to allow the unused space from production equipment to be put to use at no extra cost. At different times different units of our production equipment will have free space. Also the system I am describing should eliminate any single point of failure when attempting to access data. I am hoping to not have to buy two large units and keep them synchronized. I would prefer just to have two access points and then we can mix large/small units in any way we want and move data around seamlessly.
This is a cross post because this is more software related than sysadmin related The original question is here: https://serverfault.com/questions/212072. it may be a good idea for the original to be closed
One way would be to write a Solaris device driver, precisely a block device one emulating a real disk but that will communicate back to your application instead.
Start with reading the Device Driver Tutorial, then have a look at OpenSolaris source code for real drivers code.
Alternatively, you might investigate modifying Solaris iSCSI target to be the interface with your application. Again, looking at OpenSolaris COMSTAR will be a good start.
It seems that any fixed length file on any file system will do for a block device for use with ZFS. Not sure how reboots work, but I am sure we can get write some boot up commands to work that out.
Edit: The fixed length file would be on a network file system such as NFS.
I have created one java-swing application.
The application runs perfectly runs perfect on my pc.
But it doesn't run perfectly on client pc.
I had increase my Virtual Memory, earlier on my pc.
So my question is..
Is changing memory limit, effect or change application behavior?
Is there anything that change the behavior of java application? bcz same application runs perfectly on my pc and same application does not running perfectly on client pc?
and there is no problem in code, i have checked three times.
EDIT:
This is one screen shot of my application, if u see in the screen shot there is one table in which there are many images in it.
Now on my pc i don't see any double images in that table.
But on client pc, i am seeing double images in that table but if u click on one of the images then after clicking , the image which is showing earlier changed.
now then i take database and all the images from client pc and then i tried to run the same application on my pc with same data which is also their on client machine.
But now there is no double images coming in that table on my pc.
i "increase my virtual memory" means changing the heap size of virtual memory of jvm by adding...
java -Xmx512m
Obviously, if you app runs into OutOfMemoryError, then increasing the maximum heap size can fix it.
Faulty (on the hardware level) memory can cause Java programs to crash. This can be diagnosed by using a memtest tool
Sometimes, Swing gets at odds with hardware graphics acceleration, especially with onboard graphics adpaters that share main memory. This can be fixed either by reducing hardware acceleration in Windows, or getting new drivers.
It's possible more memory to help. To optimize anything for better performance/scaling/size, you first need to understand the problem.
Examine how much memory your application uses - if you're on windows you can start by looking at it with task explorer. If the amount of memory used is a significant portion of the amount of memory your pc has, then adding more memory may well speed things up. Other things can affect performance such as hard disk speed and number of cpu's. You could add more memory, but find it's the hard disk speed that is the problem.
What kind of things does your program do. Does it work with files or large data-sets?
You haven't said how it doesn't run perfectly on the client's pc. Is it slow, or does it crash?
Changes in the amount of memory and thus possibly in the amount of swapping necessary to provide memory to all applications can change the timing of your program.
If your program is susceptible to timing changes (i.e. if it is timing-dependent or only works in "best-case" timing), then those timing changes can influence the behaviour of your application.
Additionally restricted memory constraints can lead to more frequent garbage collection which also change the timing and can have an additional influence if you use any kinds of weak or soft references in your application.
You must check if the problem is with memory. Use ProcessManager or other similar program to check how your program use memory from OS point of view. You can use jconsole to check, how it looks from Java perspective.
Run your application with JDK and add to its invocation:
-Dcom.sun.management.jmxremote.port=9876 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
Then run jconsole and watch your app.