The difference between ios test and web test

The difference between ios test and web test:

I. Language

As a client-oriented program, the front-end and the terminal have the same characteristics: they need to rely on the running environment of the user's machine, so there is basically no choice in the development language. Unlike the background, iOS can only use object-c, and the front end can only use javascript. Of course, iOS can also use RubyMotion, and the front end can also use GWT/CoffieScript, but it is not the mainstream, and few people use it, which will cause a lot of trouble in practice. IOS can also use Apple's new swift language, which may be used to replace object-c in the future. It's still in its infancy, so let's not discuss it.

There is an interesting contrast between objc and js: the naming style of variables/methods is just the opposite. Apple has always advocated user experience, and writing code is no exception. The program names are in English, and they should be as detailed as possible, so that you can know what you are doing by looking at the names of variables and methods, such as application: didfinishlaunching with options: but js tries to abbreviate the names of variables and methods because it is downloaded from the Internet every time. In fact, there are code compression tools, and the effect of variable names is the same no matter how long they are written, but everyone is used to using short names. For example, the above-mentioned objc application: did finishing launching with options: method is named $ () in js.

Both Objc and js are dynamic languages, which are similar in use, but objc is compiled with high speed, and many errors can be found in the process of compilation. Js is interpreted, and its performance depends on the interpretation engine. Even under the powerful v8 engine, the performance can't keep up with the compiled language. The language is too dynamic, the variables are not typed at all, it is cool to write and a little hard to debug. I always feel that js is light and flexible, bohemian and full of all kinds of strange skills. Objc is not as serious as c++ java or as flexible as js.

Second, threads

Front-end development hardly needs the concept of thread. In browser implementation, HTML and CSS parsing and rendering of a page may not be in the same thread as js, but all js codes are only executed on one thread and will not be executed concurrently, so there is no need to consider various concurrent programming problems. In the new JS feature, you can create a worker task that can be executed by another thread in parallel. However, because not all browsers support it, different threads have different standards for transmitting data, and there are few usage scenarios, it seems that it has not been used on a large scale. Tasks such as database operation/sending network requests are different from js code execution threads, but these tasks are managed by the browser, and the front end does not need to care about or influence these threads, only needs to receive event callbacks, and does not need to deal with any concurrency problems.

Terminal development requires a lot of multithreading. IOS has a main thread, and UI rendering is in this thread. Other time-consuming logic or database IO/ network requests need to be executed by another thread, otherwise it will occupy the time of the main thread, resulting in the interface unable to respond to user interaction events, or slow rendering leading to scrolling jams. The program logic is distributed in multiple threads, and it needs to deal with the data inconsistency/time disorder that may be caused by the concurrent execution of various codes. Concurrently, some bugs are difficult to troubleshoot and will fall into the pit if you are not careful. Some queues/locks are needed to ensure the execution order of the program. IOS provides a set of multithreading management method GCD, which encapsulates threads and queues in a very simple and powerful way, which is much better than other terminals or background, but it will still take a lot of effort to deal with multithreading problems.

Third, storage

Terminal development needs a lot of data storage logic. The mobile APP is not like a browser. When users open a browser, they must connect to the Internet, but when they open an APP, they are likely to be offline or in mobile GPRS with poor network conditions, so they must save the data they requested before. After the data is saved, it needs to be synchronized with the latest data of the server. If the total amount of synchronized data is too large and the traffic consumption rate is slow, incremental synchronization is needed. It needs to work out a scheme to realize incremental data return with the server, and it needs to deal with the data consistency between the client and the server. When the data storage capacity is large and the structure is complex, it is necessary to make good use of the limited memory as a cache to optimize the performance of various storage queries.

The front end rarely needs to be stored on the desktop. Unless it is a one-page app, naturally, there is no need for a series of work to update the data. The data is taken from the background and directly spliced and displayed on the page. Even if Weibo can continuously load more data in the page, the data only exists in the memory and will not be permanently stored, because the network speed of the desktop is stable, regardless of the traffic, all data can be directly fetched from the back end, and there is no need for the client to make another set of storage. It is very similar to the Web application of mobile native app, just like terminal development. The data is also saved to SQLite, and the storage logic and the problems to be dealt with are similar.

Four. structure

On the third-party framework, the web front-end is completely opposite to iOS development. The web is inherently weak and open, allowing a large number of third-party frameworks and class libraries to exert their fists and feet, while iOS is inherently powerful and closed, resulting in little space for third-party frameworks.

At first, the browser was only designed for content-based web pages, and js is just a scripting language, which can add some special effects to this web page. In the era of web application, it can't keep up with the development and needs the assistance of many third-party libraries and frameworks. In addition, the front-end development is completely open, which leads to many libraries and frameworks. In the early days, most libraries focused on encapsulating dom operations, and everyone kept building the wheels of dom operation basic libraries. After a period of competition, jQuery is the only one in the website that uses the library. In the later period, people did not duplicate the wheel of this basic library, but added some frameworks of code organization and front-end architecture, such as framework require.js, MVC framework backbone/angular.js and so on.

IOS development Apple provides a complete development framework cocoa, and this framework has been upgraded and optimized in each generation of systems, and the development model has been finalized. There is not much room for third-party frameworks, and a large number of popular open source projects are commonly used components and libraries, such as network request library AFNetworking and database operation library FMDB. However, it is difficult for large-scale frameworks such as beef framework/reactive cocoa to catch on.

Verb (abbreviation for verb) live in harmony

Front-end development needs to be compatible with a large number of browsers, such as desktop browsers such as chrome, safari, ie6-ie 10, firefox, various browsers such as Cheetah 360 and mobile browsers such as iOS/Android, with infinitely different screen sizes. It looks terrible, but it's not that difficult. Just to scare people. Webkit is used in all kinds of extreme speed modes of Chrome/safari and shell on the desktop, and there is little difference. Firefox is basically implemented according to the standard, which is not much different from webkit. The old ie6/7 needs special care, but many websites don't support ie6. There is only one mobile terminal, all of which are webkit, and there is little difference except supporting new functions. For different screen sizes, high-end points will use responsive layout, and adapt different layouts according to different screen sizes. Usually, the desktop end of the point will be fixed and the mobile end will stretch the adaptive width.

Terminal development also needs to be compatible with different system versions and mobile phone sizes. Needless to say, Android also has a size of 3.5/4/4.7/5.5/9.7 inches, but it is as easy to be compatible as the web, that is, adaptive width. UIKit of iOS has taken care of all these, and advanced functions such as autolayout and sizeClass are available, so it doesn't take much effort in size. On the system version, iOS7 is a watershed. The UI before and after iOS7 is very different, and it needs some efforts to be compatible. However, users of iOS will be updated soon, and it is expected that users below iOS7 will be ignored in another year or two.

Performance of intransitive verbs

Both the terminal and the front end are user-oriented, and the purpose of performance optimization is to present the content as soon as possible, so that the program can run smoothly under the user's operation. The terminal mainly focuses on storage/rendering performance. When an APP stores a large amount of data and the data relationship is complex, data query can easily become a performance bottleneck. It is necessary to optimize data access efficiency, plan data IO threads, design memory cache, make good use of the limited memory of terminal devices, avoid repeated rendering, reuse views as much as possible, and find the most efficient rendering scheme.

The front end pays attention to the loading speed of the page. Because the structure/style/program/resource pictures of the webpage are all requested in real time, in order to make the page present the content faster, it is necessary to optimize these requests and make these resources load at the fastest speed, including merging pictures/codes to reduce the number of requests, compressing codes, parallel requests, caching code requests according to version numbers, gzip compression, and lazy loading of modules/pictures. In addition, like the terminal, we also pay attention to rendering performance, follow some rules to avoid page reflow, avoid using CSS shadows, and use CSS3 animation instead of js.

Seven. compile

Terminal development needs to be compiled. Compile the program into machine language, and then link with various libraries to generate executable files corresponding to the platform. Finally, it is scheduled and executed by the operating system. The rules of compiling and linking in iOS terminal development have been encapsulated in xcode, a development tool. Generally, you don't need to care, but you still have to deal with many compilation things when you have deep requirements, such as using Clang at the front end of the compiler, customizing static code detection rules, writing automatic compilation and continuous integration compilation scripts, packaging and generating static libraries, and optimizing the size of the APP according to the composition of linked executable files.

Front-end developers don't need to compile, just throw the code to the browser, and the browser will execute it while parsing the code. Although js/css code can be parsed and executed by the browser without doing anything, in order to optimize the performance mentioned above, all code and resource files will be processed before the front-end code goes online. These processes include: compressing and merging js/css, merging css sprite diagrams, handling module dependencies, handling code resource version numbers, and handling resource positioning. This process is very similar to the compilation of traditional programs. By optimizing the code shown to people and solving some dependencies, it can be regarded as a front-end compilation process. Tools like grunt.js/fis can help with this compilation process. Usually, front-end compilation is combined with online deployment as a part of online system.

Eight. safe

Although the security of the front-end and terminal does not need to be considered as much as that of the back-end, there are still some places to pay attention to. In terms of request security, the terminal and the front end are the same. Requests sent by users to the back end need to be routed through layers, and they are intercepted, tampered with or played back without knowing where. Therefore, some measures need to be taken to prevent these situations. The most common is identity authentication, which mostly uses expired tokens instead of user names and passwords to prevent hackers from logging into this account forever after being caught. Those who require high data security will use encrypted transmission or use https. In addition, it is necessary to deal with some problems such as DNS hijacking and operator advertisement implantation as appropriate.

Terminals rarely consider other security issues. The system has helped to ensure the security of the entire APP running environment on the iOS machine that has not escaped from prison. However, under the jailbreak machine, malicious programs can do anything with root permissions, and the APP is also hard to prevent. At the front end, the characteristics of the browser make the front end development have several security risks. First, js code can be dynamically inserted anywhere on the web page, and the browser will execute the code indiscriminately. Second, authentication information is stored in cookie. Third, you can freely embed pages of other websites through iframe. These attacks are caused by XSS, CSRF and cookie hijacking, so the front-end needs to consider these security issues when writing code and take corresponding preventive measures. The simplest and most important preventive measure is to completely filter all user input and output content to avoid malicious code embedding in the page.

Nine. Interaction/development

Finally, I will talk about my personal feelings about the interactive development of these two fields. When I used to be the front end of the web, I felt that the web had put human-computer interaction back ten years, and the interaction was hard click-the result was scrolling and refreshing one by one. When many people are preaching how cool html5 can be, in fact, FLASH can be made ten years ago, which is smoother than the most modern browsers. After the popularity of iPhone, human-computer interaction finally returned to its proper level, and the experience was much smoother than that of web. Fingertip interaction/smooth animation/convenient sliding gesture/infinite realization, the mainstream has finally recovered or surpassed the level of Flash ten years ago.

However, human-computer interaction has improved, but the development method has regressed. The development method of web is very advanced, and users use the latest version. When bugs are found, they can be fixed online in a few seconds, which is especially suitable for rapid iteration in the Internet environment. However, the terminal APP can't. Apart from the censorship of iPhone, Android can't guarantee users to use the latest programs. They use the traditional client update method. Fixed versions of bugs can't be given to users in time, and they can't be online dozens of times a day, so many old ones need to be maintained. This is all because the mobile network is unstable and the traffic is limited. The mobile terminal can't completely rely on the network like the desktop browser, so the development method will not change much until the mobile network has stable traffic and is free.

Besides, I'm not optimistic about HTML5. It has been said on the internet that it can replace APP for three or four years, and there is no record so far. I don't see its advantages. Native apps can get more system resources and a smoother human-computer interaction experience. HTML5 can never be compared in this respect, and it can't give full play to the development advantages of web under the limitation of mobile network and traffic, so it won't become the mainstream, and it is only suitable for making some lightweight gadgets.