This is a side note, but most members of the Android team at Google used to have 256 GB of RAM on their computers to compile Android (the entire build). When we used Android Studio, it was blazing fast so most devs that didn't work with users were not aware there was a problem.
I'm on the Android team and no, we don't. The current spec workstations are 128GB RAM, 1TB SSD, and 2x Xeon E5-2690 v4. But there's still a lot of the older 64GB & 96GB workstations in use as well.
The low clock speed of the Xeons (plus NUMA) means that for most things the machine isn't actually that fast, though, unless you can put the all the cores to use.
I don't think that really refutes the point, the median public user of Android Studio is probably closer to 16GB of ram right? With a nontrivial percentage of people with 8GB? So you're still talking about an order of magnitude more ram than those people.
Median 16GB? No way from my experience with dev agencies - most are on 8GB, some on 16GB, some on 4GB. I think I've only seen one Android dev with 32GB, ever.
I wasn't on the Android development team but rather I was in management, but my colleague was and that's the information I got when I tried using his workstation (he specifically works on Android framework). I actually never checked myself so that's my mistake, so I apologize if I am
spreading misinformation.
Funny you mention these stats, I work on Solvent IDE (codesolvent.com), I purposefully avoided beefing up my dev laptop to keep me honest...my dev box has crappy performance so that when I run the software on a more capable machine (like a medium ec2 instance) I get a nice performance boost :)
Always better to be more conservative to get a better sense of end user experience.
Not sure where you get this from, I'm not in an Android team, but from what I can see the top offered workstation one can get at Google has 64 GB of RAM.
I would assume that there was a special policy in place for people working on teams with a requirement for that amount of RAM.
I interned on Chrome in 2013, and at the time all Chrome engineers got a computer with an SSD (which I was told wasn't standard at the time), since they had to build Chrome on their desktops (whereas most other engineers could use Google's distributed build system).
64 seems a bit low, that's what I need for my hobbyist work. Granted, it doesn't take 64GiB of directly-allocated RAM to link Chrome (anymore), but there's almost no amount of page cache that would not be worthwhile if you have the whole AOSP on a box.
It runs very well on my 16GB RAM. I find a lot of the speed is in internet and hard drive speed. It opens up a full project in 3 seconds with a SSD, assuming there aren't too many dependencies.
I was also forced to buy an SSD to make my life easier, but lets be honest, SSDs are still quite expensive on price per GB on first world countries, let alone the rest of the globe.
Same regarding RAM, I know of companies that a standard developer machine is 8 GB, while everyone else gets 4 GB.
Getting something like 16 GB is unthinkable unless that is a business related change request.
So basically making the life miserable for those developers.
Mostly in context of text editing/auto completion hints. With e.g. intellij there's enough choppiness/delay in typing and completion to really put me off.
Have you tried the new versions with Zero Latency Typing? As the name implies, they managed to basically eliminate all latency on typing, even beating apps like notepad++ and emacs on latency. It's switched on by default in the current release.
Pretty primitive compared to what IntelliJ actually does, which for Java (and typed JS, Scala, Kotlin, etc) is full source code indexing and understanding of the type hierarchy.
That means "Find Usages", "Jump to Implementors/Overriders", "Show Substypes", etc all work correctly. When you ask for code completion, it's far above what IntelliSense does. IntelliJ will actually understand all of the variables and types that are reachable in scope, as well as those that are reachable by calling methods or accessing fields on those types two or three levels down. This is not the same as just examining what's reachable via 'this' or what's to the left of the '.' character.
The autocompletions are also ranked and sorted properly most of the time. Think of it as the difference between a shitty search engine and one that shows the most probable autocompletions first. Even Eclipse IMHO is pretty bad at this, and will often try to suggest meaningless classes somewhere on my classpath that I'm obviously not going to use, including internal sun.* implementations.
IntelliJ's refactoring and code analysis is also far above what XCode and VSC do. I've been using IntelliJ since the first version, and to me XCode and VSC aren't much of a step above Emacs as an IDE.
Syntax Highlighting, VCS integration, Debugger, and Jump to Symbol Definition are table stakes that even basic text editors have.
Erm, VSCode does all of that for Rust via RLS and the Language Server Protocol[1]. Heck, VSCode does even better than Android Studio because the pick common words in the source file as part of their auto completion. Things like comments, untyped parameters(ints, etc) all work much better in VSCode.
I'll agree that for Java VSCode isn't up to par yet but for many other languages it's easily at an equal level.
This is a matter of opinion, but language-specific navigation, searching, and refactoring is where I'd draw the line between an editor an an IDE. VS Code may not be there yet, but they're improving quickly and I think it's only a matter of time.
Better search ranking seems like a feature that could easily be added (though it has to be done for each language).
I'm happy to see competition in this space. The end user might not see it, but IntelliJ internals are pretty horrible from a plugin developer's point of view and haven't improved in many years. Moving language smarts to editor-independent servers (with VS Code's Language Server Protocol) seems like the right architectural move.
While I agree that IJ's internals are spaghetti, the VS LSP isn't quite the same, or at least, it appears to me, it does not offer the richness of IJ.
Consider that IntelliJ can syntax color and autocomplete multiple language grammars at once, e.g.
String aJavaString = "<someHtml onFoo='someJs.style=\"color: red\"; var regex = new Regex(\"someRegex\");'">
Does VS's language server protocol handle the ability to deal with nested language grammars each with nested contexts?
My issue is false negatives: IntelliJ usually just "works", especially with Java, it's near perfection and almost never gives a wrong completion. I've never encountered another IDE whose code understanding was as complete. Even a 2-3% false completion rate is super annoying.
Plus, the refactoring, structural search, and callstack analysis stuff is beyond reproach. Can VS tell me all possible reaching expressions to a given method? I've used that before to figure out what kinds of subtypes or nullability a given parameter has, but it requires global code understanding.
I feel like the kind of functionality that grok style code indexing provides is just the baseline, and what's important is what's built on top of it. VSC has a long way to go to reach IJ in that regard.
While agree that IntelliJ is pretty great the Android Studio implementation of it is nowhere near perfect. I've had false lints, incorrect flags and a whole class of issues where intellisense goes wrong.
Except, Gradle 4.1 with kotlin scripts (unless android studio overwrites your gradle version AGAIN) works fine nowadays.
But Android Studio actually managed to break builds on non-US locales because they used String.format using the system locale (which means %02.f renders with a ,)
Isn't this true of mostly any dev environment? You'll run into one or more of those every once in a while. Colleagues running XCode for iOS development think it and Swift are a piece of crap too most of the time (though the latest rewrite for iOS 11 apparently was a big improvement).
I've ran this version for going on 3 months now and pretty happy. I've run into some issues with Kotlin builds and preprocessors (can't see the build errors in the Gradle console, have to run a command line build with --debug flag) and every once in a while the emulator and IDE stop talking with each other (ADB needs a reset every so often).
C# + Visual Studio, the build will just work. The fact that editing the MSBuild XML is not really necessary for 90% of developers helps with this a lot.
You're probably right for modern/default use cases, but I've seen C++ for Windows Mobile fail terribly too (Android Studio supports NDK/Native C++ code also).
Installation failed with message Failed to install all .
That's enough for today
OK, just one more:
Error while uploading slice_4.apk : java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String)
After my experience with Android Studio I started to enjoy using Eclipse again.
The migration experience was even worse for those of us using the NDK.
Three reboots for the build system, no migration path until CLion was developed, debugging features only available to Java code,...
Although they have made major improvements, I always ask myself if they had spent all that money improving the Eclipse based IDE, how much better the overall experience would be.
Kotlin to rescue! Shameless plug https://hackernoon.com/in-pursuit-of-better-jvm-futures-kotl... I have seen/followed Kotlin since it's early days and I was so sure it's going to be next big thing for Android. After failure of Scala we had no other options :P
React native! Sublime to edit text (mostly the React app, but you can modify Android/ios if you want). I have the node CLI compiling code in one terminal, and then pointing all that to a Genymotion android emulator. Pretty smooth! Not having to compile the whole android app that only serves as a container to the JS is a godsend!
Yes, Android Studio is needed for running Flutter apps on Android but not for iOS. (You don't normally need to launch Android Studio, just have it installed on your machine.)
Similarly, if you want to run on iOS you need a Mac with xCode installed.
(It's rather weird to me that you need to install entire other IDE's as developer dependencies to build mobile apps, but that seems to be how it is.)
> It's rather weird to me that you need to install entire other IDE's as developer dependencies to build mobile apps, but that seems to be how it is.
I don't remember the details, but a couple years ago there was a way to install just the Xcode build tools without installing the entire IDE. I'm sure there's a similar process for the Android SDK. (Though, of course, none of that is officially supported, so you're on your own for the most part.)
Edit: Turns out Google provides downloads for just the SDK without Android Studio[1], so it looks like the separation is unofficial only for Xcode.
Your app is structured the same as a native one (Activities, Receivers, Services, Layouts, etc) and the XML for your layouts is identical, but you get to work in C# and don’t have to deal with Gradle etc.
What downsides does it have compared to a more traditional environment? I'm a C# developer so Xamarin sounds really tempting, it's just that I don't want to break my head on "simple" stuff I could easily avoid with a traditional environment
You still have to learn the underlying story platform and API, that’s not abstracted. Also choosing between Xamarin Forms and Xamarin Native for the UI (not compatible between them). Obscure errors sometimes.
But from my (little) experience on it, getting to an app running and start working on it is way mire easy than with the Java approach. Give it a try :)
This is for C++ code, which is kind of a special case. Android Studio now has C++ support but I tried it and wasn't impressed. Among other problems, the build process seems to be extremely slow.
In the early years of Android Studio, I generally preferred IntelliJ. I have since converted our application and main library (SQLCipher for Android) to use Gradle. I have Instant Run disabled, but otherwise I haven't run into many issues with Android Studio. We still coordinate our library build with a Makefile.
(On very lean teams that don't have the resources to build bespoke UI for every platform, even with Xamarin or React Native, and the web platform is a good compromise for the simple data collection apps we are building.)
Same here. Using Cordova with Atom or Sublime, and building/signing/deploying on the device via the CLI.
We need to deploy to desktop/mobile/chromebook and we don't have the budget to develop native UI for each one.
The be honest the only problematic platform has been iOS and its crappy UIWebView / WkWebView, and Windows but only because we are using Squirrel for the installs.
It has given me a few headaches. On Mac, Squirrel has worked flawlessly.
The biggest headache for my users is that the app is not added to the start menu, and the .exe is buried in some deep bizarre folder. Maybe there is a way to solve this, but I haven't been able to find it. There is an option to add a shortcut to the desktop, but if the user deletes it then the exe is lost forever.
I've had other bizarre problems for a few users and the only solution was to reinstall the app from scratch. Tech support is not very happy about that.
Maybe it all stems from my Windows ignorance but Electron-builder, one of the most important projects for packaging Electron apps, is moving away from Electron to NSIS. The problem is that AFAIK NSIS doesn't work with Electron updater.
I'm seriously considering moving away from Electron and replacing it with a UWP JS app and distribute it via the Windows Store.
VSCode dropped Squirrel on Windows ages ago for most of those same reason.
My only reason to support an Electron app on Windows is a need to import ancient Access MDB files. I've been meaning to explore deeper the possibility of using the desktop bridge for my Access reader component and call it from the Cordova UWP JS app. It's on my TODO list to explore, but I think just having a single UWP app (with a desktop component that lights up as available) would be the best distribution plan on Windows.
Man, that sucks. I just read through the discussion on that and can see where the pain points are in using Squirrel.Windows [0]. Hopefully they eventually deal with that. I don't use Windows much, so outside of making sure Squirrel.Windows is working correctly, I don't have much of an opinion on whether or not it provides a good UX to end-users (and it sounds like it doesn't, unfortunately).
Is this effective? I've never used vim, but Android Studio is great as an IDE. It has lots of autocomplete for tedious things like layouts, the shortcuts open up files as needed, and it highlights more effective ways to do things. This is extra useful for Kotlin.
in typical Google being evil fashion, using their central authority on Android they now discontinued android sdk and made the sdk a piece of android studio. for no reason other than forcing everyone to beta test their "version 3" (ha) studio. so much so that you now have to download the whole studio, and pick the sdk from within it. there are still some ways to find the sdk directly, but they are going away.
They said they will support it officially, which means they are in conversations with JetBrains to make it stable in Android Studio. They didn't implement a thing in the language, not even the plugins for android studio.
A lot of developers were already using kotlin before google announced anything.
Kotlin was the worst thing that happened to Android, I mean no disrespect but it seems that JetBrains and its team are really trying very hard to shove Kotlin down people's throat, the sad thing is that despite knowing the fact that it doesn't offer any performance improvements over Java, it is being paraded as the next big thing by overtly excited enthusiasts.
As a user of Android and a developer I want something that enhances the user experience of the apps I use and I create, I want the apps to feel and behave as smooth as iOS, the team at Google should focus on that and not on fragmenting the already fragmented community, right now they are solving a problem that doesn't exist.
I wonder if I would ever see 120/240 FPS apps in the future or if I could offload UI work and animations to a different core because you know your 7 cores are sitting idle and you can do nothing about it.
As as developer I am totally happy that it increases my productivity. You know, you don't have to use it? It is not shoved down your throat. It is a supported offer.
For what it's worth Android has used a separate thread for rendering since API 21. When you implement onDraw, it's really recording the commands and then sending them to the render thread for actual execution.
It doesn't fragment the community as you can call kotlin code from java and vice versa. Seamlessly.
Kotlin is great in that it brings Java 8 features to Java 6(lambda expressions, functional programming, etc.) and more. It's a boon to productivity and makes programming in the Java ecosystem fun again.
There is a sometimes increase in compiling speed but it's very marginal and the method counts increase with the transpiling but it's not noticable until the app get's on the larger side.
Yes, this was a major focus for the new Android Gradle Plugin. Unfortunately, this did mean breaking their Gradle DSL (part of reason for the new 3.0 version). Here's a talk discussing the changes:
Hmm; I have been running extremely large projects on AS with a good but not out of this world machine.
Compilation times are too slow for my taste (ie even clean should take less than 5 seconds ideally), but the IDE itself is pretty smooth.
Again, the trick is to monitor its memory usage.
It is a pity that it's up to the user to configure this, but for large projects I had to allocate more memory to AS and it makes it go from unusable to lag free.
No, no, your English is fine, it's AS that's the problem. :-) I assumed that it was probably a typo of some sort, but I would truly have believed either usage. Though AS has gotten better about not trashing memory.
That said, I agree that with a properly provisioned machine, AS does well. And it's a vast improvement over its predecessor.
Yes, the new Gradle plugin reworks how dependecies are handled (significantly improving compile times for larger modular apps) and has quite a few improvements in configuration and resource processing performance. Instant run has apparently been rewritten as well.
Unfortunately those changes do mean a few breaking changes for build.gradle files.
If most of my build.gradle files need to be tweaked in order to work with AS 3.0, then I might as well just rewrite them in Kotlin -- after all, they're only 30 lines long. That way, I can use Kotlin as my programming language for Android and my build scripting language.
Only played with it a bit so far but it seems to me that the call and flame charts are now missing any timing information. Unless I've overlooked it you can't actually see how long a function takes to execute - defeats the purpose of instrumented profiling surely!
Instrumented trace capture modifies the execution profile too much for timing information to be useful, and then sampling profiling which doesn't modify the execution profile doesn't have timing by its nature.
So if you were using the timing data previously you were basically just looking at random numbers that would send you on wild chases into things that weren't real. The new one fixes that by not showing bogus data :)
Yes, instrumentation adds overhead. The absolute numbers cannot be used to determine peak performance but that's never the intention when profiling code.
Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.
Furthermore with something like the call chart in AS3 you are often looking for outliers that you can't see when looking at an aggregated view of the profile. A function that has an average of 1000us might be running alternately at 500us and 1500us and you want to see that. It may indicate an unknown performance bottleneck, maybe a call to OpenGL is causing a GPU sync for some reason. It's rare that the instrumentation overhead would dominate major effects like that. Having a number available is important for this as you may be comparing invocations/looking at different parts of the graph at different zoom levels etc. Having a number available is the only solution.
Furthermore, where do you think the instrumented profiler is getting numbers from in the aggregated views? Answer: exactly the same place that the callchart gets it's numbers from. In essence you are saying all instrumented profilers are inaccurate and reporting bogus numbers, demonstrably untrue.
> Instrumentation rarely modifies the execution profile to the point that the numbers are 'worthless' or 'random'. My rule of thumb is that self times near the leaves of the callgraph are more accurate than self times further up the graph but having some indication of timing is important.
I was only talking about the instrumentation system on Android, not the one anywhere else. It forced ART to fall back to interpreted mode, so no JIT at all, which massively balloons the cost of certain things like single-line getters or JNI calls. It was actually useless as a performance tool of any kind, which is why the recommendation for years has been to ignore the numbers it produced. It's great at answering questions about what a given function ends up doing, but that's it.
The new profiler is much nicer. I'm a fan of the network monitor, it has a timeline of your requests, shows your JSON payload bodies, and previews images. I was mainly using Facebook's Stetho bridge for this, if Studio adds a good Sqlite inspector I'll happily kill that dependency.
Between the introduction of Instant Run and Genymotion going to a paid business model, I'd say the Emulator has improved exponentially. I tend to alternate between using the Emulator and using a device depending on what I'm working on.
Yes, I've found it to be much faster than it used to be and they've added a lot of settings to simulate different environments. They also recently added quick boot in the preview (https://developer.android.com/studio/preview/emulator.html) to improve the boot times.
yes. just open port 5555 and then connect via tcp on your dev box (which in my case, is another virtual box vm running ubuntu so i can wipe everything down every time a new version of android studio arrives --you DO NOT want to upgrade)
I found a fault when using a webview and rendering em's - it (as well as Chrome in debug mode for touch devices) didn't show the 8x scaling issue you get with a real device, which was annoying.
I wonder how JetBrains shared the license for their IDE with Android the license. As far as I know IDEA community edition is open-source, but I'm wondering if they license allows what Android did with it.
Alternatively, and more likely, Google has a bespoke licence for it. They’re cooperating enough with JetBrains on this that they’re likely to have some agreements in place anyhow
I only use it for a webview app so I'm not that much affected but I'm sad that the flat UI with those grey icons that are in Jetbrains' IDEs are now in Android Studio too.
I'd just like to apt install android-sdk and pass some .java file to a compiler, just like with any other language... In the past you could still just grab the sdk without an entire operating system's worth of GUIs, but they've removed that download option now. I'm down to using my own local copy whenever I use a different computer, together with a few shell scripts that I wrote to do the compiling for me, but that won't last forever with new sdk versions.
I'm glad to see Kotlin making its proper debut. Android has been crying out for something a little more expressive and less verbose than Java, and Kotlin fits the bill perfectly.
Kotlin is super nice. As a former C# dev who went into Android, I was really dissatisfied with Java, and Kotlin was my rescue. I had to write some C# recently, and I have to admit Kotlin does feel nicer. (Admittedly it is still lacking some good stuff in comparison, eg. _yield return_).
