I think it is a base problem. I think for example about my old nokia 8310, in which you pressed buttons quickly and the response was immediate, yeah, I know it has no OS and not even the capabilities we have at the android, but it was what should be a phone. We must remember that the term smartphone is phone and smart, but primarly phone.
So I think that the design should have been raised differently, not as regards the manner in which applications are handled, if not in the way they handled the phone functions, and I do not talk about there shouldn't be cuts in a conversation, I speak also of the interfaces that the user must navigate to get to make a call ( and write text messages, etc) Then will come the applications, but I think it's a must to solve the user experience we had with old cell phones and unfortunately we lost. I think the system should be designed from a standpoint of real-time system. Giving specific quarks to specific and real time functions. pd. Unfortunately my phone has the filtered version of Eris, I hope in the htc version this problem would be issued. On 7 abr, 17:49, Sean Hodges <[email protected]> wrote: > What I think is that there are lot of little issues, not one big one. > > I'm also suggesting that the problem has very little to do with the > Java specific aspects of Android, and more to do with a composite of > problems. I base a lot of that from my experience working on other > software projects; the underlying problem is usually numerous, very > specific and hidden behind a curtain of assumptions... > > What are your thoughts debuti? You asked the question originally, do > you think there is one big spanner stuck in the works? Or a collection > of issues that could be ironed out through optimisation efforts and > accurate bug reporting? > > Also, could you let us know if your HTC Hero is still running the old > 1.5 build of Android? > > On Wed, Apr 7, 2010 at 4:33 PM, debuti <[email protected]> wrote: > > Dont you think that the big issue here is a base problem?: > > > We are talking about a real time system (in most functions) and the > > current architecture dont behave accordingly. Appart from java. > > > On 7 abr, 17:25, Sean Hodges <[email protected]> wrote: > >> Hey Tim, > > >> On Wed, Apr 7, 2010 at 2:51 PM, Tim <[email protected]> wrote: > >> > The programs are written in Java, compiled to a bytecode that is > >> > primarily used to represent Java source, and executed on a virtual > >> > machine that is primarily intended to execute these Java programs. > > >> Primarily used to represent a Java program in an instruction set > >> designed for efficient execution by a VM, not to represent Java > >> source. I was pointing out that the Java language is not interpreted > >> in the VM, is that what you are disagreeing with? > > >> > Only a pedant would say 'Android is not Java', not that that even > >> > makes sense - Android is the OS not the VM/language. > > >> Sorry, did I do something to you to deserve the name calling? Thanks > >> for pointing out the terminology slip, I did not mean to insinuate > >> that. > > >> > Google it (and remember Dalvik is currently JIT-less). > >> > There's some debate about whether JIT'ed Java is as fast as C, but in > >> > most cases it isn't (good microbenchmark website: > >> >http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=jav... > >> > ) > > >> It's funny, only today I was talking to a colleague about how people > >> often use the Shootout tests and Google Trends to make their point > >> about language performance. Please read the caveats on the Shootout > >> test suite, particularly the comparison > >> section:http://shootout.alioth.debian.org/flawed-benchmarks.php#comparison. > >> As > >> a rule of thumb, you shouldn't use the shootout suite to generalise on > >> performance differences. > > >> All the same, I do agree that on average, C and it's derivatives > >> out-perform Java (particularly without JIT) on a good number of > >> benchmarks. What I don't want to do is get pulled into a low-level > >> benchmarking argument (perhaps it's too late?) as we are talking about > >> significant responsiveness issues on the UI, not evaluating a > >> controlled Fibonacci test between the 2 platforms. > > >> > Either way, Dalvik doesn't have a JIT compiler so it is *much* slower > >> > than native code. Additionally it uses a 'stop the world' garbage > >> > collector which periodically freezes the UI for around 0.1-0.2 > >> > seconds. That causes little hiccups. > > >> The "stop the world" garbage collection is an interesting point to > >> make. I've heard it before, and at the time I saw a response from > >> Dianne Hackborn that stated that the GC of one app does not affect the > >> functioning of another in normal handset operation. However, right now > >> I can't find that email, so I won't argue the point :) > > >> It would be interesting to see any bugs logged for this particular GC > >> issue. I do know that when I execute a background Service that > >> deliberately triggers the GC regularly, that service responds slowly > >> but my Home app continues to function properly. It is not a scientific > >> test, but I think it makes the "stop the world" scenario more subtle > >> than you suggest. > > >> > So the following are reasons that contribute to Android being much > >> > less responsive than the iPhone, in order of how much I'd guess they > >> > affect things: > > >> > 1. Interpreted code rather than compiled. > >> > 2. Stop-the-world garbage collector. > >> > 3. Lack of hardware OpenGL accelleration for the UI (afaik, maybe this > >> > has changed in the latest versions?) > >> > 4. Background apps. > >> > 5. Maybe the UI thread isn't given high enough priority? > > >> Some of those have question marks against them, so perhaps you should > >> say "the following are the reasons I think contribute to Android being > >> much less responsive than the iPhone". I won't argue any of them as > >> potential factors (most significantly, your first point does not > >> mention "Java code", which makes it valid), but I would say that there > >> is a lot more going on than your list above. I personally think my > >> list is a bit more concise, but then I did write it :) > > >> > By the way, I think the whole "You have to make sure you don't > >> > allocate too many objects, e.g. strings in loops" kind of cancels out > >> > the "Java is great, you don't need to worry about memory management!" > > >> Couldn't agree with you more, and of course every good programmer > >> (Java or otherwise) knows this. The problem is there are a lot of bad > >> programmers out there, and they propagate the myth. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Android Discuss" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/android-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
