IOS App startup optimization (I) : Detect startup time

IOS App startup Optimization (2) : Physical memory and virtual memory

IOS App startup optimization (3) : binary rearrangement

IOS App startup optimization (4) : pile && get method symbol at compile time

IOS App startup optimization (5) : Collect symbols && generate Order File

IOS App launch optimization (vi) : Utility party directly see here

Memory management

Memory is managed paging, mapping tables are not in bytes, but in pages.

  • LinuxIn order to4KTo one page
  • macOSIn order to4KTo one page
  • iOSIn order to16KOne page

The input terminal

pageSize
Copy the code

4 * 1024 = 4096

Memory is a waste of

In the early days, computers kept starting applications. After a certain number of applications were started, an error would be reported. Applications could not run properly.

This is because early computers didn’t have virtual addresses, and once loaded they were all loaded into memory. Once the physical memory runs out, the application can no longer be started.

Applications in memory are sorted sequentially, so that a process can access the memory address of another process only by moving its own address tail back a bit, which is quite unsafe.

Virtual memory

Users will not use all the memory when they use it. If the App is loaded into the memory as soon as it starts, a lot of memory space will be wasted. Virtual memory technology appears to solve this memory waste problem.

After the App starts, it will think that it has obtained the memory space needed for the entire App operation, but in fact, it does not apply for so much space in physical memory, but only generates a table associated with virtual memory and physical memory.

Address translation

When the App needs to use the address of a certain virtual memory, it checks whether the virtual address has applied for space in the physical memory through this table.

  • If requested, access the physical memory address through the table’s record,
  • If not, request a physical memory space and record it in the table (Page Fault).

This process mapping to different physical memory Spaces through the process mapping table is called address translation, and this process requires CPU and operating system cooperation.

Page Fault

The following operations are performed when the data is not in physical memory

  • The system blocks the process
  • Corresponds to the diskPageLoad the data into memory
  • Point virtual memory to physical memory

This behavior is Page Fault

Flexible Memory Management

This solves the waste problem, but what if all of the physical memory is used up? There may be insufficient memory. In order to ensure the normal use of the current App, data loading follows the following principles:

  • If there is free memory space, put it in the empty memory space
  • If not, overwrite the other process’s data
  • Specific coverage is handled by the operating system

Resolving security issues

The space problem has been solved, but what about the security problem?

ASLR (Address Space Layout Randomization) technology and code signature are introduced in the loading process of dylib for safety.

ASLR: Images, executables, dylib, and bundles will add a slide in front of the preferred_address to prevent the internal address from being located.

Why binary rearrangement

Virtual memory technology produces Page faults, which can be a time-consuming operation.

Page time also varies widely, from 1 microsecond to 0.8 milliseconds.

This time is not obvious in the process of use, but a large amount of data is loaded when starting up. If a large number of Page faults occur, users will have an obvious perception after time stacking.

If we put all the boot-time code on one or two pages, we can greatly reduce Page faults and optimize startup speed, which is binary rearrangement.

Binary rearrangement details please go to iOS App to start optimization (3) : binary rearrangement