This paper is accompanied by a video demonstrating the tool
in action. In this section we will briefly describe the demo
applications shown in the video, which will also serve as the
foundation for the performance evaluation in the next section. The
first demo application is one of the sample applications made by
Google to showcase some of the capabilities of the Android
platform called DivideAndConquer, [4]. It is chosen for this
paper primarily because the visual nature of a game allows the
viewer to clearly see the immediate effects of runtime class
reloading. The application consists of only 13 classes.
Clearly, an app which is this small does not have a huge
redeployment time, thus the direct savings gained by utilizing
class reloading with JRebel.Android will be relatively small. However,
from the enormous amount of user experience with JRebel for standard
Java, we know that developers change their coding habits when using
class reloading. Typically, developers will test out even small
changes much earlier simply because they are automatically
reflected in the running application automatically. The key is
that class reloading will keep developers in “the zone”,
which heavily improves productivity. In addition, the fact that
all of the application state is preserved adds to the benefits of
not being constantly interrupted by having to recreate
some specific runtime scenario before testing the changed
code.Given the small size of the Divide and Conquer app, a
second more realistic application has been picked for
showcasing in this paper, namely the open-source Google-developed
application named My Tracks, [5]. My Tracks is much larger
and contains just over 500 classes, and lots of resource files
and declarative resources in XML files. Fig. 4 shows a couple
of screenshots of the appIn this section we report on the
redeploy times of Android application development on the chosen
sample applications with and without JRebel.Android. The
redeploy time without JRebel.Android is measured from the time where
the developer presses the run button in the IDE, which triggers
reinstallation on the device. For these experiments a Google
Nexus 5 phone was used. The redeploy time with JRebel.Android
is the time taken from when the tool detects a class file change
(using OS file system notifications) until the change is
reflected on the device. The tool automatically writes this time to
system output during normal operation. Table 1. shows the
measured redeploy times. All numbers are simple averages based
on at least 10 samples. Numbers were very similar for each
sample, so improving the statistic validity of the measurements
had a low priority for this paper. Code Shoppy
https://codeshoppy.com/php-projects-titles-topics.html
As can be seen from Table 1 the size of the app is
somewhat proportional to the standard redeployment time. The
installation size reported by the Nexus 5 phone was 672KB and 11.95MB
respectively for the two sample apps. Having a turnaround time
of 3 seconds, does not sound like much, but recall that the
app is completely restarted, so all state is lost. For larger
apps like My Tracks (medium size), where the clean redeploy is 15
seconds, the redeploy time is much more felt as a pain for
developers. With a reload time of not much more than half a
second (for reloading 13 changed classes) as offered by JRebel.Android
it saves more than 95% of the dreadful redeploy
timentrospection results, and new members cannot be found
through reflection at all. InstaReloader has some support for
reloading resources, but from simple tests notable issues were
observed. Also, in contrast to JRebel.Android, InstaReloader
leaves generated artifacts inside the Android manifest file,
which will pollute production code.
https://codeshoppy.com/php-projects-titles-topics.html
Comments
Post a Comment