KR20210029621A - 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치 - Google Patents

전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치 Download PDF

Info

Publication number
KR20210029621A
KR20210029621A KR1020190111084A KR20190111084A KR20210029621A KR 20210029621 A KR20210029621 A KR 20210029621A KR 1020190111084 A KR1020190111084 A KR 1020190111084A KR 20190111084 A KR20190111084 A KR 20190111084A KR 20210029621 A KR20210029621 A KR 20210029621A
Authority
KR
South Korea
Prior art keywords
application
information
metadata
electronic device
update
Prior art date
Application number
KR1020190111084A
Other languages
English (en)
Inventor
정관희
세르게이 론차코프
이반 티타렌코
구르겐 아라케로프
이반 메이단스키
김효정
알렉산드르 세무카
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020190111084A priority Critical patent/KR20210029621A/ko
Priority to EP20860639.2A priority patent/EP3994571A4/en
Priority to PCT/KR2020/011323 priority patent/WO2021045428A1/en
Priority to CN202080061838.5A priority patent/CN114341800A/zh
Priority to US17/004,192 priority patent/US11327739B2/en
Publication of KR20210029621A publication Critical patent/KR20210029621A/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G06F9/4451—User profiles; Roaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G06F9/4552—Involving translation to a different instruction set architecture, e.g. just-in-time translation in a JVM
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading

Abstract

본 개시의 다양한 실시예들에 따르면, 전자 장치에 설치된 어플리케이션의 업데이트 시에 런타임 성능(runtime performance)을 향상할 수 있는 장치 및 방법에 관하여 개시한다. 다양한 실시예들에 따른 전자 장치는, 무선 통신을 제공하도록 구성된 통신 회로, 상기 통신 회로와 작동적으로 연결된 적어도 하나의 프로세서, 및 상기 프로세서와 작동적으로 연결된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 어플리케이션의 업데이트를 감지하고, 상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하고, 상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하고, 상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하도록 하는 인스트럭션들을 저장할 수 있다. 다양한 실시예들이 가능하다.

Description

전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치{APPARATUS AND METHOD FOR IMPROVING RUNTIME PERFORMANCE AFTER APPLICATION UPDATE IN ELECTRONIC DEVICE}
다양한 실시예들은 전자 장치에 설치된 어플리케이션의 업데이트 시에 런타임 성능(runtime performance)을 향상할 수 있는 장치 및 방법에 관하여 개시한다.
전자 장치는 하나 이상의 리소스들을 제어하기 위한 운영 체제(OS, operating system)와 운영 체제에서 실행 가능한 어플리케이션(application)을 포함할 수 있다. 운영 체제는, 예를 들면, 안드로이드(AndroidTM), 아이오에스(iOSTM), 윈도우(WindowsTM), 심비안(SymbianTM), 타이젠(TizenTM), 또는 바다(BadaTM)를 포함할 수 있다. 일 실시예에 따라, 안드로이드에서는 기존에 사용되던 달빅(Dalvik) 가상 머신(VM, virtual machine)의 한계점을 해결하기 위해 ART(Android RunTime)라는 새로운 런타임(runtime)을 제공하고 있다. 예를 들어, 달빅 가상 머신은 JIT(Just-In-Time) 컴파일 방식을 사용하고, 초기의 ART는 AOT(Ahead-Of-Time) 컴파일 방식을 사용하였으나, 각각의 방식의 한계로 인하여, 최근에는 JIT 컴파일 방식과 AOT 컴파일 방식을 하이브리드 방식으로 사용하고 있다. 예를 들어, AOT 컴파일 방식은 어플리케이션을 설치할 때 컴파일 시간이 많이 소요되며 컴파일된 산출물(예: *.odex, *.vdex, *.art) 저장을 위한 저장공간이 추가로 요구될 수 있다. 예를 들어, JIT 컴파일 방식은 런타임 중에 네이티브 코드(native code)로 컴파일 되기 때문에 설치하는데 시간은 적게 걸리나 캐시된 메모리가 해제됐을 때 반복 수행이 감지되면 재 변환이 필요하고, 재 변환에 소요되는 시간만큼 어플리케이션 동작에 지연이 발생하게 되어 JIT 컴파일에 소모되는 시간이 오래 걸릴 수 있다.
반면, 하이브리드 방식은 JIT와 AOT의 장점을 모두 살리기 위해 두 방식을 모두 사용하는 방식일 수 있다. 예를 들어, 어플리케이션의 최초 설치 시에는 JIT를 사용하여 설치 시간과 저장에 필요한 용량을 줄이고, 어플리케이션을 구동할 때 ART에서 해당 컴파일된 코드를 바로 사용하는 방식을 적용하고 있다.
전자 장치는 전자 장치 내에 설치된 어플리케이션에 대해, 다양한 어플리케이션 스토어(application store)(이하, '앱스토어(App store)'라 한다)(예: 플레이 스토어TM)를 통해 어플리케이션 업데이트를 주기적으로 수행할 수 있다. 일 실시예에 따르면, 전자 장치는 어플리케이션의 프로파일(profile)이 업데이트되면, 업데이트된 프로파일을 수집하여 앱스토어(또는 클라우드, 서버)에 전달할 수 있다. 앱스토어에서는 전자 장치로부터 수신된 프로파일(또는 정보)를 기반으로 해당 어플리케이션에 적합한 공통 프로파일을 생성할 수 있다. 앱스토어에서는 어플리케이션 업데이트 시 어플리케이션의 업데이트 파일(예: 설치 파일(예: *.apk 파일))과 어플리케이션의 공통 프로파일(예: *.dm 파일)을 함께 전자 장치로 전달할 수 있다. 전자 장치는 앱스토어로부터 전달된 업데이트 파일과 어플리케이션의 공통 프로파일에 기반하여 AOT 컴파일을 수행하여 네이티브 코드를 파일로 저장할 수 있다.
전자 장치(또는 운영 체제(예: 안드로이드))에서는 앱스토어를 통해 어플리케이션의 프로파일을 저장하고 있는 경우, 저장된 프로파일을 기반으로 AOT 컴파일을 수행하여 네이티브 코드를 파일로 저장할 수 있다. 전자 장치에 저장된 프로파일은 업데이트된 어플리케이션 버전(version)이 많은 사용자에 의해 사용되고 있고 그 정보가 앱스토어에 수집이 되는 경우에 생성되는 정보일 수 있다. 따라서, 앱스토어에서, 새롭게 업데이트된 어플리케이션의 해당 버전과 관련하여 전자 장치가 관련 프로파일을 가지고 있지 않은 경우나, 또는 충분한 데이터가 수집되지 못하는 어플리케이션의 경우, 전자 장치가 어플리케이션을 다운로드 요청 시 해당 프로파일을 같이 전달하지 못할 수 있다. 또한, 앱스토어에서는, 전자 장치를 사용하는 사용자가 아닌 여러 다른 사용자의 정보를 기반으로 만들어진 프로파일을 제공함에 따라, 앱스토어를 통해 제공되는 프로파일은 사용자 패턴과 정확히 일치하지 않을 수 있다.
일반적으로, 전자 장치는 어플리케이션 업데이트 시, 업데이트 전인 어플리케이션을 사용하면서 사용자 패턴에 따라 생성된 프로파일과 네이티브 코드를 삭제(또는 제거)할 수 있다. 따라서, 전자 장치는 어플리케이션에 대한 사용자 패턴에 따라 생성된 프로파일과 네이티브 코드가 사라짐에 따라, 어플리케이션 업데이트 이후 이전의 사용자 경험에 대한 데이터를 잃게 되며, 해당 어플리케이션에 대한 사용 이력이 존재하지 않으므로, 런타임 성능이 떨어지고 어플리케이션 진입에도 지연이 발생할 수 있다. 또한, 사용자는 이전에 가졌던 성능을 동일 수준으로 확보하기 위해서는 충분한 프로파일링과 네이티브 코드 생성에 필요한 시간을 기다려야 하며, 이는 정형화된 시간이 아니며, 사용자마다 사용하는 방법에 따라 달라질 수 있다. 따라서, 사용자는 새로운 어플리케이션을 업데이트하는 경우 이전 사용에 비해 떨어지는 성능으로 인해 불편함을 야기할 수 있다.
다양한 실시예들에서는, 전자 장치에서 어플리케이션 업데이트 시 이전 프로파일(profile)과 바이트코드(bytecode)를 활용하여 런타임(runtime) 성능을 개선할 수 있는 방법 및 장치에 관하여 개시한다.
다양한 실시예들에서는, 전자 장치의 ART(Android RunTime) 환경에서 어플리케이션 업데이트 시, 사용자의 어플리케이션 사용 패턴에 따라 이전에 저장된(또는 생성된) 프로파일과 바이트코드를 활용하여 런타임 성능을 개선할 수 있는 방법 및 장치에 관하여 개시한다.
다양한 실시예들에서는, 전자 장치에서 앱스토어로부터 내려오는 어플리케이션의 공통 프로파일(예: *.dm 파일)의 유무와 상관없이 사용자의 사용 패턴에 따라 만들어진 기존의 프로파일을 유지하고, 기존의 프로파일을 이용하여 어플리케이션의 업데이트를 처리할 수 있는 방법 및 장치에 관하여 개시한다.
다양한 실시예들에서는, 앱스토어로부터 어플리케이션을 다운로드 시 앱스토어로부터 프로파일링이 함께 전달되지 않은 경우에도 사용자 패턴에 따른 프로파일링을 그대로 유지하고, 이후 생성된 산출물을 이용하여 프로파일링이 사용되었는지 여부를 확인할 수 있는 방법 및 장치에 관하여 개시한다.
본 발명의 다양한 실시예들에 따른 전자 장치는, 무선 통신을 제공하도록 구성된 통신 회로, 상기 통신 회로와 작동적으로 연결된 적어도 하나의 프로세서, 및 상기 프로세서와 작동적으로 연결된 메모리를 포함하고, 상기 메모리는, 실행 시에, 상기 프로세서가, 어플리케이션의 업데이트를 감지하고, 상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하고, 상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하고, 상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하도록 하는 인스트럭션들을 저장할 수 있다.
본 발명의 다양한 실시예들에 따른 전자 장치의 동작 방법은, 어플리케이션의 업데이트를 감지하는 동작, 상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하는 동작, 상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하는 동작, 상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하는 동작을 포함할 수 있다.
상기와 같은 과제를 해결하기 위하여 본 발명의 다양한 실시예들에서는, 상기 방법을 프로세서에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 판독 가능한 기록 매체를 포함할 수 있다.
다양한 실시예들에 따른 전자 장치 및 그의 동작 방법에 따르면, 전자 장치에서 어플리케이션 업데이트 시, 사용자의 어플리케이션 사용 패턴에 따라 이전에 저장된 이전 프로파일과 바이트코드를 이용하여, 런타임 성능을 향상할 수 있다. 다양한 실시예들에 따르면, 전자 장치는 앱스토어로부터 내려오는 어플리케이션의 공통 프로파일(예: *.dm 파일)의 유무와 상관없이, 사용자의 사용 패턴에 따라 만들어진 이전 프로파일을 유지하고, 이전 프로파일을 이용하여 어플리케이션의 업데이트를 처리할 수 있다. 다양한 실시예들에 따르면, 전자 장치는 이전 프로파일과 이전 어플리케이션의 설치 파일 내의 실행 파일(예: dex 파일)을 기반으로, 업데이트 될 어플리케이션의 실행 파일을 비교하여 변경 사항이 없는 메소드(method)와 클래스(class)에 대해서는 기존 정보를 유지할 수 있다. 다양한 실시예들에 따르면, 전자 장치는 기존 정보를 기반으로 어플리케이션에 대한 새로운 프로파일을 생성하고, 새롭게 생성된 어플리케이션의 프로파일 정보를 이용하여 어플리케이션 업데이트 시점에 사용할 수 있다. 다양한 실시예들에 따르면, 전자 장치는 새롭게 생성된 프로파일을 기반으로 핫 메소드(hot method)에 대해 네이티브 코드를 생성하고, 핫 클래스(hot class)에 대해 어플리케이션 이미지 파일(예: *.art)을 생성하여 기존 대비 사용자에게 보다 빠른 런타임 성능을 제공할 수 있다. 다양한 실시예들에 따르면, 전자 장치는 어플리케이션의 업데이트 이후에, 업데이트된 어플리케이션에 대한 추가적이 사용 없이도, 바로 사용자가 이전에 사용했던 패턴에 따라 적용된 런타임 성능으로 어플리케이션을 사용하도록 하는 사용자 경험을 제공할 수 있다.
도 1은 다양한 실시예들에 따른 네트워크 환경 내의 전자 장치의 블록도이다.
도 2는 다양한 실시예들에 따른 전자 장치의 기능 모듈의 예를 도시하는 도면이다.
도 3은 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
도 4는 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
도 5는 다양한 실시예들에 따른 전자 장치에서 프로파일을 생성하는 방법을 도시하는 흐름도이다.
도 6은 다양한 실시예들에 따른 전자 장치에서 컴파일을 수행하는 방법을 도시하는 흐름도이다.
도 7은 다양한 실시예들에 따른 전자 장치에서 이전 프로파일에 기반하여 새로운 프로파일을 생성하는 예를 설명하기 위한 도면이다.
도 8은 다양한 실시예들에 따른 전자 장치에서 생성하는 메타데이터의 예를 설명하기 위한 도면이다.
도 9는 다양한 실시예들에 따른 전자 장치에서 메타데이터를 매칭하는 예를 설명하기 위한 도면이다.
도 10, 도 11a, 및 도 11b는 다양한 실시예들에 따른 전자 장치에서 메타데이터 생성을 위한 난독화 동작을 설명하기 위한 도면들이다.
도 1은 다양한 실시예들에 따른 네트워크 환경(100) 내의 전자 장치(101)의 블록도이다.
도 1을 참조하면, 네트워크 환경(100)에서 전자 장치(101)는 제1 네트워크(198)(예: 근거리 무선 통신 네트워크)를 통하여 전자 장치(102)와 통신하거나, 또는 제2 네트워크(199)(예: 원거리 무선 통신 네트워크)를 통하여 전자 장치(104) 또는 서버(108)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 서버(108)를 통하여 전자 장치(104)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 프로세서(120), 메모리(130), 입력 장치(150), 음향 출력 장치(155), 표시 장치(160), 오디오 모듈(170), 센서 모듈(176), 인터페이스(177), 햅틱 모듈(179), 카메라 모듈(180), 전력 관리 모듈(188), 배터리(189), 통신 모듈(190), 가입자 식별 모듈(196), 또는 안테나 모듈(197)을 포함할 수 있다. 어떤 실시예에서는, 전자 장치(101)에는, 이 구성 요소들 중 적어도 하나(예: 표시 장치(160) 또는 카메라 모듈(180))가 생략되거나, 하나 이상의 다른 구성 요소가 추가될 수 있다. 어떤 실시예에서는, 이 구성 요소들 중 일부들은 하나의 통합된 회로로 구현될 수 있다. 예를 들면, 센서 모듈(176)(예: 지문 센서, 홍채 센서, 또는 조도 센서)은 표시 장치(160)(예: 디스플레이)에 임베디드(embedded)된 채 구현될 수 있다.
프로세서(120)는, 예를 들면, 소프트웨어(예: 프로그램(140))를 실행하여 프로세서(120)에 연결된 전자 장치(101)의 적어도 하나의 다른 구성 요소(예: 하드웨어 또는 소프트웨어 구성 요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 일 실시예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서(120)는 다른 구성 요소(예: 센서 모듈(176) 또는 통신 모듈(190))로부터 수신된 명령 또는 데이터를 휘발성 메모리(volatile memory)(132)에 로드(load)하고, 휘발성 메모리(132)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 비휘발성 메모리(non-volatile memory)(134)에 저장할 수 있다. 일 실시예에 따르면, 프로세서(120)는 메인 프로세서(121)(예: 중앙 처리 장치(CPU, central processing unit) 또는 어플리케이션 프로세서(AP, application processor)), 및 이와는 독립적으로 또는 함께 운영 가능한 보조 프로세서(123)(예: 그래픽 처리 장치(GPU, graphic processing unit), 이미지 시그널 프로세서(ISP, image signal processor), 센서 허브 프로세서(sensor hub processor), 또는 커뮤니케이션 프로세서(CP, communication processor))를 포함할 수 있다. 추가적으로 또는 대체적으로, 보조 프로세서(123)는 메인 프로세서(121)보다 저전력을 사용하거나, 또는 지정된 기능에 특화되도록 설정될 수 있다. 보조 프로세서(123)는 메인 프로세서(121)와 별개로, 또는 그 일부로서 구현될 수 있다.
보조 프로세서(123)는, 예를 들면, 메인 프로세서(121)가 인액티브(inactive)(예: 슬립(sleep)) 상태에 있는 동안 메인 프로세서(121)를 대신하여, 또는 메인 프로세서(121)가 액티브(active)(예: 어플리케이션 실행) 상태에 있는 동안 메인 프로세서(121)와 함께, 전자 장치(101)의 구성 요소들 중 적어도 하나의 구성 요소(예: 표시 장치(160), 센서 모듈(176), 또는 통신 모듈(190))과 관련된 기능 또는 상태들의 적어도 일부를 제어할 수 있다. 일 실시예에 따르면, 보조 프로세서(123)(예: 이미지 시그널 프로세서 또는 커뮤니케이션 프로세서)는 기능적으로 관련 있는 다른 구성 요소(예: 카메라 모듈(180) 또는 통신 모듈(190))의 일부로서 구현될 수 있다.
메모리(130)는, 전자 장치(101)의 적어도 하나의 구성 요소(예: 프로세서(120) 또는 센서모듈(176))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어(예: 프로그램(140)) 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다. 메모리(130)는, 휘발성 메모리(132) 또는 비휘발성 메모리(134)를 포함할 수 있다.
프로그램(140)은 메모리(130)에 소프트웨어로서 저장될 수 있으며, 예를 들면, 운영 체제(OS, operating system)(142), 미들웨어(middleware)(144) 또는 어플리케이션(146)을 포함할 수 있다.
입력 장치(150)는, 전자 장치(101)의 구성 요소(예: 프로세서(120))에 사용될 명령 또는 데이터를 전자 장치(101)의 외부(예: 사용자)로부터 수신할 수 있다. 입력 장치(150)는, 예를 들면, 마이크, 마우스, 키보드, 또는 디지털 펜(예: 스타일러스 펜)을 포함할 수 있다.
음향 출력 장치(155)는 음향 신호를 전자 장치(101)의 외부로 출력할 수 있다. 음향 출력 장치(155)는, 예를 들면, 스피커(speaker) 또는 리시버(receiver)를 포함할 수 있다. 스피커는 멀티미디어 재생 또는 녹음 재생과 같이 일반적인 용도로 사용될 수 있고, 리시버는 착신 전화를 수신하기 위해 사용될 수 있다. 일 실시예에 따르면, 리시버는 스피커와 별개로, 또는 그 일부로서 구현될 수 있다.
표시 장치(160)는 전자 장치(101)의 외부(예: 사용자)로 정보를 시각적으로 제공할 수 있다. 표시 장치(160)는, 예를 들면, 디스플레이, 홀로그램 장치, 또는 프로젝터 및 해당 장치를 제어하기 위한 제어 회로를 포함할 수 있다. 일 실시예에 따르면, 표시 장치(160)는 터치를 감지하도록 설정된 터치 회로(touch circuitry), 또는 상기 터치에 의해 발생되는 힘의 세기를 측정하도록 설정된 센서 회로(예: 압력 센서(pressure sensor))를 포함할 수 있다.
오디오 모듈(170)은 소리를 전기 신호로 변환시키거나, 반대로 전기 신호를 소리로 변환시킬 수 있다. 일 실시예에 따르면, 오디오 모듈(170)은, 입력 장치(150)를 통해 소리를 획득하거나, 음향 출력 장치(155), 또는 전자 장치(101)와 직접 또는 무선으로 연결된 외부 전자 장치(예: 전자 장치(102))(예: 스피커 또는 헤드폰))를 통해 소리를 출력할 수 있다.
센서 모듈(176)은 전자 장치(101)의 작동 상태(예: 전력 또는 온도), 또는 외부의 환경 상태(예: 사용자 상태)를 감지하고, 감지된 상태에 대응하는 전기 신호 또는 데이터 값을 생성할 수 있다. 일 실시예에 따르면, 센서 모듈(176)은, 예를 들면, 제스처 센서(gesture sensor), 자이로 센서(gyro sensor), 기압 센서(barometer sensor), 마그네틱 센서(magnetic sensor), 가속도 센서(acceleration sensor), 그립 센서(grip sensor), 근접 센서(proximity sensor), 컬러 센서(color sensor)(예: RGB(red, green, blue) 센서), IR(infrared) 센서, 생체 센서(biometric sensor), 온도 센서(temperature sensor), 습도 센서(humidity sensor), 또는 조도 센서(illuminance sensor)를 포함할 수 있다.
인터페이스(177)는 전자 장치(101)의 외부 전자 장치(예: 전자 장치(102))와 직접 또는 무선으로 연결되기 위해 사용될 수 있는 하나 이상의 지정된 프로토콜(protocol)들을 지원할 수 있다. 일 실시예에 따르면, 인터페이스(177)는, 예를 들면, HDMI(high definition multimedia interface), USB(universal serial bus) 인터페이스, SD(secure digital) 카드 인터페이스, 또는 오디오 인터페이스를 포함할 수 있다.
연결 단자(connection terminal)(178)는, 그를 통해서 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 물리적으로 연결될 수 있는 커넥터를 포함할 수 있다. 일 실시예에 따르면, 연결 단자(178)는, 예를 들면, HDMI 커넥터, USB 커넥터, SD 카드 커넥터, 또는 오디오 커넥터(예: 헤드폰 커넥터)를 포함할 수 있다.
햅틱 모듈(haptic module)(179)은 전기적 신호를 사용자가 촉각 또는 운동 감각을 통해서 인지할 수 있는 기계적인 자극(예: 진동 또는 움직임) 또는 전기적인 자극으로 변환할 수 있다. 일 실시예에 따르면, 햅틱 모듈(179)은, 예를 들면, 모터(motor), 압전 소자(piezoelectric element), 또는 전기 자극 장치(electrical stimulation device)를 포함할 수 있다.
카메라 모듈(180)은 정지 영상 및 동영상을 촬영할 수 있다. 일 실시예에 따르면, 카메라 모듈(180)은 하나 이상의 렌즈들, 이미지 센서들, 이미지 시그널 프로세서들, 또는 플래시들을 포함할 수 있다.
전력 관리 모듈(188)은 전자 장치(101)에 공급되는 전력을 관리할 수 있다. 일 실시예에 따르면, 전력 관리 모듈(188)은, 예를 들면, PMIC(power management integrated circuit)의 적어도 일부로서 구현될 수 있다.
배터리(189)는 전자 장치(101)의 적어도 하나의 구성 요소에 전력을 공급할 수 있다. 일 실시예에 따르면, 배터리(189)는, 예를 들면, 재충전 불가능한 1차 전지, 재충전 가능한 2차 전지 또는 연료 전지(fuel cell)를 포함할 수 있다.
통신 모듈(190)은 전자 장치(101)와 외부 전자 장치(예: 전자 장치(102), 전자 장치(104), 또는 서버(108)) 간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(190)은 프로세서(120)(예: 어플리케이션 프로세서)와 독립적으로 운영되고, 직접(예: 유선) 통신 또는 무선 통신을 지원하는 하나 이상의 커뮤니케이션 프로세서를 포함할 수 있다. 일 실시예에 따르면, 통신 모듈(190)은 무선 통신 모듈(192)(예: 셀룰러 통신 모듈, 근거리 무선 통신 모듈, 또는 GNSS(global navigation satellite system) 통신 모듈) 또는 유선 통신 모듈(194)(예: LAN(local area network) 통신 모듈, 또는 전력선 통신 모듈)을 포함할 수 있다. 이들 통신 모듈 중 해당하는 통신 모듈은 제1 네트워크(198)(예: 블루투스, Wi-Fi direct 또는 IrDA(infrared data association) 같은 근거리 통신 네트워크) 또는 제2 네트워크(199)(예: 셀룰러 네트워크, 인터넷, 또는 컴퓨터 네트워크(예: LAN 또는 WAN(wide area network))와 같은 원거리 통신 네트워크)를 통하여 외부 전자 장치와 통신할 수 있다. 이런 여러 종류의 통신 모듈들은 하나의 구성 요소(예: 단일 칩)로 통합되거나, 또는 서로 별도의 복수의 구성 요소들(예: 복수 칩들)로 구현될 수 있다.
무선 통신 모듈(192)은 가입자 식별 모듈(196)에 저장된 가입자 정보(예: 국제 모바일 가입자 식별자(IMSI, international mobile subscriber identity))를 이용하여 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크 내에서 전자 장치(101)를 확인 및 인증할 수 있다.
안테나 모듈(197)은 신호 또는 전력을 외부(예: 외부 전자 장치)로 송신하거나 외부로부터 수신할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 서브스트레이트(예: PCB) 위에 형성된 도전체 또는 도전성 패턴으로 이루어진 방사체를 포함하는 하나의 안테나를 포함할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 복수의 안테나들을 포함할 수 있다. 이런 경우, 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크에서 사용되는 통신 방식에 적합한 적어도 하나의 안테나가, 예를 들면, 통신 모듈(190)에 의하여 상기 복수의 안테나들로부터 선택될 수 있다. 신호 또는 전력은 상기 선택된 적어도 하나의 안테나를 통하여 통신 모듈(190)과 외부 전자 장치 간에 송신되거나 수신될 수 있다. 어떤 실시예에 따르면, 방사체 이외에 다른 부품(예: RFIC)가 추가로 안테나 모듈(197)의 일부로 형성될 수 있다.
상기 구성 요소들 중 적어도 일부는 주변 기기들간 통신 방식(예: 버스, GPIO(general purpose input and output), SPI(serial peripheral interface), 또는 MIPI(mobile industry processor interface))를 통해 서로 연결되고, 신호(예: 명령 또는 데이터)를 상호 간에 교환할 수 있다.
일 실시예에 따르면, 명령 또는 데이터는 제2 네트워크(199)에 연결된 서버(108)를 통해서 전자 장치(101)와 외부의 전자 장치(104) 간에 송신 또는 수신될 수 있다. 전자 장치(102, 104) 각각은 전자 장치(101)와 동일한 또는 다른 종류의 장치일 수 있다.
일 실시예에 따르면, 전자 장치(101)에서 실행되는 동작들의 전부 또는 일부는 외부 전자 장치들(102, 104 또는 108) 중 하나 이상의 외부 장치들에서 실행될 수 있다. 예를 들면, 전자 장치(101)가 어떤 기능이나 서비스를 자동으로, 또는 사용자 또는 다른 장치로부터의 요청에 반응하여 수행해야 할 경우에, 전자 장치(101)는 기능 또는 서비스를 자체적으로 실행시키는 대신에 또는 추가적으로, 하나 이상의 외부 전자 장치들(102, 104)에게 그 기능 또는 그 서비스의 적어도 일부를 수행하라고 요청할 수 있다. 상기 요청을 수신한 하나 이상의 외부 전자 장치들(102, 104)은 요청된 기능 또는 서비스의 적어도 일부, 또는 상기 요청과 관련된 추가 기능 또는 서비스를 실행하고, 그 실행의 결과를 전자 장치(101)로 전달할 수 있다. 전자 장치(101)는 상기 결과를, 그대로 또는 추가적으로 처리하여, 상기 요청에 대한 응답의 적어도 일부로서 제공할 수 있다. 이를 위하여, 예를 들면, 클라우드 컴퓨팅(cloud computing), 분산 컴퓨팅(distributed computing), 또는 클라이언트-서버 컴퓨팅(client-server computing) 기술이 이용될 수 있다.
본 문서에 개시된 다양한 실시예들에 따른 전자 장치(101)는 다양한 형태의 장치가 될 수 있다. 전자 장치(101)는, 예를 들면, 휴대용 통신 장치(예: 스마트 폰), 휴대용 멀티미디어 장치, 휴대용 의료 기기, 카메라, 웨어러블 장치(wearable device), 또는 가전 장치를 포함할 수 있다. 본 문서의 실시예에 따른 전자 장치(101)는 전술한 기기들에 한정되지 않는다.
본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경(modifications), 균등물(equivalents), 또는 대체물(alternatives)을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성 요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다.
본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", “A 또는 B 중 적어도 하나”, "A, B 또는 C", "A, B 및 C 중 적어도 하나" 및 “A, B, 또는 C 중 적어도 하나”와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제1", "제2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성 요소를 다른 해당 구성 요소와 구분하기 위해 사용될 수 있으며, 해당 구성 요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제1) 구성 요소가 다른(예: 제2) 구성 요소에 "기능적으로” 또는 “통신적으로"라는 용어와 함께 또는 이런 용어 없이, “커플드” 또는 “커넥티드”라고 언급된 경우, 그것은 상기 어떤 구성 요소가 상기 다른 구성 요소에 직접적으로(예: 유선으로), 무선으로, 또는 제3 구성 요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어(firmware)로 구현된 유닛(unit)을 포함할 수 있으며, 예를 들면, 로직(logic), 논리 블록(logic block), 부품(component), 또는 회로(circuit)의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 일 실시예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.
본 문서의 다양한 실시예들은 기기(machine)(예: 전자 장치(101))에 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리(136) 또는 외장 메모리(138))에 저장된 하나 이상의 명령어들(instructions)을 포함하는 소프트웨어(예: 프로그램(140))로서 구현될 수 있다. 예를 들면, 기기(예: 전자 장치(101))의 프로세서(예: 프로세서(120))는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러(compiler) 생성된 코드 또는 인터프리터(interpreter)에 의해 실행될 수 있는 코드(code)를 포함할 수 있다. 기기로 읽을 수 있는 저장 매체는, 비일시적(non-transitory) 저장 매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장 매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장 매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
일 실시예에 따르면, 본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: CD-ROM, compact disc read only memory)의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두 개의 사용자 장치들(예: 스마트 폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시예들에 따르면, 상기 기술한 구성 요소들의 각각의 구성 요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시예들에 따르면, 전술한 해당 구성 요소들 중 하나 이상의 구성 요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성 요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성 요소들(예: 모듈 또는 프로그램)은 하나의 구성 요소로 통합될 수 있다. 이런 경우, 통합된 구성 요소는 상기 복수의 구성 요소들 각각의 구성 요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성 요소들 중 해당 구성 요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성 요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱(heuristic)하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.
도 2는 다양한 실시예들에 따른 전자 장치의 기능 모듈의 예를 도시하는 도면이다.
도 2에 도시된 실시예와 같이, 도 2는 다양한 실시 예들에서 전자 장치의 어플리케이션을 업데이트 하는 것과 관련된 기능을 실행(또는 처리)하는 기능 모듈(200)의 예를 나타낼 수 있다. 다양한 실시 예들에서, 기능 모듈(200)은 프로세싱 회로(processing circuitry)를 포함하는 적어도 하나의 프로세서(예: 도 1의 프로세서(120))에 하드웨어 모듈(hardware module)로 포함되거나, 또는 소프트웨어 모듈(software module)로 포함될 수 있다. 일 실시예에 따르면, 도 2에 도시된 실시예에 따른 기능 모듈(200)은 프로세서(120)의 일부로서 구동되거나, 및/또는 프로세서(120)와 독립적으로 운영되는 별도의 하드웨어 구성일 수 있다. 일 실시예에 따르면, 도 2에 도시된 실시예에 따른 기능 모듈(200)은 소프트웨어(예: 도 1의 프로그램(140))일 수 있다. 예를 들어, 소프트웨어 형태의 기능 모듈(200)은 메모리(예: 도 1의 메모리(130))에 명령어(또는 인스트럭션(instruction))들의 형태로 저장되고, 적어도 하나의 프로세서(예: 도 1의 프로세서(120))에 의해 기능 모듈(200)의 동작들이 실행될 수 있다.
도 2를 참조하면, 기능 모듈(200)은 업데이트 모니터(update monitor)(210), 패키지 매니저(package manager)(220), 프로파일 매칭부((230), 또는 프로파일 매니저(240) 중 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 업데이트 모니터(210)는, 전자 장치(101) 내에 설치된 어플리케이션에 대한 업데이트 여부를 모니터 할 수 있다. 일 실시예에 따르면, 업데이트 모니터(210)는 앱스토어 또는 그 밖의 다른 방법(예: ADB(Android debug bridge) 명령어에 의한 인스톨(install))에 적어도 기반하여, 적어도 하나의 어플리케이션에 대한 업데이트(예: 어플리케이션 인스톨 포함) 발생을 감지할 수 있다. 일 실시예에 따르면, 업데이트 모니터(210)는 어플리케이션 업데이트 감지에 기반하여, 통신 회로(예: 도 1의 무선 통신 모듈(192))를 통해, 앱스토어로부터 업데이트 파일(예: 설치 파일(예: apk(Android application package) 파일)을 수신(또는 다운로드)할 수 있다. 일 실시예에 따르면, 어플리케이션(예: 안드로이드 어플리케이션)은 특정 프로그래밍 언어(예: 자바 언어)로 개발될 수 있으며, SDK(software development kit)에 의해 리소스 파일(예: 자바 소스코드, 레이아웃 xml 파일, 이미지 파일, 오디오 파일, 애니메이션, 메뉴, 스타일, 및/또는 컬러 등)을 업데이트 파일(예: apk 파일)로 생성될 수 있다. 업데이트 파일은 안드로이드 패키지(Android package)를 나타내며, 확장자는 “.apk”로 나타낼 수 있다. 예를 들면, 하나의 apk 파일이 하나의 어플리케이션(또는 앱)을 나타내며, 전자 장치(101)에 설치되는 파일일 수 있다.
일 실시예에 따라, 패키지 매니저(220)는 어플리케이션에 대한 검증(verification)을 수행할 수 있다. 일 실시예에 따르면, 패키지 매니저(220)는 업데이트 모니터(210)에 기반하여 수신된 업데이트 파일(예: 업데이트될 대상 어플리케이션에 관련된 업데이트 파일)의 유효성을 체크할 수 있다. 일 실시예에 따르면, 패키지 매니저(220)는 벤딩(vending)에 의한 검증(verification) 및/또는 디바이스 보안(device security)에 의한 검증을 수행할 수 있다. 일 실시예에 따르면, 패키지 매니저(220)는 어플리케이션에 대한 검증이 완료되면, 어플리케이션 업데이트를 위한 요청을 프로파일 매칭부(230)로 전달할 수 있다. 일 실시예에 따르면, 패키지 매니저(220)에서는 어플리케이션 업데이트 요청을, ART(Android RunTime)로 전달된다. 어플리케이션을 인스톨하는 과정에서 어플리케이션에 대한 업데이트가 런타임(예: ART, Android RunTime)으로 요청하기 이전에, 프로파일 매칭부(230)로 전달할 수 있다.
일 실시예에 따라, 프로파일 매칭부(230)는 사용자의 어플리케이션 사용에 따른 사용자 패턴에 따라 기록된(또는 저장된) 이전 프로파일(예: *.prof 파일)과 이전 업데이트 파일(예: 이전 *.apk 파일) 내의 바이트코드(bytecode)(예: 어플리케이션의 실행 파일(예: dex 정보))에 기반하여 현재 업데이트 파일(예: 앱스토어로부터 어플리케이션 업데이트와 관련하여 수신(또는 다운로드)된 업데이트 파일)을 매칭(matching)할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(230)는 어플리케이션에 대한 업데이트가 런타임(예: ART)으로 요청되기 이전에, 사용자의 어플리케이션에 대한 사용 패턴에 따라 기록된(또는 저장된) 이전 프로파일 및 어플리케이션의 이전 업데이트 파일 내 실행 파일(예: dex 정보)과 대상 어플리케이션에 관련된 현재 업데이트 파일을 비교할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(230)는 변경 사항이 없는 메소드(method) 및/또는 클래스(class)에 대해서는 기존 정보를 유지하고, 새로운 메소드 및/또는 클래스에 대해서는 새로운 정보로 추가하고, 기존 정보와 새로운 정보를 매칭하는 작업을 수행할 수 있다. 예를 들어, 프로파일 매칭부(230)는 매칭 작업을 통해 대상 어플리케이션에 관련된 새로운 업데이트 파일(예: 새로운 *.apk 파일)을 생성할 수 있다.
일 실시예에 따르면, 프로파일 매칭부(220)는, 어플리케이션 업데이트에 의해 인스톨되는 과정에서, 프로파일의 빠른 재사용을 위한 툴(profile quick reuse tool)(이하, ‘프로파일 재사용 툴’이라 한다)을 이용하여, 이전 프로파일을 기반으로 어플리케이션의 업데이터를 위한 새로운 프로파일을 생성하여 런타임(예: ART)에 전달할 수 있다. 일 실시예에 따라, 런타임에서는 기존 방식과 같이, 프로파일 매칭부(220)로부터 전달된 새로운 프로파일을 컴파일 하여 네이티브 코드(예: *.odex 및/또는 *.oat 형태) 및 어플리케이션의 클래스 정보에 대한 초기화 이미지(예: *.art)를 생성할 수 있다. 일 실시예에 따라, 네이티브 코드는, 예를 들면, 바이트코드에 대한 컴파일된 코드를 나타낼 수 있으며, 컴파일된 머신코드(machine code)를 포함할 수 있다.
일 실시예에 따르면, 프로파일 매칭부(220)는 이전 업데이트 파일(예: *.apk 파일)의 바이트코드(예: dex 정보)와 사용자가 어플리케이션을 사용한 패턴에 의해 수집되어 있는 이전 프로파일(예: *.prof 파일)을 이용하여 사용자에게 제공할 새로운 프로파일을 제공하기 위한 하나의 방법으로써 임시 프로파일을 생성할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(220)는 임시 프로파일을 기반으로 업데이트할 어플리케이션에서 사용될 새로운 프로파일을 생성할 수 있다. 예를 들어, 프로파일 매칭부(220)는 이전 프로파일과 이전 업데이트 파일 내 바이트코드를 획득(또는 파싱, 추출)할 수 있다. 예를 들어, 프로파일 매칭부(220)는 이전 업데이트 파일 내 바이트코드(예: dex 정보)와 사용자가 사용한 패턴에 의해 수집되어 있는 이전 프로파일을 이용하여 제1 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(220)는 이전 프로파일 및 이전 업데이트 파일의 dex 정보를 기반으로 자주 사용된 핫 메소드(hot method) 및 핫 메소드의 코드베이스 정보를 추출하고, 명령 코드(예: opcode, operation code) 및 아규먼트 객체(예: args)를 기반으로 코드베이스 정보를 분석하여 파싱할 수 있다. 일 실시예에 따라, 프로세서(120)는 파싱된 정보를 기반으로 핫 메소드 및 어플리케이션 진입 시 사용되는 클래스에 대한 제1 클래스 메타데이터를 생성할 수 있다.
일 실시예에 따르면, 프로파일 매칭부(220)는 업데이트할 어플리케이션과 관련된 현재 업데이트 파일(예: 다운로드된 업데이트 파일) 내 바이트코드(예: dex 정보)를 획득(또는 파싱, 추출)할 수 있다. 예를 들어, 프로파일 매칭부(220)는 현재 업데이트 파일의 dex 정보를 이용하여 제2 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(220)는 제1 클래스 메타데이터를 생성하는 동작에 대응하는 동작으로 제2 클래스 메타데이터를 생성할 수 있다.
일 실시예에 따르면, 프로파일 매칭부(220)는 이전 정보(예: 이전 프로파일, 이전 업데이트 파일의 dex 정보) 기반의 제1 클래스 메타데이터와 현재 정보(예: 현재 업데이트 파일의 dex 정보) 기반의 제2 클래스 메타데이터의 비교에 기반하여 업데이트 파일을 매칭(matching)하는 작업을 수행할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(220)는 어플리케이션에 대한 업데이트가 런타임으로 요청되기 이전에, 사용자의 대상 어플리케이션에 대한 사용 패턴에 따라 기록된(또는 저장된) 이전 프로파일 및 어플리케이션의 이전 업데이트 파일 내 dex 정보와 어플리케이션에 관련된 현재 업데이트 파일 내 dex 정보를 비교하여, 변경 사항이 없는 메소드 및/또는 클래스에 대해서는 기존 정보를 유지하고, 새로운 메소드 및/또는 클래스에 대해서는 새로운 정보로 추가하고, 기존 정보와 새로운 정보를 매칭하는 작업을 수행할 수 있다. 예를 들어, 프로파일 매칭부(220)는 제1 클래스 메타데이터와 제2 클래스 메타데이터를 서로 비교하여 일치하는 부분을 식별할 수 있다. 일 실시예에 따르면, 프로파일 매칭부(220)는 제1 클래스 메타데이터와 제2 클래스 메타데이터의 비교에 기반하여 변경 사항이 없는 메소드와 클래스에 대해서는 기존 정보를 유지하여 새로운 프로파일에 포함할 수 있다.
다양한 실시예들에 따르면, 이전 정보(예: 이전 프로파일, 이전 업데이트 파일의 dex 정보)는 외부 서버와 연동하여 저장 및 동기화될 수 있다. 일 실시예에 따르면, 이전 정보는 개인화 정보를 저장하는 외부 서버(예: 클라우드)에 보관(또는 저장) 및 동기화될 수 있다. 일 실시예에 따르면, 전자 장치(101)의 사용자가 새로운 다른 전자 장치를 사용할 시, 외부 서버에 보관된 이전 정보를 활용하여, 어플리케이션의 최초 실행(또는 구동) 시에 활용할 수 있다.
일 실시예에 따르면, 프로파일 매칭부(220)는 클래스 메타데이터의 매칭에 기반하여 새로운 프로파일을 생성할 수 있다. 예를 들어, 프로파일 매칭부(220)는 매칭 작업을 통해 어플리케이션에 관련된 새로운 업데이트 파일(예: 새로운 설치 파일(예: 새로운 *.apk 파일)을 생성하고, 새로운 업데이트 파일로부터 실행 파일(예: dex 정보)을 파싱하여 실제 컴파일에 사용할 새로운 프로파일을 생성할 수 있다.
일 실시예에 따라, 프로파일 매니저(240)는, 새로운 프로파일에 기반하여 컴파일을 수행할 수 있다. 일 실시예에 따르면, 프로파일 매니저(240)는 프로파일 매칭부(230)로부터 전달된 새로운 프로파일에 기반하여 어플리케이션에 대한 업데이트를 위해 런타임(예: ART)으로 컴파일을 요청하고, 런타임에서 새로운 프로파일에 기반한 컴파일을 수행하도록 할 수 있다. 일 실시예에 따라, 프로파일 매니저(240)는 컴파일을 수행하는 결과에 기반하여 산출물을 생성할 수 있다. 일 실시예에 따라, 산출물은, 예를 들면, *.odex, *.vdex, 또는 *.oat와 같은 네이티브 파일(또는 코드)과 *.art와 같은 어플리케이션 클래스 정보에 대한 초기화 이미지를 포함할 수 있다. 예를 들어, 프로파일 매니저(240)는 dex 정보가 컴파일된 *.oat 파일(또는 네이티브 파일)과 *.art(또는 초기화 이미지)를 생성할 수 있다. 일 실시예에 따라, 프로파일 매니저(240)는 컴파일 수행 결과에 기반하여, 산출물 생성에 성공하는 경우, 이전 어플리케이션의 디렉토리를 삭제할 수 있다.
다양한 실시예들에 따르면, 생성된 산출물은 외부 서버와 연동하여 저장 및 관리될 수 있다. 일 실시예에 따르면, 생성된 산출물은 개인화 정보를 저장하는 외부 서버(예: 클라우드)에 보관(또는 저장) 및 동기화될 수 있다. 일 실시예에 따르면, 전자 장치(101)의 사용자가 새로운 다른 전자 장치를 사용할 시, 외부 서버에 보관된 산출물을 활용하여, 어플리케이션의 최초 실행(또는 구동) 시에 활용할 수 있다.
본 개시의 다양한 실시예들에 따른 전자 장치(101)는, 무선 통신을 제공하도록 구성된 통신 회로(예: 도 1의 무선 통신 모듈(192)), 상기 통신 회로(192)와 작동적으로 연결된 적어도 하나의 프로세서(예: 도 1의 프로세서(120)), 및 상기 프로세서(120)와 작동적으로 연결된 메모리(예: 도 1의 메모리(130))를 포함하고, 상기 메모리(130)는, 실행 시에, 상기 프로세서(120)가, 어플리케이션의 업데이트를 감지하고, 상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하고, 상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하고, 상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하도록 하는 인스트럭션들을 저장할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 제1 정보(예: 이전 프로파일 정보, 이전 업데이트 파일의 dex 정보)는, 전자 장치(101)의 내부 메모리(예: 도 1의 메모리(130)) 및/또는 외부 서버에 저장 및 동기화될 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 제1 정보는, 사용자가 상기 어플리케이션에 대한 사용 패턴에 따라 기록된 이전 프로파일과 상기 어플리케이션의 이전 업데이트 파일의 바이트코드(bytecode)에 기반하여 생성하는 제1 메타데이터를 포함할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 제2 정보는, 상기 어플리케이션의 업데이트 시점에서, 상기 통신 회로를 통해, 앱스토어로부터 획득하는 상기 업데이트 파일의 바이트코드에 기반하여 생성하는 제2 메타데이터를 포함할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서(120)가, 상기 어플리케이션의 상기 업데이트 파일에 대한 검증을 수행하도록 할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서(120)가, 상기 어플리케이션에 대한 업데이트가 런타임(runtime)으로 요청되기 이전에, 상기 제1 정보와 상기 제2 정보를 매칭하고, 상기 매칭에 기반하여 일치하는 메소드(method)와 클래스(class)를 유지하도록 할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서(120)가, 상기 제1 정보에 따른 이전 프로파일 및 이전 업데이트 파일 내 바이트코드를 파싱하여 제1 메타데이터를 생성하고, 상기 제2 정보에 따른 상기 업데이트 파일 내 바이트코드를 파싱하여 제2 메타데이터를 생성하고, 상기 제1 메타데이터와 상기 제2 메타데이터를 비교하도록 할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 제1 메타데이터와 상기 제2 메타데이터는 클래스 정보, 메소드 리턴 타입, 메소드 인자, 및 메소드 명령어 중 적어도 하나를 포함할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서(120)가, 상기 제1 메타데이터와 상기 제2 메타데이터의 해시 값(hash value)에 기반하여 상기 비교를 수행하도록 할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서(120)가, 상기 제1 정보와 상기 제2 정보의 매칭에 기반하여 생성된 상기 새로운 프로파일에 기반하여 컴파일을 수행하도록 할 수 있다.
본 개시의 다양한 실시예들에 따르면, 상기 인스트럭션들은, 상기 프로세서(120)가, 상기 새로운 프로파일의 컴파일에 기반하여 네이티브 코드 및 어플리케이션 클래스 정보에 대한 초기화 이미지를 생성하도록 할 수 있다.
이하에서는 다양한 실시예들의 전자 장치(101)의 동작 방법에 대해서 상세하게 설명한다. 다양한 실시예들에 따라, 이하에서 설명하는 전자 장치(101)에서 수행하는 동작들은, 전자 장치(101)의 적어도 하나의 프로세서(예: 프로세싱 회로를 포함하는 적어도 하나의 프로세서로서, 예를 들면, 도 1의 프로세서서(120))(이하, ‘프로세서(120)’라 한다)에 의해 실행될 수 있다. 일 실시예에 따라, 전자 장치(101)에서 수행하는 동작들은, 메모리(예: 도 1의 메모리(130))(이하, ‘메모리(130)’라 한다)에 저장되고, 실행 시에, 프로세서(120)가 동작하도록 하는 인스트럭션들(instructions)에 의해 실행될 수 있다.
도 3은 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
도 3을 참조하면, 동작 301에서, 전자 장치(101)의 프로세서(120)는 어플리케이션의 업데이트를 감지할 수 있다. 일 실시예에 따라, 프로세서(120)는 앱스토어 또는 그 밖의 다른 방법(예: ADB 명령어에 의한 인스톨)에 적어도 기반하여, 적어도 하나의 어플리케이션에 대한 업데이트(예: 어플리케이션 인스톨 포함) 발생을 감지할 수 있다. 일 실시예에 따르면, 프로세서(120)는 어플리케이션 업데이트 감지에 기반하여, 통신 회로(예: 도 1의 무선 통신 모듈(192))를 통해, 앱스토어로부터 업데이트 파일(또는 설치 파일(예: apk 파일))을 수신(또는 다운로드)할 수 있다.
동작 303에서, 프로세서(120)는 어플리케이션의 업데이트 감지에 기반하여, 해당 어플리케이션에 대한 검증(verification)을 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 업데이트될 대상 어플리케이션에 관련된 현재 업데이트 파일(또는 어플리케이션 설치 파일(예: apk 파일))의 유효성을 체크할 수 있다. 예를 들어, 프로세서(120)는 벤딩에 의한 검증 및/또는 디바이스 보안에 의한 검증을 수행할 수 있다.
동작 305에서, 프로세서(120)는 해당 어플리케이션에 대한 검증이 완료되면, 이전 프로파일(예: *.prof 파일)과 이전 업데이트 파일(예: 이전 *.apk 파일) 내의 바이트코드(bytecode)(예: 어플리케이션의 실행 파일(예: dex 정보))에 기반하여 현재 업데이트 파일(예: 앱스토어로부터 어플리케이션 업데이트와 관련하여 수신(또는 다운로드)된 업데이트 파일)을 매칭할 수 있다. 일 실시예에 따르면, 프로세서(120)는 어플리케이션에 대한 업데이트가 런타임(예: ART)으로 요청되기 이전에, 사용자의 어플리케이션에 대한 사용 패턴에 따라 기록된(또는 저장된) 이전 프로파일 및 어플리케이션의 이전 업데이트 파일 내 실행 파일(예: dex 정보)과 대상 어플리케이션에 관련된 현재 업데이트 파일을 비교할 수 있다. 일 실시예에 따르면, 프로세서(120)는 변경 사항이 없는 메소드(method) 및/또는 클래스(class)에 대해서는 기존 정보를 유지하고, 새로운 메소드 및/또는 클래스에 대해서는 새로운 정보로 추가하고, 기존 정보와 새로운 정보를 매칭하는 작업을 수행할 수 있다. 예를 들어, 프로세서(120)는 매칭 작업을 통해 대상 어플리케이션에 관련된 새로운 업데이트 파일(예: 새로운 *.apk 파일)을 생성할 수 있다. 다양한 실시예들에서, 업데이트 파일을 매칭하는 동작과 관련하여 후술하는 도면들을 참조하여 설명된다.
동작 307에서, 프로세서(120)는 대상 어플리케이션에서 사용될 새로운 프로파일을 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 현재 업데이트 파일(예: 새로운 설치 파일(예: 새로운 *.apk 파일)의 바이트코드(예: dex 정보)을 기반으로 실제 컴파일에 사용할 새로운 프로파일을 생성할 수 있다. 다양한 실시예들에서, 새로운 프로파일을 생성하는 동작과 관련하여 후술하는 도면들을 참조하여 설명된다.
도 4는 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
일 실시예에 따라, 도 4는 전자 장치(101)에서 런타임 성능 개선에 기반하여 어플리케이션을 업데이트는 동작의 예를 나타낼 수 있다.
도 4를 참조하면, 동작 401에서, 전자 장치(101)의 프로세서(120)는 어플리케이션의 업데이트를 감지할 수 있다. 일 실시예에 따라, 프로세서(120)는 앱스토어 또는 그 밖의 다른 방법(예: ADB 명령어에 의한 인스톨)에 적어도 기반하여, 적어도 하나의 어플리케이션에 대한 업데이트(예: 어플리케이션 인스톨 포함) 발생을 감지할 수 있다.
동작 403에서, 프로세서(120)는 어플리케이션의 업데이트 감지에 기반하여, 업데이트할 대상 어플리케이션이 저장될 임시(temp, temporary) 디렉토리(directory)(또는 폴더(folder))를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 대상 어플리케이션에 관련된 업데이트 파일(또는 설치 파일(예: *.apk 파일))이 저장될 임시 디렉토리를 생성할 수 있다. 일 실시예에 따라, 프로세서(120)는 임시 디렉토리를 생성할 때, 임시 디렉토리의 디렉토리 이름을 임의적으로(또는 랜덤(random)하게) 생성하여 임시 디렉토리에 대한 디렉토리 이름으로 설정할 수 있다.
동작 405에서, 프로세서(120)는 임시 디렉토리에 업데이트 파일을 다운로드 할 수 있다.
동작 407에서, 프로세서(120)는 다운로드된 업데이트 파일에 대한 검증을 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 대상 어플리케이션에 관련된 업데이트 파일(예: apk 파일))의 유효성을 체크할 수 있다. 예를 들어, 프로세서(120)는 벤딩에 의한 검증 및/또는 디바이스 보안에 의한 검증을 수행할 수 있다.
동작 407에서, 프로세서(120)는 업데이트 파일의 유효성 체크 결과에 기반하여, 업데이트 파일이 유효하지 않은 것으로 판단하면(예: 업데이트 파일에 대한 검증 실패)(예: 동작 407의 ‘실패’), 동작 409에서, 임시 디렉토리를 삭제할 수 있다. 일 실시예에 따르면, 프로세서(120)는 임시 디렉토리를 삭제함에 따라 다운로드된 업데이트 파일도 함께 삭제(또는 제거)할 수 있다.
동작 407에서, 프로세서(120)는 업데이트 파일의 유효성 체크 결과에 기반하여, 업데이트 파일이 유효한 것으로 판단하면(예: 업데이트 파일에 대한 검증 성공)(예: 동작 407의 ‘성공’), 동작 411에서, 임시 디렉토리에 대한 디렉토리 이름을 변경할 수 있다. 일 실시예에 따르면, 프로세서(120)는 임시 디렉토리에 설정된 디렉토리 이름을 대상 어플리케이션과 연관된 이름(예: 어플리케이션 이름)으로 변경할 수 있다. 예를 들면, 프로세서(120)는 임시 디렉토리를 업데이트할 어플리케이션의 실질적 디렉토리로 생성할 수 있다.
동작 413에서, 프로세서(120)는 이전 프로파일과 바이트코드에 기반하여 클래스 메타데이터(class metadata)를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 이전 프로파일(예: *.prof 파일)과 어플리케이션과 관련된 이전 업데이트 파일(예: 이전 *.apk 파일) 내 바이트코드(예: dex 정보)에 기반하여 제1 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 어플리케이션과 관련된 현재 업데이트 파일(예: 새로운 *.apk 파일) 내 바이트코드(예: dex 정보)에 기반하여 제2 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 이전 프로파일(예: *.prof 파일)과 어플리케이션과 관련된 이전 업데이트 파일(예: 이전 *.apk 파일)은 전자 장치(101)의 내부 메모리(예: 도 1의 메모리(130)) 및/또는 외부 서버에 저장 및 동기화될 수 있다.
동작 415에서, 프로세서(120)는 클래스 메타데이터에 기반하여 업데이트할 어플리케이션을 위한(또는 대상 어플리케이션에서 사용될) 새로운 프로파일을 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 제1 클래스 메타데이터와 제2 클래스 메타데이터의 비교에 기반하여 업데이트 파일을 매칭(matching)하는 작업을 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 어플리케이션에 대한 업데이트가 런타임으로 요청되기 이전에, 사용자의 어플리케이션에 대한 사용 패턴에 따라 기록된(또는 저장된) 이전 프로파일 및 어플리케이션의 이전 업데이트 파일 내 dex 정보와 어플리케이션에 관련된 현재 업데이트 파일 내 dex 정보를 비교하여, 변경 사항이 없는 메소드 및/또는 클래스에 대해서는 기존 정보를 유지하고, 새로운 메소드 및/또는 클래스에 대해서는 새로운 정보로 추가하고, 기존 정보와 새로운 정보를 매칭하는 작업을 수행할 수 있다. 예를 들어, 프로세서(120)는 매칭 작업을 통해 대상 어플리케이션에 관련된 새로운 업데이트 파일(예: 새로운 설치 파일(예: *.apk 파일))을 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 새로운 업데이트 파일로부터 바이트코드(예: dex 정보)를 파싱하고, 파싱된 바이트코드를 기반으로 실제 컴파일에 사용할 새로운 프로파일을 생성할 수 있다.
동작 417에서, 프로세서(120)는 새로운 프로파일에 기반하여 컴파일을 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 새로운 프로파일에 기반하여 대상 어플리케이션에 대한 업데이트를 위해 런타임으로 컴파일을 요청하고, 런타임에서 새로운 프로파일에 기반한 컴파일을 수행할 수 있다.
동작 419에서, 프로세서(120)는 컴파일을 수행하는 결과에 기반하여 산출물의 생성 여부를 판단할 수 있다. 일 실시예에 따라, 산출물은, 예를 들면, *.odex, *.vdex, 또는 *.oat와 같은 네이티브 파일(또는 코드)과 *.art와 같은 어플리케이션 클래스 정보에 대한 초기화 이미지를 포함할 수 있다. 일 실시예에 따르면, 프로세서(120)는 dex 파일이 컴파일된 *.oat 파일(또는 네이티브 파일)과 *.art(또는 초기화 이미지)가 생성되는지 여부를 식별할 수 있다.
동작 419에서, 프로세서(120)는 컴파일 수행 결과에 기반하여, 산출물이 생성되지 않은 경우(예: 산출물 생성 실패)(예: 동작 419의 ‘실패’), 동작 409로 진행하여, 임시 디렉토리를 삭제할 수 있다.
동작 419에서, 프로세서(120)는 컴파일 수행 결과에 기반하여, 산출물이 생성된 경우(예: 산출물 생성 성공)(예: 동작 419의 ‘성공’), 동작 421에서, 이전 어플리케이션의 디렉토리를 삭제할 수 있다.
도 5는 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
일 실시예에 따라, 도 5는 전자 장치(101)에서 새로운 프로파일을 생성하는 동작의 예를 나타낼 수 있다. 예를 들면, 도 5에 도시된 실시예는, 도 4에 도시된 실시예의 동작 413과 동작 415에 관련된 상세 동작을 포함할 수 있다.
도 5를 참조하면, 도 4에 도시된 실시예의 동작 411에서, 프로세서(120)는 임시 디렉토리에 대한 디렉토리 이름을 변경할 수 있다. 일 실시예에 따르면, 프로세서(120)는 임시 디렉토리에 설정된 디렉토리 이름을 대상 어플리케이션과 연관된 이름(예: 어플리케이션 이름)으로 변경할 수 있다. 예를 들면, 프로세서(120)는 임시 디렉토리를 대상 어플리케이션의 디렉토리로 생성할 수 있다.
동작 501에서, 프로세서(120)는 이전 프로파일과 이전 업데이트 파일 내 바이트코드(예: 자바 바이트코드(Java bytecode))를 획득(또는 파싱, 추출)할 수 있다. 동작 503에서, 프로세서(120)는 이전 프로파일과 이전 업데이트 파일에 기반하여 제1 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 이전 프로파일(예: *.prof 파일)과 어플리케이션과 관련된 이전 업데이트 파일 내 바이트코드(예: dex 정보)에 기반하여 제1 클래스 메타데이터를 생성할 수 있다. 예를 들어, 프로세서(120)는 이전 업데이트 파일의 dex 정보와 사용자가 사용한 패턴에 의해 수집되어 있는 이전 프로파일을 이용하여 제1 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 이전 프로파일 및 이전 업데이트 파일의 dex 정보를 기반으로 자주 사용된 핫 메소드(hot method) 및 핫 메소드의 코드베이스 정보를 추출하고, 명령 코드(예: opcode) 및 아규먼트 객체(예: args)를 기반으로 코드베이스 정보를 분석하여 파싱할 수 있다. 일 실시예에 따라, 프로세서(120)는 파싱된 정보를 기반으로 핫 메소드 및 어플리케이션 진입 시 사용되는 클래스에 대한 제1 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 제1 클래스 메타데이터는 변하지 않는 성질의(또는 불변성) 프로파일(예: invariant profile) 또는 메타데이터(예: invariant metadata)일 수 있다.
동작 511에서, 프로세서(120)는 업데이트될 어플리케이션과 관련된 현재 업데이트 파일(예: 다운로드된 업데이트 파일) 내 바이트코드(예: 자바 바이트코드)를 획득(또는 파싱, 추출)할 수 있다. 동작 513에서, 프로세서(120)는 현재 업데이트 파일에 기반하여 제2 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 대상 어플리케이션과 관련된 현재 업데이트 파일 내 바이트코드(예: dex 정보)에 기반하여 제2 클래스 메타데이터를 생성할 수 있다. 예를 들어, 프로세서(120)는 현재 업데이트 파일의 dex 정보를 이용하여 제2 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 전술한 제1 클래스 메타데이터를 생성하는 동작에 대응하는 동작으로 제2 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 제2 클래스 메타데이터는 임시 프로파일(예: temp profile) 또는 임시 메타데이터(temp metadata)일 수 있다.
일 실시예에 따르면, 동작 501 및 동작 503과 동작 511 및 동작 513의 동작들은, 도 5에 도시된 실시예에서, 병렬적으로, 순차적으로, 또는 역순차적으로 수행될 수 있다.
동작 525에서, 프로세서(120)는 클래스 메타데이터를 비교할 수 있다. 일 실시예에 따르면, 프로세서(120)는 이전 정보(예: 이전 프로파일, 이전 업데이트 파일의 dex 정보) 기반의 제1 클래스 메타데이터와 현재 정보(예: 현재 업데이트 파일의 dex 정보) 기반의 제2 클래스 메타데이터의 비교에 기반하여 업데이트 파일을 매칭(matching)하는 작업을 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 대상 어플리케이션에 대한 업데이트가 런타임으로 요청되기 이전에, 사용자의 대상 어플리케이션에 대한 사용 패턴에 따라 기록된(또는 저장된) 이전 프로파일 및 어플리케이션의 이전 업데이트 파일 내 dex 정보와 어플리케이션에 관련된 현재 업데이트 파일 내 dex 정보를 비교하여, 변경 사항이 없는 메소드 및/또는 클래스에 대해서는 기존 정보를 유지하고, 새로운 메소드 및/또는 클래스에 대해서는 새로운 정보로 추가하고, 기존 정보와 새로운 정보를 매칭하는 작업을 수행할 수 있다. 일 실시예에 따르면, 프로세서(120)는 프로세서(120)는 이전 업데이트 파일로부터 dex 정보를 읽고 파싱하고, 파싱된 dex 정보로부터 메소드에 대한 제1 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 현재 업데이트 파일로부터 dex 정보를 읽고 파싱하고, 파싱된 dex 정보에 기반하여 메소드에 대한 제2 클래스 메타데이터를 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 제1 클래스 메타데이터와 제2 클래스 메타데이터를 서로 비교하여 일치하는 부분을 식별할 수 있다. 일 실시예에 따르면, 프로세서(120)는 제1 클래스 메타데이터와 제2 클래스 메타데이터의 비교에 기반하여 변경 사항이 없는 메소드와 클래스에 대해서는 기존 정보를 유지할 수 있다.
동작 527에서, 프로세서(120)는 클래스 메타데이터의 매칭에 기반하여 새로운 프로파일을 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 제1 클래스 메타데이터와 제2 클래스 메타데이터의 비교에 기반하여 일치하는 메소드와 클래스를 포함하여 새로운 프로파일을 생성할 수 있다. 일 실시예에 따르면, 프로세서(120)는 매칭 작업을 통해 대상 어플리케이션에 관련된 새로운 업데이트 파일(예: 새로운 설치 파일(예: 새로운 *.apk 파일)을 생성하고, 새로운 업데이트 파일로부터 실행 파일(예: dex 정보)을 파싱하여 실제 컴파일에 사용할 새로운 프로파일을 생성할 수 있다.
동작 529에서, 프로세서(120)는 생성된 새로운 프로파일을 압축할 수 있다. 일 실시예에 따르면, 프로세서(120)는 새로운 프로파일을 어플리케이션의 공통 프로파일(예: *.dm 파일)로 압축할 수 있다. 일 실시예에 따라, 공통 프로파일(예: *.dm 파일)은 전자 장치(101)에서 해당 어플리케이션과 관련하여 추출된 정보에 대응하는 파일 이름으로 압축될 수 있다.
도 6은 다양한 실시예들에 따른 전자 장치의 동작 방법을 도시하는 흐름도이다.
일 실시예에 따라, 도 6은 전자 장치(101)에서 새로운 프로파일에 기반하여 컴파일을 수행하기 위한 동작의 예를 나타낼 수 있다. 예를 들면, 도 6에 도시된 실시예는, 도 4에 도시된 실시예의 동작 417에 관련된 상세 동작을 포함할 수 있다.
도 6을 참조하면, 도 5에 도시된 실시예의 동작 529에서, 프로세서(120)는 새로운 프로파일을 어플리케이션의 공통 프로파일(예: *.dm 파일)로 압축하여 압축 파일을 생성할 수 있다.
동작 601에서, 프로세서(120)는 어플리케이션과 관련하여 기존 공통 프로파일(예: 기존 *.dm 파일)의 존재 여부를 판단할 수 있다. 예를 들어, 프로세서(120)는 새로운 프로파일에 기반하여 압축된 새로운 공통 파일(예: 새로운 *.dm 파일)과 동일한 파일 이름을 가지는 기존 공통 프로파일이 있는지 여부를 판단할 수 있다.
동작 601에서, 프로세서(120)는 판단하는 결과에 기반하여, 기존 공통 프로파일(예: 기존 *.dm 파일)이 존재하면(예: 동작 601의 ‘YES’), 동작 603에서, 기존 공통 프로파일 내의 이전 프로파일(예: *.prof 파일)을 복사할 수 있다.
동작 601에서, 프로세서(120)는 판단하는 결과에 기반하여, 기존 공통 프로파일(예: 기존 *.dm 파일)이 존재하지 않으면(예: 동작 601의 ‘NO’), 동작 605에서, 이전 프로파일(예: *.prof 파일)을 삭제할 수 있다.
동작 607에서, 프로세서(120)는 어플리케이션에 대한 컴파일을 수행할 수 있다. 일 실시예에 따르면, 대상 어플리케이션을 위한 새로운 프로파일에 기반하여 런타임으로 컴파일을 요청하고, 런타임에서 새로운 프로파일에 기반한 컴파일을 수행할 수 있다. 예를 들면, 프로세서(120)는 런타임을 통해, 새로운 프로파일에 대해 지정된 컴파일 방식(예: AOT 컴파일)을 사용하여 네이티브 코드(예: *.odex 및/또는 *.oat), 및 어플리케이션 클래스 정보에 대한 초기화 이미지(예: *.art)를 생성할 수 있다. 일 실시예에 따라, 네이티브 코드는, 예를 들면, 바이트코드에 대한 컴파일된 코드를 나타낼 수 있으며, 컴파일된 머신코드(machine code)를 포함할 수 있다.
도 7은 다양한 실시예들에 따른 전자 장치에서 이전 프로파일에 기반하여 새로운 프로파일을 생성하는 예를 설명하기 위한 도면이다. 도 8은 다양한 실시예들에 따른 전자 장치에서 생성하는 메타데이터의 예를 설명하기 위한 도면이다. 도 9는 다양한 실시예들에 따른 전자 장치에서 메타데이터를 매칭하는 예를 설명하기 위한 도면이다.
도 7에 도시된 실시예에서는, 도 5를 참조한 설명 부분에서 설명한 바와 같이, 생성된 클래스 메타데이터(예: 제1 클래스 메타데이터, 제2 클래스 메타데이터)의 비교에 기반하여 새로운 프로파일을 생성하는 동작을 나타낼 수 있다. 예를 들어, 본 개시의 다양한 실시예들에 따른 전자 장치(101)는 프로파일의 빠른 재사용을 위한 프로파일 재사용 툴을 포함할 수 있으며, 어플리케이션 업데이트에 따라 대상 어플리케이션에 대한 인스톨(install) 과정에서 프로파일 재사용 툴을 사용하여 이전 프로파일을 기반으로 업데이트할 대상 어플리케이션을 위한 새로운 프로파일을 생성하여 런타임에 전달할 수 있다. 예를 들어, 전자 장치(101)는 어플리케이션 업데이트(어플리케이션 인스톨 포함)가 발생하면, 패키지 매니저(예: 도 2의 패키지 매니저(220))(예: 패키지 매니저 서비스(PacakgeManagerService) 모듈)을 통해 어플리케이션에 대한 검증을 수행할 수 있다. 전자 장치(101)는 어플리케이션에 대한 검증이 완료되면, 어플리케이션 업데이트를 위한 요청이 런타임(예: ART)으로 전달될 수 있는데, 본 개시의 다양한 실시예들에서는, 어플리케이션을 인스톨하는 과정에서 어플리케이션에 대한 업데이트가 런타임으로 요청되기 이전에, 프로파일 재사용 툴을 통해, 사용자 패턴에 따라 기록된 이전 프로파일 및 어플리케이션의 이전 업데이트 파일 내 dex 정보와 현재 업데이트 파일 내 dex 정보를 비교하는 작업을 수행할 수 있다. 일 실시예에 따르면, 런타임에서는 프로파일 재사용 툴로부터 전달된 새로운 프로파일을 컴파일 하여 네이티브 코드(예: *.odex 및/또는 *.oat 형태) 및 어플리케이션 클래스 정보에 대한 초기화 이미지(예: *.art)를 생성할 수 있다.
도 7을 참조하면, 전자 장치(101)는 어플리케이션의 업데이트 이전에 가지고 있던 어플리케이션의 이전 프로파일(710) 및 어플리케이션의 이전 업데이트 파일(예: 설치 파일(예: 이전 *.apk 파일)) 내의 자바 바이트코드(예: dex 정보)(720)을 기반으로 제1 클래스 메타데이터(760)를 생성할 수 있다. 예를 들어, 전자 장치(101)는 이전 프로파일(710)과 관련된 메소드 식별자(예: method id) 및 플래그(flags)에 기반한 클래스 정보와 이전 업데이트 파일 내 자바 바이트코드(720)의 메소드 데이터(예: 해시 값(hash value)) 및 메소드 식별자에 기반한 클래스 정보를 기반으로 이전 정보(예: 이전 프로파일(710), 이전 업데이트 파일의 자바 바이트코드(720))에 대한 메소드 그룹핑(730)을 수행할 수 있다. 일 실시예에 따라, 전자 장치(101)는 메소드 그룹핑(730)에 의해, 어플리케이션에 관련된 이전 정보를 기반으로 하는 제1 클래스 메타데이터(760)를 생성할 수 있다. 일 실시예에 따르면, 제1 클래스 메타데이터(760)는 이전 정보를 기반으로 하는 변하지 않는 성질의(또는 불변성) 프로파일(예: invariant profile) 또는 메타데이터(예: invariant metadata)일 수 있다.
전자 장치(101)는 어플리케이션의 업데이트 요청에 따라 획득된 어플리케이션의 현재 업데이트 파일(예: 현재 *.apk 파일)) 내의 자바 바이트코드(예: dex 정보)(740)을 기반으로 제2 클래스 메타데이터(770)를 생성할 수 있다. 예를 들어, 전자 장치(101)는 현재 업데이트 파일 내 자바 바이트코드(740)의 메소드 데이터(예: 해시 값) 및 메소드 식별자에 기반한 클래스 정보를 기반으로 현재 정보(예: 현재 업데이트 파일의 자바 바이트코드(740))에 대한 메소드 그룹핑(750)을 수행할 수 있다. 일 실시예에 따라, 전자 장치(101)는 메소드 그룹핑(750)에 의해, 어플리케이션에 관련된 현재 정보를 기반으로 하는 제2 클래스 메타데이터(770)를 생성할 수 있다. 일 실시예에 따르면, 제2 클래스 메타데이터(770)는 현재 정보를 기반으로 하는 임시 프로파일(예: temp profile) 또는 임시 메타데이터(temp metadata)일 수 있다.
일 실시예에 따르면, 전자 장치(101)는 이전 정보에 기반한 제1 클래스 메타데이터(760)와 제2 클래스 메타데이터(770)의 비교(또는 매칭) 시간을 줄이기 위해 해시 값을 이용할 수 있으며, 메소드 식별자(예: 클래스 이름, 리턴 타입, 및/또는 메소드 이름)는 클래스에 따른 메소드의 그룹핑을 위해 이용할 수 있다. 일 실시예에 따른 메타데이터(예: 제1 클래스 메타데이터(760), 제2 클래스 메타데이터(770))의 구조는 도 8의 예시와 같이 나타낼 수 있다.
도 8을 참조하면, 메타데이터는 클래스 정보(810), 메소드 리턴 타입(820), 메소드 인자(830), 및 메소드 명령어(840)와 같은 적어도 하나의 필드를 포함할 수 있다. 일 실시예에 따르면, 클래스 정보(810)는 메소드가 가지는 클래스의 패키지 개수(815)에 관한 정보를 포함할 수 있다. 일 실시예에 따르면, 메소드 리턴 타입(820)은 메소드 리턴 타입의 패키지 개수(821), 어레이(array) 여부(823), 및/또는 타입(예: 오브젝트(object) 타입 또는 원시(primitive) 타입)에 관한 정보를 포함할 수 있다. 일 실시예에 따르면, 메소드 인자(830)는 인자 정보(835)를 포함할 수 있다. 예를 들어, 인자 정보(835)는 메소드 인자의 개수, 인자의 패키지 개수, 어레이 여부, 또는 인자 타입(예: 오브젝트 타입 또는 원시 타입)에 관한 정보를 포함할 수 있다. 일 실시예에 따르면, 메소드 명령어(840)는 명령어에 관한 정보(예: 명령 코드(opcode), 아규먼트 객체(args))를 포함할 수 있다. 일 실시예에 따라, 아래 <표 1>과 <표 2>는 메소드(예: <표 1>)와 메소드에 대한 메타데이터(예: <표 2>)의 예가 개시된다.
public class MainActivity extends Actvity
{
protected void onCreate(Bundle paramBundle)
{
super.onCreate(paramBundle);
...
}
}
.class public Ltest/hals/test/myapplication/MainActivity < 메소드가 가진 클래스의 패키지 개수는 5개
.super Landroid/support/v7/app/AppCompatActivity; (not used)
protected void onCreate(Bundle paramBundle) - .method protected onCreate(Landroid/os/Bundle;)V
{
Method return type:
V - void, 메소드 리턴 타입의 패키지 개수는 1개
V is not array;
V is primitive;
Method arguments:
메소드 인자 개수는 1개
Bundle paramBundle - Landroid/os/Bundle;
인자의 패키지 개수는 3개
It is not array;
Argument type is object.
}
일 실시예에 따르면, 전자 장치(101)는 순환 중복 검사(CRC, cyclic redundancy check)(예: CRC-32)를 통해 도 8에 도시된 실시예와 같은 메타데이터의 정보를 기반으로 해시 값을 생성할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 메타데이터를 매칭하는 동작에서 해시 값을 이용할 수 있다. 이의 예시가 도 9에 도시된다.
도 7 및 도 9를 참조하면, 전자 장치(101)는 이전 정보(예: 이전 프로파일, 이전 업데이트 파일의 dex 정보) 기반의 제1 클래스 메타데이터(760)와 현재 정보(예: 현재 업데이트 파일의 dex 정보) 기반의 제2 클래스 메타데이터(770)를 비교(또는 매칭)(780)할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 제1 클래스 메타데이터(760)의 제1 해시 값과 제2 클래스 메타데이터(770)의 제2 해시 값을 사용하여 클래스 메타데이터의 비교 시간을 단축할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 제1 클래스 메타데이터(760)와 제2 클래스 메타데이터(770)를 서로 비교(780)하여 일치하는 부분(예: 메소드)을 식별할 수 있다. 예를 들어, 전자 장치(101)는 메타데이터의 내용을 비교하여 동일 메소드 여부를 확인할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 제1 클래스 메타데이터(760)와 제2 클래스 메타데이터(770)의 비교에 기반하여 변경 사항이 없는 메소드(예: 일치하는 메소드(910))와 클래스에 대해서는 기존 정보를 유지할 수 있다. 예를 들어, 전자 장치(101)는 어플리케이션에 대한 업데이트가 런타임으로 요청되기 이전에, 제1 클래스 메타데이터(760)와 제2 클래스 메타데이터(770)를 비교하여, 변경 사항이 없는 메소드(예: 일치하는 메소드(910)) 및/또는 클래스에 대해서는 기존 정보를 유지하고, 새로운 메소드 및/또는 클래스에 대해서는 새로운 정보로 추가하고, 기존 정보와 새로운 정보를 매칭하는 작업을 수행할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 제1 클래스 메타데이터(760)와 제2 클래스 메타데이터(770) 기반의 매칭하는 작업의 결과로, 새로운 프로파일(예: new ART profile)(790)을 생성할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 매칭 작업을 통해 어플리케이션에 관련된 새로운 설치 파일(예: 새로운 *.apk 파일)을 생성할 수 있고, 새로운 설치 파일로부터 자바 바이트코드(예: dex 파일)를 파싱하여, 실제 컴파일에서 사용할 새로운 프로파일(790)을 생성할 수 있다.
일 실시예에 따르면, 전자 장치(101)는 생성된 새로운 프로파일(790)에 대해 dex2oat 실행 파일을 통해 컴파일할 수 있으며, 그 결과로, 추가적인 사용 없이, 어플리케이션의 업데이트 이후에, 업데이트된 어플리케이션에 대한 추가적인 사용 없이도, 바로 사용자가 이전에 사용했던 패턴에 따라 적용된 런타임 성능으로 어플리케이션을 사용하도록 사용자에게 제공할 수 있다.
도 10, 도 11a, 및 도 11b는 다양한 실시예들에 따른 전자 장치에서 메타데이터 생성을 위한 난독화 동작을 설명하기 위한 도면들이다.
일 실시예에 따라, 도 10, 도 11a, 및 도 11b는 전자 장치(101)에서 메타데이터를 위한 난독화 코드를 생성하는 예를 나타낼 수 있다. 예를 들면, 도 10, 도 11a, 및 도 11b에 도시된 실시예는, 도 7, 도 8, 및 도 9에 도시된 실시예의 메타데이터를 위한 난독화 프로세스의 예를 나타낼 수 있다.
도 10, 도 11a, 및 도 11b를 참조하면, 전자 장치(101)는 프로가드(progurd)를 통해 난독화 프로세스를 수행할 수 있다. 일 실시예에 따르면, 프로가드(progurd)는 코드의 난독화(예: code obfuscation)를 위한 툴을 나타내며, 변수, 메소드, 및/또는 클래스의 이름을 의미없는 이름으로 짧게 변경하고, 불필요한 코드를 찾아서 제거하여 최적화 할 수 있다.
예를 들어, 도 10의 도시된 실시예에서와 같이, 소스 코드(1010)(예: 자바 컴파일러를 통해 생성된 자바 바이트코드)의 난독화를 통해 변수, 메소드, 및/또는 클래스의 이름이 변경되고, 일부 코드를 제공하는 결과로써 최적화된(optimized) 코드(1020)(예: 자바 바이트코드)를 생성할 수 있다. 일 실시예에 따르면, 도 10에 도시된 최적화된 코드(1020)(예: 난독화된 바이트코드)에 기반하여 도 8에 도시된 실시예와 같은 메타데이터를 생성할 수 있다.
일 실시예에 따라, 도 11a에 도시된 실시예는 동일한 메소드 이름(예: app-v1/smali/X/00X.smali)을 가지지만, 난독화로 인하여 실제로 다른 메소드가 생성되는 예를 나타낼 수 있다. 예를 들어, “.class public final LX/00X;”가 “.class public abstract LX/00X;”와 같이 다른 메소드가 생성될 수 있다.
일 실시예에 따라, 도 11b에 도시된 실시예는 동일한 내용의 메소드를 가지지만, 난독화로 인하여 메소드 이름이 변경되는 예를 나타낼 수 있다. 예를 들어, “app-v1/smali/X/00X.smali”가 “app-v2/smali/X/00Y.smali”와 같이 변경될 수 있다.
본 발명의 다양한 실시예들에 따른 전자 장치(101)에서 수행하는 동작 방법은, 어플리케이션의 업데이트를 감지하는 동작, 상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하는 동작, 상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하는 동작, 상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하는 동작을 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 제1 정보는, 사용자가 상기 어플리케이션에 대한 사용 패턴에 따라 기록된 이전 프로파일과 상기 어플리케이션의 이전 업데이트 파일의 바이트코드(bytecode)에 기반하여 생성하는 제1 메타데이터를 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 제2 정보는, 상기 어플리케이션의 업데이트 시점에서, 상기 통신 회로를 통해, 앱스토어로부터 획득하는 상기 업데이트 파일의 바이트코드에 기반하여 생성하는 제2 메타데이터를 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 업데이트 파일을 획득하는 동작은, 상기 어플리케이션의 상기 업데이트 파일에 대한 검증을 수행하는 동작을 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 제1 정보와 상기 제2 정보를 매칭하는 동작은, 상기 어플리케이션에 대한 업데이트가 런타임(runtime)으로 요청되기 이전에, 상기 제1 정보와 상기 제2 정보를 매칭하는 동작, 상기 매칭에 기반하여 일치하는 메소드(method)와 클래스(class)를 유지하는 동작을 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 제1 정보와 상기 제2 정보를 매칭하는 동작은, 상기 제1 정보에 따른 이전 프로파일 및 이전 업데이트 파일 내 바이트코드를 파싱하여 제1 메타데이터를 생성하는 동작, 상기 제2 정보에 따른 상기 업데이트 파일 내 바이트코드를 파싱하여 제2 메타데이터를 생성하는 동작, 상기 제1 메타데이터와 상기 제2 메타데이터를 비교하는 동작을 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 제1 메타데이터와 상기 제2 메타데이터는 클래스 정보, 메소드 리턴 타입, 메소드 인자, 및 메소드 명령어 중 적어도 하나를 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 비교하는 동작은, 상기 제1 메타데이터와 상기 제2 메타데이터의 해시 값(hash value)에 기반하여 비교하는 동작을 포함할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 제1 정보와 상기 제2 정보의 매칭에 기반하여 생성된 상기 새로운 프로파일에 기반하여 컴파일 할 수 있다.
본 발명의 다양한 실시예들에 따르면, 상기 새로운 프로파일의 컴파일에 기반하여 네이티브 코드 및 어플리케이션 클래스 정보에 대한 초기화 이미지를 생성하는 동작을 포함할 수 있다.
본 명세서와 도면에 개시된 본 개시의 다양한 실시예들은 본 개시의 기술 내용을 쉽게 설명하고 본 개시의 이해를 돕기 위해 특정 예를 제시한 것일 뿐이며, 본 개시의 범위를 한정하고자 하는 것은 아니다. 따라서 본 개시의 범위는 여기에 개시된 실시예들 이외에도 본 개시의 기술적 사상을 바탕으로 도출되는 모든 변경 또는 변형된 형태가 본 개시의 범위에 포함되는 것으로 해석되어야 한다.
101: 전자 장치
120: 프로세서
130: 메모리
200: 기능 모듈
210: 업데이트 모니터
220: 패키지 매니저
230: 프로파일 매칭부
240: 프로파일 매니저
710: 이전 프로파일
720: 이전 업데이트 파일 내의 자바 바이트코드
740: 현재 업데이트 파일 내의 자바 바이트코드
760: 제1 클래스 메타데이터
770: 제2 클래스 메타데이터
790: 새로운 프로파일

Claims (20)

  1. 전자 장치에 있어서,
    무선 통신을 제공하도록 구성된 통신 회로;
    상기 통신 회로와 작동적으로 연결된 적어도 하나의 프로세서; 및
    상기 프로세서와 작동적으로 연결된 메모리를 포함하고,
    상기 메모리는, 실행 시에, 상기 프로세서가,
    어플리케이션의 업데이트를 감지하고,
    상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하고,
    상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하고,
    상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하도록 하는 인스트럭션들을 저장하는 전자 장치.
  2. 제1항에 있어서,
    상기 제1 정보는, 사용자가 상기 어플리케이션에 대한 사용 패턴에 따라 기록된 이전 프로파일과 상기 어플리케이션의 이전 업데이트 파일의 바이트코드(bytecode)에 기반하여 생성하는 제1 메타데이터를 포함하는 전자 장치.
  3. 제1항에 있어서,
    상기 제2 정보는, 상기 어플리케이션의 업데이트 시점에서, 상기 통신 회로를 통해, 앱스토어로부터 획득하는 상기 업데이트 파일의 바이트코드에 기반하여 생성하는 제2 메타데이터를 포함하는 전자 장치.
  4. 제1항에 있어서, 상기 인스트럭션들은, 상기 프로세서가,
    상기 어플리케이션의 상기 업데이트 파일에 대한 검증을 수행하도록 하는 전자 장치.
  5. 제1항에 있어서, 상기 인스트럭션들은, 상기 프로세서가,
    상기 어플리케이션에 대한 업데이트가 런타임(runtime)으로 요청되기 이전에, 상기 제1 정보와 상기 제2 정보를 매칭하고, 상기 매칭에 기반하여 일치하는 메소드(method)와 클래스(class)를 유지하도록 하는 전자 장치.
  6. 제5항에 있어서, 상기 인스트럭션들은, 상기 프로세서가,
    상기 제1 정보에 따른 이전 프로파일 및 이전 업데이트 파일 내 바이트코드를 파싱하여 제1 메타데이터를 생성하고,
    상기 제2 정보에 따른 상기 업데이트 파일 내 바이트코드를 파싱하여 제2 메타데이터를 생성하고,
    상기 제1 메타데이터와 상기 제2 메타데이터를 비교하도록 하는 전자 장치.
  7. 제6항에 있어서,
    상기 제1 메타데이터와 상기 제2 메타데이터는 클래스 정보, 메소드 리턴 타입, 메소드 인자, 및 메소드 명령어 중 적어도 하나를 포함하는 전자 장치.
  8. 제6항에 있어서, 상기 인스트럭션들은, 상기 프로세서가,
    상기 제1 메타데이터와 상기 제2 메타데이터의 해시 값(hash value)에 기반하여 상기 비교를 수행하도록 하는 전자 장치.
  9. 제1항에 있어서, 상기 인스트럭션들은, 상기 프로세서가,
    상기 제1 정보와 상기 제2 정보의 매칭에 기반하여 생성된 상기 새로운 프로파일에 기반하여 컴파일을 수행하도록 하는 전자 장치.
  10. 제9항에 있어서, 상기 인스트럭션들은, 상기 프로세서가,
    상기 새로운 프로파일의 컴파일에 기반하여 네이티브 코드 및 어플리케이션 클래스 정보에 대한 초기화 이미지를 생성하도록 하는 전자 장치.
  11. 전자 장치의 동작 방법에 있어서,
    어플리케이션의 업데이트를 감지하는 동작,
    상기 어플리케이션의 업데이트 감지에 기반하여, 상기 어플리케이션의 업데이트를 위한 업데이트 파일을 획득하는 동작,
    상기 어플리케이션에 대한 인스톨(install) 동작에서, 상기 어플리케이션과 관련하여 이전에 기록된 제1 정보와 상기 어플리케이션의 상기 업데이트 파일과 관련된 제2 정보를 획득하는 동작,
    상기 제1 정보와 상기 제2 정보의 매칭(matching)에 기반하여, 업데이트 이후에 상기 어플리케이션에서 사용될 새로운 프로파일을 생성하는 동작을 포함하는 방법.
  12. 제11항에 있어서,
    상기 제1 정보는, 사용자가 상기 어플리케이션에 대한 사용 패턴에 따라 기록된 이전 프로파일과 상기 어플리케이션의 이전 업데이트 파일의 바이트코드(bytecode)에 기반하여 생성하는 제1 메타데이터를 포함하는 방법.
  13. 제11항에 있어서,
    상기 제2 정보는, 상기 어플리케이션의 업데이트 시점에서, 상기 통신 회로를 통해, 앱스토어로부터 획득하는 상기 업데이트 파일의 바이트코드에 기반하여 생성하는 제2 메타데이터를 포함하는 방법.
  14. 제11항에 있어서, 상기 업데이트 파일을 획득하는 동작은,
    상기 어플리케이션의 상기 업데이트 파일에 대한 검증을 수행하는 동작을 포함하는 방법.
  15. 제11항에 있어서, 상기 제1 정보와 상기 제2 정보를 매칭하는 동작은,
    상기 어플리케이션에 대한 업데이트가 런타임(runtime)으로 요청되기 이전에, 상기 제1 정보와 상기 제2 정보를 매칭하는 동작,
    상기 매칭에 기반하여 일치하는 메소드(method)와 클래스(class)를 유지하는 동작을 포함하는 방법.
  16. 제15항에 있어서, 상기 제1 정보와 상기 제2 정보를 매칭하는 동작은,
    상기 제1 정보에 따른 이전 프로파일 및 이전 업데이트 파일 내 바이트코드를 파싱하여 제1 메타데이터를 생성하는 동작,
    상기 제2 정보에 따른 상기 업데이트 파일 내 바이트코드를 파싱하여 제2 메타데이터를 생성하는 동작,
    상기 제1 메타데이터와 상기 제2 메타데이터를 비교하는 동작을 포함하는 방법.
  17. 제16항에 있어서,
    상기 제1 메타데이터와 상기 제2 메타데이터는 클래스 정보, 메소드 리턴 타입, 메소드 인자, 및 메소드 명령어 중 적어도 하나를 포함하는 방법.
  18. 제16항에 있어서, 상기 비교하는 동작은,
    상기 제1 메타데이터와 상기 제2 메타데이터의 해시 값(hash value)에 기반하여 비교하는 것을 포함하는 방법.
  19. 제11항에 있어서,
    상기 제1 정보와 상기 제2 정보의 매칭에 기반하여 생성된 상기 새로운 프로파일에 기반하여 컴파일 하는 방법.
  20. 제19항에 있어서,
    상기 새로운 프로파일의 컴파일에 기반하여 네이티브 코드 및 어플리케이션 클래스 정보에 대한 초기화 이미지를 생성하는 동작을 포함하는 방법.
KR1020190111084A 2019-09-06 2019-09-06 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치 KR20210029621A (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
KR1020190111084A KR20210029621A (ko) 2019-09-06 2019-09-06 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치
EP20860639.2A EP3994571A4 (en) 2019-09-06 2020-08-25 METHOD AND APPARATUS FOR IMPROVING RUNTIME PERFORMANCE AFTER UPDATING AN APPLICATION IN AN ELECTRONIC DEVICE
PCT/KR2020/011323 WO2021045428A1 (en) 2019-09-06 2020-08-25 Method and apparatus for improving runtime performance after application update in electronic device
CN202080061838.5A CN114341800A (zh) 2019-09-06 2020-08-25 用于在电子设备中的应用更新之后提高运行时性能的方法和装置
US17/004,192 US11327739B2 (en) 2019-09-06 2020-08-27 Method and apparatus for improving runtime performance after application update in electronic device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020190111084A KR20210029621A (ko) 2019-09-06 2019-09-06 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치

Publications (1)

Publication Number Publication Date
KR20210029621A true KR20210029621A (ko) 2021-03-16

Family

ID=74850930

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020190111084A KR20210029621A (ko) 2019-09-06 2019-09-06 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치

Country Status (5)

Country Link
US (1) US11327739B2 (ko)
EP (1) EP3994571A4 (ko)
KR (1) KR20210029621A (ko)
CN (1) CN114341800A (ko)
WO (1) WO2021045428A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024071707A1 (ko) * 2022-09-28 2024-04-04 삼성전자주식회사 어플리케이션을 컴파일하기 위해 이용되는 정보를 획득하기 위한 전자 장치 및 그 방법

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115298649A (zh) * 2020-03-16 2022-11-04 Fdk株式会社 控制装置和控制程序的改写方法
CN113094290B (zh) * 2021-05-21 2024-02-23 珠海金山数字网络科技有限公司 程序测试系统及方法
CN116541045B (zh) * 2023-07-03 2023-11-03 京东科技信息技术有限公司 一种应用资源更新方法、装置和系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7191435B2 (en) * 2002-06-07 2007-03-13 Sun Microsystems, Inc. Method and system for optimizing software upgrades
JP4864557B2 (ja) * 2006-06-15 2012-02-01 富士通株式会社 ソフトウェアの更新処理プログラム及び更新処理装置
KR100828364B1 (ko) 2006-06-28 2008-05-08 삼성전자주식회사 가상 프로파일을 이용한 자바 ｊｉｔ 컴파일 방법 및시스템
US8606765B2 (en) * 2007-11-30 2013-12-10 Red Hat, Inc. Systems and methods for updating software appliances
US20140033123A1 (en) * 2009-07-30 2014-01-30 Adobe Systems, Inc. User interface and method for comparing a local version of a profile to an online update
US8838964B2 (en) * 2010-11-30 2014-09-16 Red Hat, Inc. Package audit tool
US9063819B2 (en) * 2011-01-02 2015-06-23 Cisco Technology, Inc. Extensible patch management
US8656343B2 (en) * 2012-02-09 2014-02-18 Sonatype, Inc. System and method of providing real-time updates related to in-use artifacts in a software development environment
US9275006B2 (en) * 2012-10-28 2016-03-01 Google Inc. Configuration file updater
US9760351B2 (en) 2013-04-02 2017-09-12 Google Inc. Framework for user-directed profile-driven optimizations
US9280339B1 (en) * 2013-12-12 2016-03-08 Amazon Technologies, Inc. Class replacer during application installation
US10146515B1 (en) * 2015-03-10 2018-12-04 Twitter, Inc. Live code updates
US10042735B2 (en) * 2015-07-10 2018-08-07 Ca, Inc. Selecting application wrapper logic components for wrapping a mobile application based on wrapper performance feedback from user electronic devices
US10067757B2 (en) * 2015-11-20 2018-09-04 Google Llc Dynamic update of an application in compilation and deployment with hot-swapping
CN107346252B (zh) * 2016-05-07 2021-05-25 腾讯科技（深圳）有限公司 应用更新方法和装置
US10289847B2 (en) 2016-07-29 2019-05-14 Qualcomm Incorporated Updating virtual memory addresses of target application functionalities for an updated version of application binary code
KR20180079852A (ko) 2017-01-03 2018-07-11 삼성에스디에스 주식회사 애플리케이션 변환 장치 및 방법
KR101954623B1 (ko) 2017-02-27 2019-03-06 한국전자통신연구원 가상화 환경에서의 소프트웨어 업데이트 장치 및 방법
US10552140B2 (en) * 2018-01-31 2020-02-04 Oracle International Corporation Automated identification of deployment data for distributing discrete software deliverables

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024071707A1 (ko) * 2022-09-28 2024-04-04 삼성전자주식회사 어플리케이션을 컴파일하기 위해 이용되는 정보를 획득하기 위한 전자 장치 및 그 방법

Also Published As

Publication number Publication date
EP3994571A4 (en) 2022-08-24
WO2021045428A1 (en) 2021-03-11
US20210072971A1 (en) 2021-03-11
CN114341800A (zh) 2022-04-12
EP3994571A1 (en) 2022-05-11
US11327739B2 (en) 2022-05-10

Similar Documents

Publication Publication Date Title
KR20210029621A (ko) 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치
US10795652B2 (en) Generating native code from intermediate language code for an application
WO2017166446A1 (zh) 漏洞修复方法和装置
US11435985B2 (en) Electronic device and operation method thereof
KR102400580B1 (ko) 다른 전자 장치의 인증을 수행하는 전자 장치와 이의 동작 방법
US20230185554A1 (en) Application installation method and electronic device for supporting same
WO2019182335A1 (ko) 전자 장치 및 전자 장치의 업데이트 제어 방법
KR102208696B1 (ko) 센서 데이터 획득 방법 및 그 장치
CN112162795A (zh) 一种插件启动方法、装置、计算机设备和存储介质
KR102424672B1 (ko) 악성 코드를 분류하는 전자 장치 및 그 동작 방법
KR102405593B1 (ko) 전자 장치 및 그의 데이터 운용 방법
KR102372644B1 (ko) 운영 체제의 운용 방법 및 이를 지원하는 전자 장치
KR20210046426A (ko) 어플리케이션의 최적화 방법 및 이를 지원하는 전자 장치
KR102188685B1 (ko) 애플리케이션 패키지를 생성하는 장치 및 방법
KR20210007262A (ko) 어플리케이션을 관리하는 방법 및 그 장치
US11360752B2 (en) Electronic device performing restoration on basis of comparison of constant value and control method thereof
EP3819763B1 (en) Electronic device and operating method thereof
CN113168485A (zh) 用于通过安全元件提供请求安全性服务的电子装置，及用于控制相同电子装置的方法
KR20200039053A (ko) 클라우드 서비스를 제공하는 전자 장치 및 그 동작 방법
KR102657534B1 (ko) 어플리케이션의 무결성을 검증하는 전자 장치 및 어플리케이션의 무결성을 검증하기 위한 방법
US20230236744A1 (en) Electronic device and method for managing memory of electronic device
KR20210104521A (ko) 상수 값의 비교 결과에 기반하여 리스토어를 수행하는 전자 장치 및 그 제어 방법
KR102018960B1 (ko) 이중 패킹을 이용한 코드 난독화
KR20200097100A (ko) 어플리케이션의 무결성을 검증하는 전자 장치 및 어플리케이션의 무결성을 검증하기 위한 방법
CN115167932A (zh) 一种开机性能的优化方法、装置、设备及存储介质

Legal Events

Date Code Title Description
A201 Request for examination