KR100738419B1 - Smartphone Equipped with Memory Manager For Multi Application Based WIPI - Google Patents

Abstract

The present invention relates to a smart phone equipped with a memory manager for executing a Wi-Fi-based multi-application, each application running based on Wi-Fi loaded on the operating system of the smart phone to share the system heap area on the memory Provided is a smart phone equipped with a memory manager for executing the Wi-Fi-based multi-application to use the application heap area independently.

Smartphone, Operating System, Wifi, Multi-Application, Memory Management, System Heap Area, Application Heap Area

Description

Smartphone Equipped with Memory Manager For Multi Application Based WIPI

1 is a schematic hierarchical view of a smartphone according to the prior art;

Figure 2 is a schematic hierarchical view of the smartphone proposed in the present invention.

3 is a hierarchical diagram of an embodiment of a memory manager for executing a Wi-Fi based multi-application according to the present invention;

* Explanation of symbols on the main parts of the drawing

10: Windows CE OS 20: Nate Intro Applicaion

21: NGB Application 22: WAM Downloader Application

41: System Heap Area 42: Application Heap Area

50: Memory Manager

The present invention relates to a smart phone equipped with a memory manager for executing a Wi-Fi-based multi-application, and more particularly, each application to be executed based on the Wi-Fi loaded on the operating system of the smart phone system heap area on each other The present invention relates to a smart phone equipped with a memory manager for executing a Wi-Fi-based multi-application that allows sharing and using the application heap area independently.

Recently, smart phones that combine the functions of a mobile phone and a PDA have been in the spotlight. These smartphones are equipped with a larger memory and a higher performance CPU than conventional mobile phones, and are equipped with an operating system (OS) to support various application execution, voice / data communication, and PC interworking. Smartphone operating systems include the "symbian OS" developed by the British Symbian company and the "WindowsCE OS" developed by the Microsoft company of the United States.

Meanwhile, South Korea has adopted Wireless Internet Platform for Interoperability (WIPI) as the wireless Internet platform standard for mobile phones. Accordingly, each mobile communication company and each terminal manufacturer has installed (porting) portie in the middle of the operating system (eg, REX) layer and the application layer of the mobile phone.

As mentioned earlier, while existing mobile phones are equipped with Wi-Fi in existing operating systems such as REX, recent smartphones do not have Wi-Fi. We are working on developing Wi-Fi on smartphones so that applications (eg, browsers, wireless Internet menus, content, ringtones, videos, document creation programs, etc.) can run smoothly on smartphones.

In order to install Wi-Fi on the smartphone as above, it is necessary to add / change some specifications of Wi-Fi in consideration of the specifications of symbian OS or Windows CE OS and upload Wi-Fi on the operating system of the smartphone. In particular, one of these considerations is how the operating system of smartphones treats Wiffy. This will be described with reference to FIG. 1.

1 is a schematic hierarchical view of a smart phone according to a conventional scheme.

Various applications ("Nate Intro", "NGB Browser" and "Shock Downloader") executed on the smartphone's operating system (e.g., "WindowsCE OS") 10 based on various applications, such as Wi-Fi, 21, 22, 23) is mounted, each of the heap area [Note; This heap area is implemented in memory] (31, 32, 33).

As shown in FIG. 1, the operating system 10 of the smartphone treats the Wi-Fi as only one application. Accordingly, various applications executed based on the Wi-Fi are also treated as a single application. Can be executed in multiples. As such, since the multi-application can be executed in the smart phone, the user can perform various tasks through more applications [eg; Browsing the swap site, downloading content, creating a multimedia message (MMS), etc.] at the same time.

However, the operating system 10 of the smartphone treats each application 21, 22, 23 as an instance and allocates each heap area 31, 32, 33 to each memory for each application. Therefore, there is a problem in that the memory of the heap area not used for each application is wasted. That is, although each of the above applications 21, 22, and 23 are executed on the basis of Wi-Fi, since the memory heap area is allocated by the operating system 10, as the number of Wi-Fi-based applications executed on the smartphone increases, Waste is getting worse.

The present invention has been proposed to solve the above problems and to meet the above requirements, and each application to be executed based on the Wiki loaded on the operating system of the smartphone to share the system heap area in the memory and use each other An object of the present invention is to provide a smart phone equipped with a memory manager for executing the Wi-Fi based multi-application, which allows the application heap area to be used independently.

In order to achieve the above object, the present invention provides a smartphone on which an operating system is mounted on the operating system, and a memory manager that allocates / releases a memory heap area for an application executed based on the operating system. To
The operating system for allocating a system heap region for storing the hardware-related resource information of the smartphone and the storage of static application-related information including the Wi-Fi to the memory, and an application heap region for storing the Wi-Fi-based application-related information in the memory ; And
When the Wi-Fi is executed, the operating system is requested to allocate memory for the remaining area (Wifi-use area) except the shared buffer among the system heap areas, and when the Wi-Fi based application is executed, the operating system-related information Provided is a smart phone equipped with a memory manager for executing a Wi-Fi-based multi-application, characterized in that it comprises the memory manager for requesting the allocation of a separate application heap area for storage to the memory.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, detailed descriptions of well-known functions or configurations will be omitted if it is determined that the detailed description of the present invention may unnecessarily obscure the subject matter of the present invention. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

2 is a schematic hierarchical view of a smart phone according to the present invention.

Generally, various applications ("Nate Intro", "NGB Browser" and "Shock Downloader") executed on the smartphone's operating system (e.g., "WindowsCE OS") 10 based on various applications, such as Wifi, 21 , 22, and 23 may be executed in a multi-mounted state. In the present invention, each application 21, 22, and 23 may share and use the heap regions 30 in the memory.

To this end, in the present invention, a memory manager is implemented between the operating system layer and the application layer of the smartphone, preferably on a Wi-Fi, and the system heap area and the application are stored on the memory by the memory manager. The heap is divided into application heap areas, and shared data for each application is stored in the system heap area, and individual data for each application is stored in each area of the application heap area. Hereinafter, the memory manager of the present invention will be described in more detail with reference to FIG. 3.

3 is a hierarchical diagram of a memory manager for executing a Wi-Fi based multi-application according to the present invention.

As shown in FIG. 3, the smart phone according to the present invention includes various hardware (eg, memory, CPU, I / O device, network device, etc.) in the lowermost layer, and the WindowsCE OS 10 in the operating system layer. The WIPI and the memory manager 50 merged with the WIPI are mounted on the platform [middleware] layer, and the various applications 20, 21, and 22 running on the WIPI are mounted on the application layer. On the other hand, in the following embodiment of the present invention will be described as an example that the Windows CE OS is mounted as a basic OS of the smartphone, it will be readily understood by those skilled in the art that the present invention is applied to the operating system of other smartphones, such as symbian OS.

In the present invention, the system heap area 41 and the application heap area 42 are divided on the memory of the smart phone, and the system heap area 41 is dynamically allocated in size by the Windows CE OS 10, The application heap area 42 is individually allocated the size of the application area corresponding to the application heap area 42 by the memory manager 50 according to whether each application 20, 21, 22 is executed.

That is, the Windows CE OS 10 loads resource information related to hardware mounted on the smartphone at the time of its operation and information related to various software executed at the time of operating system initialization, preferably a static application, onto a memory. In order to determine the size of the system heap area 41 based on the contents defined in the known windowsCE memory map file (also known as the shared memory mechanism of the native OS), it allocates the memory.

As described above, the hardware resource information loaded in the system heap area 41 and the static application related information are all applications executed on the Windows CE OS 10, preferably Wiki and various applications executed on the basis of the Wiki. , 22) are data shared with each other. For example, the hardware resource information is data that is typically stored in the "Shared Buffer" in the WindowsCE OS. The hardware resource information includes linking information, tree information, etc. on the type and number of applications that can be executed in the smartphone, and I / O device usage information. , Network device access information, network parameter related information, and the like. In addition, the static application-related information includes the platform information required for each application 20, 21, and 22 to be executed in the smartphone, that is, the Wi-Fi has the respective applications 20, 21, 22 such as Wi-Fi core-related information, Wi-Fi global table, and the like. All the data necessary to run on the OS 10.

In other words, in a conventional mobile phone, a terminal operating system (also called "OEM") allocates a fixed heap area (e.g., about 6 MB) to memory for WiPi and various applications that are executed based on the WiPi. Although memory was managed, in this case, unused memory was wasted when the application was not executed, and the terminal had to be rebooted due to insufficient memory when the application was excessively executed.

However, in the present invention, the Wiki is treated as one application in the operating system through the shared memory mechanism of the native OS of the WindowsCE OS 10 of the smart phone and the memory for various applications executed based on the WiFi is available. Allocate a system heap area in a flexible manner.

Preferably, in the present invention, memory is allocated directly from the Windows CE OS 10 only to the system heap area 41 except for the "Shared Buffer" which is the basic mechanism of the Windows CE OS 10. In order to use the shared memory mechanism of the WindowsCE OS 10 in Wippi, the memory manager 50 uses the space available to the WindowsCE OS 10 when the Wippi is running. ] Asks you to allocate fluid memory.

Table 1 below shows the system heap area 41 allocated on memory.

THeapDesc * s_pSysHeapDesc = NULL; // heap start position DWORD s_dwHeapPoolSize = 0; // heap size PCHUNK_T s_pHeapFirstChunk = 0; // first free list PCHUNK_T s_pHeapLastChunk = 0; // last free list

Meanwhile, each of the applications 20, 21, and 22 executed on the basis of Wippi requests the Wifi to allocate its own memory at the time of execution. In the present invention, the memory manager 50 merged into Wiwi is a specific application. Receives a memory allocation request from the memory allocation API and allocates the corresponding application heap area 42 through the Windows CE OS 10 using a memory related API defined in the WIPI CORE and the Handset Adaptation Layer (HAL). .

That is, the memory manager 50 requests memory allocation from a specific application [eg; When receiving WIPI HEAP Alloc AP (MC_knlAlloc ())], check the RO Code and RW Data that make up this application and consider the data capacity required to run this application. 42). The application heap area 42 has an independent heap area for each application, and each application uses its own memory handler to access its own heap area in memory.

In other words, the RO code constituting the application refers to a read only code, which is a constant having properties that are not changed from programming code such as "for", "if / else", and "void". RW Data refers to a read / write data area that can be read and written, such as actual application data (eg, image / sound data, etc.) and global variables having changed properties. Can be mentioned.

As such, the memory manager 50 of the present invention stores the header, Ro Code, RW Data, and memory handler information, which constitute an application, in the application heap area 42 for each application, and in particular, reports the Ro Code and the RW Data. The size of the application heap area 42 is determined in consideration of data required for initial execution of the application and expected data capacity in the future.

[Table 2] below shows a part of the data stored in the application heap area 42 allocated on the memory.

DAF, DLF Header, Code, Data // Download application executable file, library MAF, MLF Header, Code, Data // Embedded application executable file, library Application memory handle // Memory handler information used by each application

As described above, each application 20, 21, and 22 executed on the basis of Wi-Fi performs its own process while keeping its own instance, etc. in its own application heap area 42, and accesses network devices or When using the Wi-Fi-related resources, each application 20, 21, 22 performs the process using the smartphone resource access or Wi-Fi-related data stored in the system heap area 41.

On the other hand, the Windows CE OS 10 deletes the corresponding data stored in the system heap area 41 when the static application execution ends (e.g., Wifi execution ends), hardware removal (e.g., network device removal), or the like. Heap area de-allocation], and the memory manager 50 deletes (heap area de-allocation) corresponding data stored in the application heap area 42 when the execution of a specific application executed on the basis of Wi-Fi is terminated. In addition, since it is conventionally WindowsCE OS 10 to actually access and control the memory, the memory manager 50 uses the memory-related API defined in Wi-Fi at the time of memory allocation / release. ) Requests memory allocation / release and returns the processing result.

While the content of the present invention has been described by way of examples, the embodiments of the present invention are merely illustrative of the present invention and should not be construed as limiting the scope of the present invention. Those skilled in the art to which the present invention pertains may modify or alter the present invention in various forms within the principles and scope described in the claims herein.

The present invention as described above has the effect of preventing the memory is wasted in running the Wi-Fi-based multi-application in the smartphone.

Claims (3)

In the smartphone equipped with Wi-Fi on the operating system, and in the Wi-Fi is equipped with a memory manager for allocating / freeing the memory heap area for the application running based on the Wi-Fi, The operating system for allocating a system heap region for storing the hardware-related resource information of the smartphone and the storage of static application-related information including the Wi-Fi to the memory, and an application heap region for storing the Wi-Fi-based application-related information in the memory ; And When the Wi-Fi is executed, the operating system is requested to allocate memory for the remaining area (Wifi-use area) except the shared buffer among the system heap areas, and when the Wi-Fi based application is executed, the operating system-related information And a memory manager for requesting to allocate an individual application heap area to a memory for storage. The method of claim 1, The memory manager, When the memory allocation request is received from the specific application based on the Wi-Fi, the RO Code and the RW data forming the specific application are checked, and the individual application heap area corresponding to the size is allocated to the operating system in consideration of the data capacity required to execute the application. Smart phone equipped with a memory manager for executing a Wi-Fi-based multi-application, characterized in that requesting the assignment. The method according to claim 1 or 2, Each of the application heap region is a smart phone equipped with a memory manager for executing a Wi-Fi-based multi-application, characterized in that the header, Ro Code, RW Data and memory handler information forming each application is stored.

Images