How to run SWF files on an early childhood education video playback platform

Abstract

This invention relates to the field of animation video playback technology, specifically a method for running SWF files on an early childhood education video playback platform. The method includes an Android-based SWF early childhood education video playback platform, which comprises at least a file isolation unit, a JNI bridging unit, an application engine, a compilation unit, a rendering adaptation unit, and an output unit. The method includes steps such as: importing the SWF file into a private cache directory for early childhood education resources within an application sandbox, configuring the JNI data exchange protocol, and establishing a shared memory management mechanism adapted to the platform. This invention enables the secure and efficient operation of SWF files on an early childhood education video playback platform, solving problems such as low security, poor efficiency, and insufficient adaptability in existing technologies.

Description

Technical Field

[0001] This invention relates to the field of animation video playback technology, specifically a method for running SWF files on an early childhood education video playback platform. Background Technology

[0002] With the booming development of the early childhood education industry, early childhood education video playback platforms have become important tools for children's learning and entertainment. SWF files, as a multimedia file format containing animation, audio, and interactive elements, offer interactive features and are very popular with children, occupying a significant proportion of early childhood education resources. However, Google has announced that it will no longer support SWF format Flash video playback in Android 4.4 and above. Therefore, existing players based on Android 4.4 and above face the problem of being unable to run SWF format Flash early childhood education video files, affecting user experience. Therefore, in the field of early childhood education, solving this problem will allow SWF video files to regain their value for both users and early childhood education manufacturers, playing a crucial role.

[0003] Regarding file handling, Android's storage sandbox model imposes strict restrictions on application access to files. Improper handling can easily lead to file import processes that do not comply with security standards, resulting in security risks such as data leaks or unauthorized access. In terms of data exchange, a lack of efficient protocols for data transfer between the Java and Native layers can result in the transfer of numerous small objects, causing unnecessary copying overhead, affecting the smoothness of instruction transmission, and consequently causing SWF file execution lag.

[0004] Furthermore, while the existing application engine core library can parse and execute SWF files, it is not optimized for mobile devices, resulting in a large library size, high runtime overhead, and the inclusion of many advanced features unnecessary for early childhood education scenarios. Additionally, the mobile rendering backend has poor compatibility with the general rendering instructions generated by the application engine, leading to poor synchronization between graphics threads and issues such as thread blocking, deadlocks, and unstable rendering frame rates, severely impacting the playback performance of SWF files in early childhood education video players.

[0005] Therefore, inventing a method that can safely and efficiently run SWF files on early childhood education video playback platforms has significant practical implications. Summary of the Invention

[0006] The main objective of this invention is to provide a method for running SWF files on an early childhood education video playback platform, aiming to solve problems such as insecure file processing, low efficiency of cross-language data exchange, poor adaptation of the application engine core library to mobile devices, and insufficient adaptability of the rendering backend when SWF files are run on the early childhood education video player platform.

[0007] To achieve the above objectives, the present invention provides a method for running SWF files on an early childhood education video playback platform: The system includes an early childhood education video playback platform based on the Android system. This platform includes at least a file isolation unit, a JNI bridging unit, an application engine, a compilation unit, a rendering adaptation unit, and an output unit. The method for running SWF files on the early childhood education video playback platform includes the following steps: Step 1: Import the SWF file via the device and store it in the early education resource private cache directory within the application sandbox; the file isolation unit adopts a file permission isolation mechanism to ensure the secure isolation of the SWF file from system files; Step 2: Configure the JNI data exchange protocol through the JNI bridging unit to establish a data channel between the Java layer and the Native layer, formulate a shared memory management mechanism adapted to the platform, transfer SWF file data to the application engine in the Native layer, manage the lifecycle of Java layer and Native layer objects, and ensure the smoothness of instruction transmission. Step 3: The application engine parses the graphics tags, sound tags, and ActionScript (the programming language for Adobe Flash Player and Adobe AIR runtime environments) tags of the SWF file to extract rendering resource data. The core parsing, decoding, and execution engines of the application engine are cross-compiled into a native library suitable for the platform through the compilation unit. The native library of the application engine is trimmed and optimized, and then executed through ActionScript code to convert it into general rendering instructions. Step 4: Receive the general rendering instructions generated by the application engine through the rendering adaptation unit, translate the general rendering instructions into the platform's native graphics API (Application Programming Interface) calls, manage graphics rendering resources, ensure that the lifecycle is synchronized with the platform view components and application engine content, optimize the instruction flow, and adapt to the characteristics of mobile GPUs. Step 5: Receive rendering instructions through the output unit, manage the lifecycle changes of the SurfaceView view component (a special view component in the Android system used for high-performance graphics rendering), handle the loss and reconstruction of the OpenGL (Open Graphics Library, a cross-language, cross-platform graphics programming interface standard) rendering context according to the Android system's lifecycle callbacks, and output the rendering results to the screen through the SurfaceView view component.

[0008] Furthermore, the process of importing and storing SWF files described in step one includes: If the user manually selects the target SWF file, then request access to external storage permissions. If authorization fails, the process terminates. If authorization succeeds, the file descriptor is obtained through ContentResolver (a component in the Android system used for cross-application data access), and file type verification is performed. If the caller passes in the SWF file path, the passed path is validated. If it is an invalid path, a security exception is thrown; if it is a valid path, file type validation is performed. If the file type is not an SWF file, the application is rejected; if it is a valid SWF file, a private cache file for the application is created; data is copied using FileChannel (the core channel class for file operations in Java NIO), and file permissions are set to ensure that the underlying data source for subsequent operations is valid, secure and controllable.

[0009] Furthermore, the JNI data exchange protocol described in step two includes: Rendering instruction streams are passed via direct memory buffers or off-heap memory; Texture resources are passed as Android Bitmap (the core class used to process images in the Android system) objects. The Native layer obtains pixel data or resource handles through the LockPixels API (JNI functions used to process bitmap pixel data). AS3 (short for ActionScript 3.0) data types, with basic types mapped through JNI native types; Complex objects, including matrices, are serialized into FloatArrays (a tool in AS3 for handling high-performance numerical computations) for transmission.

[0010] Furthermore, the shared memory management mechanism described in step two includes: Command batch processing: transmit commands in batches after accumulating 50ms or 200 commands. A direct memory pool is used, which allocates 10MB of ByteBuffer (a class used for data buffering in Java NIO) during initialization and is used cyclically. Object reuse allows the Java layer to directly manipulate native memory through NIO DirectByteBuffer (a Java class used for efficient data storage); Asynchronous callbacks and resource release callbacks must include view lifecycle validity checks or registration mechanisms to prevent callbacks from occurring when the view has been destroyed. Furthermore, the graphics rendering resources described in step four include texture uploading, shader compilation, vertex buffers, and frame buffers.

[0011] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention adapts to the Android storage sandbox model, standardizes the file import process, and handles runtime permissions properly, storing SWF files in the application's private cache directory. This effectively ensures the security and legitimacy of files and reduces the risk of data leakage and unauthorized access.

[0012] 2. This invention optimizes the JNI data exchange protocol, reducing small object transfer and unnecessary copying overhead. It ensures smooth instruction transmission through multiple mechanisms, improves the running efficiency of SWF files, and avoids lag.

[0013] 3. This invention trims and optimizes the application engine core library, making it more suitable for running on early childhood education video playback platforms, reducing library size and runtime overhead, and improving resource utilization.

[0014] 4. This invention achieves efficient conversion between general rendering instructions and Android's native graphics API through a dedicated mobile rendering backend, adapts to the characteristics of mobile GPUs, ensures the rendering quality and efficiency of SWF files, and meets the needs of early childhood education.

[0015] 5. This invention properly handles the lifecycle changes of SurfaceView, improving the stability and reliability of SWF files running on early education video playback platforms. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the implementation of the present invention; Figure 2 This is a flowchart illustrating the process of importing and saving SWF files for this invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] Please see Figure 1 As shown, the present invention provides a method for running SWF files on an early childhood education video playback platform: This includes an early childhood education video playback platform based on the Android system. The platform includes at least a file isolation unit, a JNI bridging unit, an application engine, a rendering adaptation unit, and an output unit. The method for running SWF files on the early childhood education video playback platform includes the following steps: Step 1: Import the SWF file via the device and store it in the early education resource private cache directory within the application sandbox; the file isolation unit adopts a file permission isolation mechanism to ensure the secure isolation of the SWF file from system files.

[0019] like Figure 2 As shown, the process of importing and storing SWF files includes: If the user manually selects the target SWF file, then request access to external storage permissions. If authorization fails, the process terminates. If authorization succeeds, the file descriptor is obtained through ContentResolver, and file type verification is performed. If the caller passes in the SWF file path, the passed path is validated. If it is an invalid path, a security exception is thrown; if it is a valid path, file type validation is performed. If the file type is not an SWF file, the application is rejected; if it is a valid SWF file, a private cache file for the application is created; data is copied using FileChannel, and file permissions are set to ensure that the underlying data source for subsequent operations is valid, secure, and controllable.

[0020] The above steps implement a file import process that conforms to Android best practices, handles runtime permissions, and securely copies or moves the user-selected SWF file to the application's private cache directory, ensuring that the underlying data source for subsequent operations is legitimate, secure, and controllable. By strictly adhering to the Android system's storage permission mechanism, file operations are performed only with user authorization, avoiding interference with other user files and protecting user data security.

[0021] Step 2: Configure the JNI data exchange protocol through the JNI bridging unit to establish a data channel between the Java layer and the Native layer, formulate a shared memory management mechanism adapted to the platform, transfer SWF file data to the application engine in the Native layer, manage the lifecycle of Java layer and Native layer objects, and ensure the smoothness of instruction transmission.

[0022] The JNI data exchange protocol includes: Rendering instruction streams are passed via direct memory buffers or off-heap memory; Texture resources are passed as Android Bitmap objects, and the Native layer obtains pixel data or resource handles through the LockPixels API. AS3 data types, basic types are mapped through JNI native types; Complex objects, including matrices, are serialized into FloatArrays for transmission.

[0023] The shared memory management mechanism includes: Command batch processing: transmit commands in batches after accumulating 50ms or 200 commands. A direct memory pool is used, allocating 10MB of ByteBuffer during initialization and using it in a cyclical manner. Object reuse allows the Java layer to directly manipulate native memory via NIO DirectByteBuffer. Asynchronous callbacks and resource release callbacks must include view lifecycle validity checks or registration mechanisms to prevent callbacks from occurring when the view has been destroyed.

[0024] By configuring and optimizing the data structure of the JNI interface as described above, we can avoid passing a large number of small objects, use buffers (ByteBuffer) and shared memory to pass complex rendering instructions or resource data, manage the lifecycle of Java layer and Native layer objects, reduce unnecessary copying overhead, and ensure the smoothness of instruction transmission.

[0025] Step 3: The application engine parses the graphics tags, sound tags, and ActionScript tags of the SWF file to extract rendering resource data. The core parsing, decoding, and execution engine of the application engine is cross-compiled into a native library suitable for the platform through the compilation unit. The native library of the application engine is trimmed and optimized, and executed through ActionScript code to convert it into general rendering instructions.

[0026] By cross-compiling the application engine's core parsing, decoding, and execution engines into native libraries suitable for Android, complex library dependency and linking issues are resolved.

[0027] By trimming and optimizing the application engine's native libraries as necessary, unnecessary advanced features are simplified, focusing on the core parsing and instruction generation requirements of mobile devices, thereby controlling library size and runtime overhead.

[0028] In this embodiment, the specific trimming and configuration optimization items include: Completely remove FLV video decoding, retaining only the basic DropShadow advanced filter effects; remove support for the old AVM1 virtual machine (supporting AS1 / AS2), retaining only the complete AVM2 virtual machine (for running AS3); replace system font rendering with Android Typeface, prioritizing the loading of commonly used fonts in early education scenarios (such as cartoon fonts and large fonts) to adapt to children's reading needs; use the system libxml2 as the XML parser.

[0029] The core components, such as the SWF tag parser, ActionScript 3.0 bytecode interpreter, basic shape rendering pipeline, event dispatch system, and simple button control support, are retained, resulting in a smaller compiled library size.

[0030] Step 4: Receive the general rendering instructions generated by the application engine through the rendering adaptation unit, translate the general rendering instructions into native graphics API calls of the platform, manage graphics rendering resources, ensure that the lifecycle is synchronized with the platform view components and application engine content, optimize the instruction flow, and adapt to the characteristics of mobile GPUs.

[0031] Specifically, this includes: translating general drawing instructions into Android's OpenGL ES API calls, such as converting the Ruffle rectangle drawing instruction into an OpenGL ES quadrilateral drawing operation; managing texture uploads, converting Bitmap objects into OpenGL textures and uploading them to the GPU; compiling shader programs suitable for mobile GPUs; creating and managing vertex buffers and frame buffers; and ensuring that the lifecycle of these resources is synchronized with the lifecycle of the SurfaceView, releasing related resources promptly when the SurfaceView is destroyed.

[0032] The above steps enable efficient conversion between general rendering commands and Android's native graphics API, leveraging the characteristics of mobile GPUs to avoid unnecessary state switching and API call overhead, thus ensuring the rendering quality and efficiency of SWF files.

[0033] Step 5: Receive rendering instructions through the output unit, perform synchronous optimization of the Android graphics thread model, manage the lifecycle changes of the SurfaceView view component, handle the loss and reconstruction of the OpenGL rendering context according to the Android system's lifecycle callbacks, and output the rendering results to the screen through the SurfaceView view component.

[0034] Specifically, the synchronization optimization of the Android graphics thread model includes: The system sets up a file loading thread, an AS3 (ActionScript 3.0) execution thread, and a rendering thread. The file loading thread and the AS3 execution thread exchange data via an MPSCQ queue (Multiple Producers, Single Consumer Queue), while the AS3 execution thread and the rendering thread exchange rendering commands via an SPSCQ queue (Single Producer, Single Consumer Queue). Rendering commands employ a triple-buffering mechanism, with three buffers used alternately to prevent frame tearing. Lifecycle synchronization locks are used to ensure the safety of data operations when threads access shared resources.

[0035] Specifically, handling the SurfaceView lifecycle includes: When a SurfaceView is paused, the rendering thread releases the GL (Open Graphics Library) textures uploaded to the GPU, but retains the vertex data in memory. When the SurfaceView resumes and the surfaceCreated method is triggered, the reloadTextures method is called to reload the texture resources, and the rebindBuffers method is called to rebind the vertex buffers. When the size of the SurfaceView changes, the framebuffer object (FBO) is rebuilt and the viewport size is adjusted. If a GL context loss occurs, all GPU resources are destroyed, data is reloaded from the native layer, and the relevant resources are rebuilt.

[0036] By following the steps above, the graphics thread model and synchronization mechanism are configured appropriately, avoiding thread blocking and deadlock, ensuring stable rendering frame rate, and properly handling the lifecycle changes of SurfaceView, thereby improving the stability and reliability of SWF files running in early education video players.

[0037] Overall, through the above steps, the method of this embodiment can safely and efficiently run SWF files in early education video players, with smooth playback and stable picture, meeting children's playback needs for SWF format early education resources in early education scenarios.

[0038] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An implementation method for running SWF files on an early education video playing platform, characterized in that: The early childhood education video playback platform includes at least a file isolation unit, a JNI bridging unit, an application engine, a compilation unit, a rendering adaptation unit, and an output unit. The method for running SWF files on an early childhood education video playback platform includes the following steps: Step 1: Import the SWF file via the device and store it in the early education resource private cache directory within the application sandbox; the file isolation unit adopts a file permission isolation mechanism to ensure the secure isolation of the SWF file from system files; Step 2: Configure the JNI data exchange protocol through the JNI bridging unit to establish a data channel between the Java layer and the Native layer, formulate a shared memory management mechanism adapted to the platform, transfer SWF file data to the application engine in the Native layer, manage the lifecycle of Java layer and Native layer objects, and ensure the smoothness of instruction transmission. Step 3: The application engine parses the graphics tags, sound tags, and ActionScript tags of the SWF file to extract rendering resource data. The core parsing, decoding, and execution engine of the application engine is cross-compiled into a native library suitable for the platform through the compilation unit. The native library of the application engine is trimmed and optimized, and then executed through ActionScript code to convert it into general rendering instructions. Step 4: Receive the general rendering instructions generated by the application engine through the rendering adaptation unit, translate the general rendering instructions into the platform's native graphics API calls, manage graphics rendering resources, ensure that the lifecycle is synchronized with the platform view components and application engine content, optimize the instruction flow, and adapt to the characteristics of mobile GPUs. Step 5: Receive rendering instructions through the output unit, perform synchronous optimization of the Android graphics thread model, manage the lifecycle changes of the SurfaceView view component, handle the loss and reconstruction of the OpenGL rendering context according to the Android system's lifecycle callbacks, and output the rendering results to the screen through the SurfaceView view component.

2. The method of claim 1, wherein the SWF file is run on an early education video playing platform. The process of importing and storing SWF files as described in step one includes: If the user manually selects the target SWF file, then request access to external storage permissions. If authorization fails, the process terminates. If authorization succeeds, the file descriptor is obtained through ContentResolver, and file type verification is performed. If the caller passes in the SWF file path, the passed path is validated. If it is an invalid path, a security exception is thrown; if it is a valid path, file type validation is performed. If the file type is not an SWF file, the application is rejected; if it is a valid SWF file, a private cache file for the application is created; data is copied using FileChannel, and file permissions are set to ensure that the underlying data source for subsequent operations is valid, secure, and controllable.

3. The method for running SWF files on an early childhood education video playback platform as described in claim 1, characterized in that: The JNI data exchange protocol described in step two includes: Rendering instruction streams are passed via direct memory buffers or off-heap memory; Texture resources are passed as Android Bitmap objects, and the Native layer obtains pixel data or resource handles through the LockPixels API. AS3 data types, basic types are mapped through JNI native types; Complex objects, including matrices, are serialized into FloatArrays for transmission.

4. The method for running SWF files on an early childhood education video playback platform as described in claim 1, characterized in that: The shared memory management mechanism described in step two includes: Command batch processing: transmit commands in batches after accumulating 50ms or 200 commands. A direct memory pool is used, allocating 10MB of ByteBuffer during initialization and using it in a cyclical manner. Object reuse allows the Java layer to directly manipulate native memory via NIO DirectByteBuffer. Asynchronous callbacks and resource release callbacks must include view lifecycle validity checks or registration mechanisms to prevent callbacks from occurring when the view has been destroyed.

5. The method for running SWF files on an early childhood education video playback platform as described in claim 1, characterized in that: The graphics rendering resources mentioned in step four include texture uploading, shader compilation, vertex buffers, and frame buffers.

6. The method for running SWF files on an early childhood education video playback platform as described in claim 1, characterized in that: Step five, which involves optimizing the synchronization of the Android graphics thread model, includes: The system sets up a file loading thread, an AS3 execution thread, and a rendering thread. The file loading thread and the AS3 execution thread exchange data via an MPSCQ queue, while the AS3 execution thread and the rendering thread exchange rendering commands via an SPSCQ queue. Rendering commands employ a triple-buffering mechanism, with three buffers used alternately to prevent frame tearing. When threads access shared resources, lifecycle synchronization locks are used to ensure the safety of data operations.

7. The method for running SWF files on an early childhood education video playback platform as described in claim 1, characterized in that: Step five involves handling the SurfaceView lifecycle, including: When a SurfaceView is paused, the rendering thread releases the OpenGL textures uploaded to the GPU, but retains the vertex data in memory. When the SurfaceView resumes and the surfaceCreated method is triggered, the reloadTextures method is called to reload the texture resources, and the rebindBuffers method is called to rebind the vertex buffers. When the size of the SurfaceView changes, the framebuffer object is rebuilt and the viewport size is adjusted. If an OpenGL context loss occurs, all GPU resources are destroyed, data is reloaded from the Native layer, and the relevant resources are rebuilt.

Images