Essential knowledge for mobile terminal development

[[140777]]

There are more and more mobile device users, and the number of Android phones activated every day has exceeded 1.3 million, so our WebAPP for mobile terminals has also begun to follow up. This article mainly introduces the knowledge and experience related to the development and debugging of webapps, and gives several optional solutions.

1. Basic Concepts

(1) CSS pixels and device pixels

CSS pixels: An abstract unit used by browsers to draw content on web pages.

Device pixels: The smallest physical unit of the display screen. Each dp contains its own color and brightness.

How much space the equivalent CSS pixels occupy on the mobile phone screen is not fixed, it depends on many properties. After analysis and summary, we can come up with such a formula: 1 CSS pixels = (devicePixelRatio)^2 device pixels (^2 means square, as for what devicePixelRatio is, we will explain it later).

(2) PPI/DPI

PPI, sometimes called DPI, refers to the number of pixels per inch. The higher the value, the higher the density at which the display can display images. (Note: The pixels here refer to device pixels.) After figuring out what PPI means, we can easily understand how to calculate PPI. We need to first calculate the diagonal equivalent pixels of the mobile phone screen, and then divide it by the diagonal (the mobile phone screen size we usually refer to is the length of the diagonal of the mobile phone screen), and we can get PPI. For the accurate calculation, please refer to the figure below. What is more interesting is that the PPI of iPhone 4 calculated according to the formula is 330, which is a little higher than the 326 officially announced by Apple.

Similarly, taking HTC G7 as an example, with a resolution of 480*800 and a screen size of 3.7 inches, the PPI is 252.

(3) Density determines proportion

We calculate PPI in order to know which density range a mobile device belongs to, because different density ranges correspond to different default scaling ratios, which is a very important concept.

As can be seen from the above figure, mobile phones with a PPI between 120-160 are classified as low-density mobile phones, 160-240 are classified as medium-density, 240-320 are classified as high-density, and above 320 are classified as ultra-high-density (Apple gave it a high-end name - retina).

These densities correspond to a specific scaling value. For example, the iPhone 4 or 4s, which we are most familiar with, has a PPI of 326, which is an ultra-high density phone. When we write a page with a width of 320px and display it on an iPhone, you will find that it is full width. This is because the page is enlarged by two times by default, that is, 640px, and the width of the iPhone 4 or 4s is exactly 640px.

The high-density category is circled in the figure because it is the statistical data of Android phones. In the domestic Android phone market, high-density devices account for the vast majority of the market share. This is a very important point and also a key point that we should pay attention to when developing Android webapps.

(4) Use of viewport

Viewport has a total of 5 properties, as follows:

 <meta name= "viewport"  
 content="
 height = [pixel_value |device-height] ,
 width = [ pixel_value |device-width ] ,
 initial-scale = float_value, minimum-scale = float_value, maximum-scale = float_value,
 user-scalable =[yes | no] ,
 target-densitydpi = [ dpi_value | device-dpi | high-dpi | medium-dpi | low-dpi] " />

Among these properties, we focus on target-densitydpi, which can change the default scaling of the device. medium-dpi is the default value of target-densitydpi. If we explicitly define target-densitydpi=device-dpi, the device will render the page according to the real dpi. For example, a 320*480 picture is placed in an iPhone 4, and by default it fills the entire screen. However, if target-densitydpi=device-dpi is defined, the picture only occupies a quarter of the screen (half the square), because the resolution of the iPhone 4 is 640*960.

2. Solution

(1) Simple and crude

If we create a page according to the 320px wide design draft and do not make any settings, the page will automatically scale to the same width as the mobile phone screen by default (this is because medium-dpi is the default value of target-densitydpi and different densities correspond to different scaling ratios, all of which are done automatically by mobile devices). So this solution is simple, rough, and effective. But there is a fatal disadvantage. For high-density and ultra-high-density mobile devices, the page (especially the picture) will be distorted, and the higher the density, the more severe the distortion.

(2) Ultimate perfection

In this solution, we use target-densitydpi=device-dpi, so that the mobile device will render according to the actual number of pixels. In professional terms, 1 CSS pixels = 1 device pixels. For example, for a 640*960 iPhone, we can make a 640*960 page, and there will be no scroll bars when displayed on the iPhone. Of course, for other devices, pages of different sizes also need to be made, so this solution often uses media queries to make responsive pages. This solution can be perfectly presented at a specific resolution, but the more different resolutions to be compatible, the higher the cost, because separate code needs to be written for each resolution. Here is a simple example:

 <meta name= "viewport" content= "target- densitydpi =device-dpi, width=device-width " />

 #header {
 background:url (medium-density-image.png);
 }
 @media screen and (- webkit -device-pixel-ratio: 1.5 ) {
 /* CSS for high-density screens */  
 #header { background:url (high-density-image.png);}
 }
 @media screen and (- webkit -device-pixel-ratio: 0.75 ) {
 /* CSS for low-density screens */  
 #header { background:url (low-density-image.png);}
 }

(3) Reasonable compromise

In view of the fact that most Android devices are high-density and some are medium-density, we can adopt a compromise solution: we restore the 480px wide design draft, but make the page 320px wide (use background-size to reduce the image), and then let the page automatically scale in proportion. In this way, low-density phones have scroll bars (this type of phone is basically no longer used by anyone), medium-density phones will waste a little traffic, high-density phones will present perfectly, and ultra-high-density phones will be slightly distorted (there are very few ultra-high-density Android phones). The advantages of this solution are very obvious: only one set of design drafts and one set of code are required (here we only discuss the situation of Android phones).

#p#

3. Development and debugging

(1) Weinre remote real-time debugging

Web developers often use Firefox's firebug or Chrome's developer tools for Web debugging, including debugging for JavaScript, DOM elements, and CSS styles. However, when we expect to debug for mobile Web sites or applications, these tools are difficult to use.

Weinre is a debugging tool that helps us remotely debug web pages or applications running in mobile device browsers on the desktop. Weinre is the abbreviation of WEb INspector REmote, which is now an open source project of Apache and hosted on GitHub.

The following will introduce how to use it in daily work.

First, we need to download the weinre jar package. The official project can no longer find the jar file, but it can be found online. It is recommended to build an independent web server. After the jar is run, it is a local server, which is similar to a web server.

Then start it by running the dos command (please note that JDK has been installed on your computer). Run the command as follows, and change the path to your actual file location:

java -jar d:\tools\weinre-jar\weinre.jar –httpPort 8081 –boundHost -all- (httpPort is the specified service port, boundHost parameter indicates that IP access can be used, and all parameter means that all hosts are supported).

Visit localhost:8081. If you see the following page, it means weinre has been started successfully:

Enter the debug client user interface address. In this example, it is: http://localhost:8081/client/#anonymous, where #anonymous is the default debug id. If this weinre debug server is only used by you, then you can use the default debug id: anonymous. The launched weinre debug client ui is as follows:

Add the following script to the page that needs to be debugged: <script type=”text/javascript” src=”http://localhost:8081/target/target-script-min.js#anonymous”></script>. Please note that localhost should be replaced with the real IP address that the mobile phone can access. When the mobile phone accesses this page, the weinre client will detect the target device and then you can debug it.

Because it is not convenient to take screenshots on a mobile phone, I will use two browser windows to show the effect. In fact, the effect on the mobile phone is the same as the one on the right.

(2) AVD simulator debugging

Static pages cannot meet our needs. Many actual effects such as touch events, scroll events, keyboard input events, etc. need to be tested in a real environment. At this time, an emulator is needed. Just like when we tested IE6, the AVD emulator can be compared to a virtual machine on a PC. When we need to test a specific model, we can create a new AVD and conduct a series of tests. However, the premise of using AVD is that the Android development environment has been deployed, which requires JDK + Android SDK + Eclipse + ADT, which is still a bit cumbersome.

(3) Mobile phone packet capture and host configuration

On PC, we can configure the host very conveniently, but how to configure the host on a mobile phone is a problem.

Here we mainly use fiddler and remote proxy to realize the operation of mobile phone host configuration. The specific operations are as follows:

1. First, make sure the PC and mobile device are in the same LAN;
2. Open Fiddler on your PC and check "allow remote computers to connect" in the settings

1. Set up a proxy on your phone. The proxy IP is the IP address of your PC and the port is 8888 (this is the default port of fiddler). Usually you can set up a proxy directly on your phone. If not, you can download an app called ProxyDroid to set up a proxy.
2. At this point you will find that when you use your mobile phone to access the Internet, you are actually using fiddler on your PC. All request packets will be listed in fiddler. When used with willow, you can configure the host or even use reverse proxy.

Summarize

The above are some of the experiences and skills we have accumulated in actual development. I hope it can help you. If you have good methods or tools, please share them in the comments~~

Source: Tencent ISUX ( http://isux.tencent.com/mobile-development-essential-knowledge.html )