Just finalizing a project for a client, will remove link once answered.
http://da.cronus.fweb.com.au/
On iOS and desktop the animations/scrolling are very smooth. As soon as it hits android things get very laggy (tested on nexus 7, Galaxy S4 and galaxy tab 3)
Anything i can do to speed things up?
first of all some images are pretty heavy for mobile devices
it should not affect the animations but still ...
codewise the only part that seems slow to me is
$('.column p').each(function(){
if($(this).html().length < 1){ $(this).remove() }
})
in custom.js line 665
so i guess if the animations are slow it must be a device / spec issue
but there is probably something to change with those line of code that could help your javascript.
For Sliding you can use Flexslider plugin. Plugin supports touch and it is responsive. I think some problem with sliding plugin only.
Switch from java script animations to CSS3 animations - they are hardware accelerated on most Android 2.3+ devices.
jQuery itself is OK on Android. I use it all the time. This could be a poorly coded slider plugin. However, you have some large images around 2mb and I think this could be optimized. I would do this first. You can also move the js files to the bottom and also compress and merge them. These are all optimization techniques that need to be done first and are not a waste of time. I'd also use responsive CSS on the images to display different sizes for device resolutions. Bootstrap has some solutions for the images sizes. After your page is optimized for mobile then you can re-evaluate if the slider is still slow or it was just large images.
I tried it on my Galaxy Note II and it works quite smooth. If you are trying to improve it in anyway, i would recommend swipejs.com for mobile and flexslider for the desktop version (although flexslider is completely working on mobile too, i just found swipe.js to be easier to setup)
Good luck and have fun! :D
Your question is very generic.So i would say, you need to minimize background processing as for as possible in scrolling(if doing some processing for scrolled data) or in animation or in any other activities.
As mobile devices have less resources.
Animation performance on android is not something you can just bolt-on with an IE jQuery plugin 'that makes it work in IE8' and expect it to work similar on android.
Remember that Android runs on a wide variety of devices, all with their own performance issues and some with even crappier versions of the android webkit variant than others. Expect huge differences between last-generation quad-core tablets/phones and low-budget devices.
My advice:
try a jquery plugin that automatically uses css3 animations instead of jquery looped where available (but no guarantees there)
try a jquery plugin that optimizes the jquery animations with the use of requestAnimationFrame (
http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/ )
As others have mentioned: You can't just throw 2mb images to a phone and expect them to animate smoothly. Optimize assets for the device you're serving them to (e.g. a max 800x600 pic for a phone)
If all that fails: Optimize manually, by enabling android browser debug settings and adding -webkit-transform 3d-transitions to the elements that need to animate so that the layer is rendered by the GPU.
You mentioned performance on android, but the first time that I loaded the site on Firefox it was pretty slow as well. After looking at your slide images, I found that the slide are way too big (~2mb), as other people have mentioned.
PNGs aren't the best choice unless you must have transparency, as they are bigger than JPEGs right off the bat. I would take the images and optimize them for the web using Ps. If you really wanted to be super-efficient, you could have another set of smaller images intended for android. Hope this helps you out. Happy programming!
Grey
If I were you I'd use css transitions. I've found that they work much better on mobile especially Android. I realize that in a desktop environment you'd have much broader support using a javascript transition but mobile is a different story.
You could hybridize....
http://jsfiddle.net/PHPVT/
$("#target").on("click", function () {
$(this).addClass("clicked");
})
use javascript events to fire css transitions :)
I use it all the time when I have to build for ie8 since it doesn't fire :hover states on anything other than anchor tags.
Related
I have a few projects with flash that i'd like to turn into apps for mobiles, I started reading adobe air and i've noticed that it uses back some things like inframe action script, something that I have not done since as2.
Is there a way to load scripts and classes like a normal flash file?
If I have a noncomplicated swf, is there a way to migrate it easily into adobe air for android and iOs?.
I've been struggling to find examples of adobe air projects, does anyone have a tip for this?
It is easy. I have converted 30 games to run on iOS and Android. The biggest problem was that they were in AS2 and had to be converted to AS3 first. If your uncomplicated swf projects are in AS3, and developed using Flash Pro, then just change the publishing output from swf for a web page to iOS pr Android. Android would be easier to start because you don't need to get an Apple developer account, create a certificate and provisioning file. With Android you can create a certificate right in Flash Pro. You test publish on your pc or mac first. When you are ready to test on a device you create an ipa (iOS) or .apk (Android).
Yes, there are a lot of screen sizes out there. But you know how you can create Flash in a web page so that it will resize with the page and keep its aspect ratio? Well its the same on mobile - it will resize to fit whatever mobile screen it displays on. Most likely your game is in landscape orientation. Just keep it that way and test it on whatever device you have (an iPad would be good because that aspect ratio or 1024 x 768). Actually, we kept the stage to 736 x 552 and that fit on any screen out there. On tall (wide) screens like the iPhone 5 & 6 you will have space on the sides, but so what.
Just give it a shot and you'll see how easy it is to write an app for both platforms at the same time. And you don't even have to own a Mac (you only need one to upload your completed app to the store, but you can rent time on one and log into it for 10 minutes to do that.)
There's no "how to" when porting a Flash project to Ios or Android. It's the same technology so it's compatible in theory. You can simply compile and publish and you'll get a Ios and Android app in most cases. Now there's 3 major problems that probably 100% of Flash projects will face when publishing for mobile and in probably 99% of cases those problems might imply recreating the whole thing from scratch.
First problem: Sizing and Density. So many phones/tablets sizes and density, chances are your Flash project doesn't have a single line of code dealing with that and as a result your app won't display correctly across any mobile devices. You'll have to put together a big piece of code to handle that and make sure it doesn't break anything in the original project. Good Luck with that.
Second Problem: Performance and memory management, I'm yet to see a Flash project that doesn't systematically waste CPU and memory constantly. That's no problem for a Flash project except when publishing for mobile: can we still waste CPU power? NO, can we still waste memory: NO. You'll have to go through your entire Flash project and optimize everything to not waste CPU and memory. Once again Good Luck with that.
Third Problem: assets. Did you use a bunch of MovieClip here and there? Well no more on mobile unless you want your app to lag and drain the battery down and make the user experience as bad as possible. All assets have to be optimized for mobile, the right asset, the right type, the right size or else ... lag and bad experience. Here again Good Luck with that.
And this is just a small run down of the problems you'll be facing. You will spend probably hundreds of hours trying to port that Flash project to mobile and at the end it will still be running bad anyway. Chances are you should just start over.
EDIT:
Simple Guidelines:
render mode: usually "gpu" (very efficient with bitmap) but "cpu" is also possible (you get more CPU power but less bitmap display efficiency) and also "direct" if you want to use Stage3D (more complicated).
Display: usually bitmap and only rarely vector. Don't oversize them and don't undersize them either. Reuse as much as possible (saves memory and battery)
Handling sizes and density: scaling your content is the easy way but not the less efficient one, as long as your bitmaps are of good quality you should be able to get a good resolution in most density and size. Because there's so many different sizes out there you'll decide if you want your content to fit any size or to display as much as possible while filling the side gaps. AIR/Flash has no built-in system for handling that so you'll have to create your own or to find something open source out there that can do that. Basically you have a content that is n x n and it needs to display on a mobile screen that is n x n, you calculate the scale factor and scale your content and center it.
perf, memory, battery: reuse object as much as possible. If there's a bitmap that you'll use often don't get rid of it just reuse it. If you reuse you don't need more CPU, don't need more memory and don't need more battery.
how to get perf: displaying something and running code, that's the 2 things that will slow down the app so optimize both and test often. Maybe reducing the quality of some bitmap will boost your perf. maybe optimizing your code in some places will get you a few more fps, etc. This is a per project try and test.
I'm using fullpage.js for an html5/css3/jquery based app for Android 4.2 tablet, that I generate with PhoneGap web service. On PC and emulators everything works smooth and fast, but on tablet itself scrolling between sections is very slow and choppy. Scrolling between slides is a bit better, though not smooth either. I have css3: true in fullpage.js options and I use very light-weight images and elements for the app. Let's say each section loads around 50kb per scroll. I have fixed background for all sections and it stays in place without lags, only loaded per-section content is getting choppy (it looks like it's loading in square patches).
When I open the same html files in tablet's Chrome browser, everything works smooth as well. So I believe it's Android's default WebView causing this choppiness and issues. Is there any way to make it work smooth with fullpage.js?
The link you just posted took 94 seconds to load on my PC using Chrome. And it had plenty of console errors.
Besides that, it is clearly a problem of performance with your site.
You are trying to create a HUGE website layout. With 30 sections and nothing less than 105 slides...
Do not expect it to work smooth on a mobile phone. Your layout in a 1280x1024 resolution is creating a layout of 28.170 pixels height and a few more thousand pixels width. And all of it has to be moved on every scroll.
You can probably make it easier for your browser if you implement some lazy load technique (or even an ajax one for the section/slide contents). This way you will still having the huge layout but it will be empty at least.
Check out this answer for that.
You can even take a look at the lazy load option fullpage.js provides.
Also, using the option scrollBar:true might improve the performance.
I have an application with a WebView, where there's a long list of posts that Autoloads via Ajax when the user approaches the bottom of the scrollable area, so I display the word "Loading ... " and an animated GIF beside it created via Ajax Loader site.
The problem is that this Gif sometimes appear as a still image in some devices with Androind 2.3.5/2.3.6, and in other devices its animation is extremely fast, and in other devices it's extremely slow.
E.g. Galaxy S Mini with OS: 2.3.6 (it appears as a still image).
Galaxy S I9003 with OS: 2.3.6 (it plays in a very very fast rate).
Galaxy S2 with OS: 4.0.3 (It plays very fast then suddenly becomes extremely slow but it's still animating).
Is there a standard frame rate or any work-around for this issue ?,
Here's the image That I'm using:
------> <--------
I know Facebook's app was using WebView with loader at the bottom of the feed but I don't know if it was animated gif or not.
I know that older versions of Android didn't support animated GIFs but I'm talking about new version
I had exactly the same problem and found no solutions! Animated GIF behavior seems really inconsistent across devices. That's the bad news. The good news is that I've made a work around, specifically for ajax loaders like yours.
You'll need to make separate image files for each frame of your GIF. It sounds horrible but it worked out ok for me - My 8 frame 8kb GIF turned into 8 png images totaling 11kb, and I got the bonus of 8bit transparency so I don't have to worry about the background color. It does mean the client has to make extra requests for the separate images though, so the fewer frames the better. I called the images 0.png, 1.png ... 7.png and put them in a folder to keep them neat.
Now the code! I'll explain it below.
HTML:
<img src="images/loader/0.png" id="headLoader" />
<div id="loaderKicker" style="visibility:hidden;"></div>
JavaScript (jQuery):
var loaderImg = $("#headLoader");
var loaderProg = 0;
setInterval(function() {
$("#loaderKicker").html(loaderProg);
loaderImg.attr("src", "images/loader/"+loaderProg+".png");
loaderProg = (loaderProg+1)%8;
}, 300);
First we have the img that we will animate. We use setInterval to change the image url to cycle through the frames. Really short intervals obviously put load on the device so we don't want to go nuts. I have a really cheap Android 2.2 device and 200ms+ intervals seem to work ok without wrecking app performance.
The loaderKicker div is there to make this work on older devices (like the ones we're targeting :) ). Android seems to ignore the calls when all we do is update an image url, so we get around this by updating the contents of a hidden div. I tried always updating with an "x" but it seems that the content has to actually be different. The slide number works well.
So that's it! It's a bit of a hack job but it works on everything I've tested on (Android 2.2, 2.3, 4.0, iOS6, Firefox, IE, Chrome) and if you're only doing it on one ajax loader that you'll then use everywhere it seems ok.
The other, completely separate, solution is to animate the image using HTML5 canvases but I couldn't tell you anything about support for them in old devices.
I have created one application which contains several buttons to home page clicking on one of that button my application redirects to some view which contains JQM form, with JQM calendar, text field, buttons and database etc....
My query is that when I test my application in android device on that time application works a little bit slow, even if I have not used any images,or any data which can contain more space. That's my first query and second one is that when I tested my application to android tablet on that time that form page is appearing for a while and suddenly it redirects back to home page automatically, while this same feature working well for android phone.
Why this strange issue?
If any one can guide me on it that it will be my pleasure
It's difficult to make assumptions regarding the slow performance and the redirection issue. Below you can find some aspects which in my opinion affect the performance of a mobile application which consists of HTML5, CSS3, JavaScript and should be taken into consideration on the analysis, the design and the development phase.
Implementation method based on the size
When developing small mobile applications the usage of a single HTML page using internal-AJAX page linking is recommended. For bigger mobile applications, a method of using different HTML pages with internal-AJAX linking is recommended. Try to create reusable page templates.
Page Transitions
As stated in the jQM 1.1.1 Docs, by default, all transitions except fade require 3D transform support. Devices that lack 3D support will fall back to a fade transition, regardless of the transition specified. jQM does this this to proactively exclude poorly-performing platforms like Android 2.x from advanced transitions and ensure they still have a smooth experience. Note that there are platforms such as Android 3.0 that technically support 3D transforms, but still have poor animation performance so this won't guarantee that every browser will be 100% flicker-free. Decide the transition type that you will use after considering the above.
Minify JS and CSS files
Each page should be as lightweight as possible. The minification’s goal is to preserve the operational qualities of the code while reducing its overall byte footprint. There are a lot of tools available on the WEB like the YUI Compressor, the Minify and many more. Furthermore there are tools like the JLint which is used to check whether JavaScript source code complies with coding rules. JLint is a code quality tool which checks for problems in the JavaScript code. The reported problems are not necessarily syntax errors but may be structural problems. Note that JLint does not prove that your code is correct. Consider it as a helping tool. Also there are tools for performing CSS optimization. The optimization helps you to get smaller CSS file sizes and better written code. You can find a lot of CSS optimizers available on the WEB such as CleanCSS and CSSTidy.
Components limits
The HTML pages is recommended to be limited to 25kb in order to gain the optimal caching advantage for the majority of the mobile web browsers. The caching limit varies depending on the OS version. For example Android 2.1 has a caching limit of approximately 2Mb.
HTML5 & CSS3
Try to create easy to read, to extend and reusable code. It is important to take full advantage of the using of HTML5 and CSS3. The HTML5 DocType declaration (<!DOCTYPE html>) should be the first thing in your HTML5 document before the html tag. It is an instruction to the web browser about what version of HTML the page is written in.
Use the W3C mobileOK Checker
The W3C mobileOK Checker is a free service by W3C that helps check the level of mobile friendliness of Web documents, and in particular assert whether a Web document is mobileOK. A Web Page is mobileOK when it passes all the tests. The tests are defined in the mobileOK Basic Tests 1.0 specification. To understand why checking a Web document for mobile-friendliness really matters, it is probably worth emphasizing a few points about the so-called mobile world. Compared to a regular desktop computer, a mobile device may be regarded as limited at first glance: smaller screen size, smaller processing powers, smaller amount of memory, no mouse, and so on. Compared to fixed data connections, mobile networks can be slow and often have a higher latency. Compared to a user sitting in front of his computer, the user on the go has limited time and is easily distracted. On top of these constraints, the mobile world is highly fragmented: many different devices, each of them defining a unique set of supported features.
Consider the appearance on different screen sizes
The screens density and the viewport size and web page’s scale should be taken into consideration when targeting different screen sizes. The viewport metadata can be used to define the viewport size where viewport is the container area in which the page is drawn. The viewport scale defines the zoom level which is applied to the web page. The target-densitydpi viewport property and CSS, JS techniques can be used to change the target screen density for the web page. There are plenty of articles on the WEB regarding the appearance on different screen sizes.
Identify the flows with potential delay
The PageSpeed Firefox/Chrome extension can be used to check the pages speed. When you profile a web page with Page Speed, it evaluates the page's conformance to a number of different rules. These rules are general front-end best practices you can apply at any stage of web development. The extension gives specific tips and suggestions on how to best implement the rules and incorporate them into the development process.
I hope this helps.
Let me explain our situation first,
We plan to develop a web application by using webview component which will work on tablet devices (target device specification: Android 3.0, Dual Core Processor (1GHz x 2), 10.1"WXGA, 1GB RAM).
In the application there will be 2D animations and we design a character. Like,
This character may wear different things, may change mimics
This character may walk with these artifacts (over a fix background image)
Application will use local resources.
My Questions are,
1) Which tools will be best to show these animations considering performance in webview and less resources size.
Canvas
SVG
Pure javascript by using fix images or animated gifs
Or something else? (Note: We do not want to use flash)
2) Which development environment(s), tool(s) do you suggest to construct these animations and related resources?
This is my first post in stackoverflow.
I hope this post and answers may help other developers also...
Best Regards,
Canvas would be better when we count in performance and SVG is something you can't render truly in all of the browsers, coz in previous versions of android SVG is not enabled by default you have to do a workaround on it to get it worked. Canvas is best tool as you can render it in most of the browsers and considering performance in webview. any how android 3.0 onwards ther's a support for SVG.