facebook html5开发app 失败的原因，

Here’s why the Facebook iOS app is so bad (UIWebViews and no Nitro)

非常好的文字讲述了facebook 为何最后放弃了html5 转向native，但是这并不是代表h5不能承担app开发，而更是证明了h5开发和native会长期共存

It’s the week of the Facebook IPO, and a lot of talk in the Facebook roadshow is about its mobile strategy. Out of the 900 million monthly active users, 500 million use Facebook on mobile. Mobile is booming and will so the next few years as these numbers are showing, so rightfully so a lot of attention goes to mobile.

On the iPhone in 2008/9, before the iPad was out, the first version of the Facebook app was seen as one of the great examples how to build an iPhone app. It was developed by one person, Joe Hewitt, and parts of the app were open sourced as the Three20 project. When he left Facebook and stopped working on the iOS app, a new team took over which resulted in a complete rewrite for a universal app that also supported the iPad (November 2011). In spite of growing numbers, not a whole lot of users actually like the current iOS app. In the US iTunes store, the rating average is 2 stars, with out the 21,803 ratings, 11,839 1 star ratings (!). One star ratings are often a sign of frustration, and you can see that in the comments. For most of the apps an average of 2 stars is deadly, but we all use Facebook so yes we will all have to use its iOS app if you own an iPhone or iPad.

So what is wrong with the iOS app?

1. app is slow 
2. inconsistent information notification icons say there are new messages or responses, actual window does not show anything new.
3. app is slower than mobile web site while everybody is used to speedy apps, the Facebook mobile web site is faster than iOS app, and offers almost the same functionality.
4. tons of other bugs scrambled views, photo upload, text boxes disappear, no sharing.

What is the origin of these issues?

1. HTML and UIWebViews without Nitro JavaScript engine
I did some network sniffing (I like sniffing  ) and found out that the data that the iOS app downloads from facebook.com is a mixture of REST (XML format, no JSON) and HTML. The HTML is used for your personal timeline, and profile and groups timelines. See for yourself, go to https://m.facebook.com/home.php and see that it is the initial view of the iOS app. Also from the screenshot above, you can see something went wrong while downloading the html and images/stylesheets/JavaScript. To display HTML in an app, a developer uses a Safari component called UIWebView. Very convenient, but also dangerous. The HTML downloaded is pretty big (15kb), and contains links to images, stylesheets and JavaScript. For a starter, caching of unchanged content cannot be controlled by the developer. The FB app downloads the whole timeline HTML every time, and it is up to the UIWebView to determine whether it needs to download images, stylesheets etc. again. Second, performance of UIWebViews is less than in mobile Safari. This has a lot to do with the absence of the new Nitro JavaScript engine in UIWebViews, apparently for security reasons. I ran some tests on my iPhone 4 with iOS 5.1.1, theJavaScript benchmark Sunspider running in Mobile Safari was 3 x as fast as running in anative app with a UIWebView. Also, to communicate from the UIWebView to the native app, a JavaScript bridge is needed. This is tricky stuff, slow and not really thread safe.

2. Different calls for similar information that is not in sync 
For notifications, messages and friend requests regular REST calls are done, returning XML data. First check is to see what number of new notifications are there (https://api.facebook.com/restserver.php), then the actual content is retrieved in a separate call (https://api-read.facebook.com/restserver.php). As far as I can tell, the Facebook service calls return inconsistent information. When you check too fast what new notifications are awaiting you, you don’t get the new information.

Why would Facebook use HTML technology inside a native iOS app?

1. HTML is easier for displaying fluid content. Objective-C really sucks when it comes to fluid display. An image with text around it, buttons with varying text labels are really hard to create yourself in Objective-C as you have to calculate dimensions and positions of all elements yourself. In particular for a timeline HTML will be much easier.
2. Creates code that can be shared across different platforms. iOS, Android, BlackBerry, Windows Phone are all different technologies and a developer’s nightmare. Sharing some content/functionality in the form of HTML makes sense.
3. HTML is much more in line with Facebook’s continuous deployment process. FB developers are responsible for their own QA, and part of that is to push code out to a limited set of servers, see results and then push it out to more and do this each day if not more often. With Apple taking as least a week of review, rolling back a code change is a nightmare.
4. They can get away with it. Yes Facebook is not a bank, there are no other iOS FB apps out there and we will still use the service as it has a virtual monopoly on social networking with 900 million users now. We just have to suck it up.
5. Feature phones is where growth is. A very high percentage of iPhone and Android users already have the Facebook app installed. The next frontier is feature phones, in particular in non-western parts of the world. These new users will first encounter Facebook on their mobile, and it will not be a shining iPhone.

For a company like Facebook a slick and fast fully native iOS App like Path would be much better. Faster means better user experience which will lead to higher user engagement. And higher user engagement is key for better monetization through ads. I’m afraid it will not be soon :(. What do you think?

 

 

 

原文链接http://blog.mobtest.com/2012/05/heres-why-the-Facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/