De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda

FlatBuffers es una biblioteca de software libre que implementa un formato de serialización similar a Protocol Buffers , Thrift , Apache Avro , SBE y Cap'n Proto , escrito principalmente por Wouter van Oortmerssen y de código abierto por Google . Al igual que Cap'n Proto y SBE, admite la deserialización de "copia cero", por lo que para acceder a los datos serializados no es necesario copiarlos primero en una parte separada de la memoria, lo que hace que acceder a los datos en estos formatos sea mucho más rápido que los datos en formatos que requieren procesamiento más extenso, como JSON , CSVy, en muchos casos, búferes de protocolo. Sin embargo, en comparación con otros formatos de serialización, el manejo de FlatBuffers generalmente requiere más código y algunas operaciones no son posibles (como algunas operaciones de mutación).

El formato serializado permite el acceso aleatorio a elementos de datos específicos (por ejemplo, cadenas individuales o propiedades enteras) sin analizar todos los datos. A diferencia de Protocol Buffers, que utiliza números enteros de longitud variable , FlatBuffers codifica números enteros en su tamaño nativo, lo que favorece el rendimiento pero conduce a representaciones codificadas más largas.

FlatBuffers es un proyecto popular en GitHub , con 15,461 estrellas, 442 colaboradores, 2,383 bifurcaciones y 645 observadores en GitHub al 10 de diciembre de 2020 . [3]

FlatBuffers se puede utilizar en software escrito en C ++ , C # , C , Go , Java , JavaScript , Kotlin , Lobster, Lua , PHP , Python , Rust , Swift y TypeScript . El compilador de esquemas se ejecuta en Android , Microsoft Windows , Mac OS X y Linux , [3] pero los juegos y otros programas que usan FlatBuffers para la serialización también funcionan en muchos otros sistemas operativos, incluido iOS ,Amazon 's Fuego OS y Windows Phone . [4]

Van Oortmerssen desarrolló originalmente FlatBuffers para el desarrollo de juegos y aplicaciones similares. [5] [1]

Aunque FlatBuffers tiene su propio lenguaje de definición de interfaz para definir los datos que se serializarán con él, también admite esquemas definidos en el formato .proto de Protocol Buffers. [6]

Usuarios [ editar ]

Algunos usuarios notables de FlatBuffers:

  • Cocos2d-x , la popular biblioteca de programación de juegos 2-D de software libre, utiliza FlatBuffers para serializar todos los datos de sus juegos. [7]
  • Facebook Android Client utiliza FlatBuffers para el almacenamiento en disco y la comunicación con los servidores de Facebook. El formato JSON utilizado anteriormente tenía un rendimiento deficiente. [8]


Ver también [ editar ]

  • Comparación de formatos de serialización de datos

Referencias [ editar ]

  1. ↑ a b Wouter van Oortmerssen (17 de junio de 2014). "FlatBuffers: una biblioteca de serialización de memoria eficiente" . Consultado el 15 de junio de 2017 .
  2. ^ "Lanzamientos - google / flatbuffers" . Consultado el 19 de mayo de 2020 , a través de GitHub.
  3. ^ a b "GitHub - google / flatbuffers: biblioteca de serialización eficiente de la memoria" . GitHub . Consultado el 10 de diciembre de 2020 .
  4. ^ "FlatBuffers para la unidad" . eXiin. 2015-09-21 . Consultado el 15 de junio de 2017 . Probamos flatbuffers [sic] en todas las principales plataformas móviles (iOS, Android, Amazon Os [sic], Windows Phone) en las que estamos construyendo [,] y funciona bastante bien.
  5. ^ "Documentación de FlatBuffers" . Consultado el 21 de junio de 2017 . FlatBuffers es una biblioteca de serialización multiplataforma eficiente para C ++, C #, C, Go, Java, JavaScript, PHP y Python. Fue creado originalmente en Google para el desarrollo de juegos y otras aplicaciones críticas para el rendimiento.
  6. Kenton Varda (17 de junio de 2014). "Cap'n Proto, FlatBuffers y SBE" . Consultado el 15 de junio de 2017 .
  7. ^ http://www.cocos2d-x.org/reference/native-cpp/V3.5/d7/d2d/namespaceflatbuffers.html
  8. George Xie (31 de julio de 2015). "Mejorando el rendimiento de Facebook en Android con FlatBuffers" . Consultado el 15 de junio de 2017 . El tiempo de carga de la historia desde la caché del disco se reduce de 35 ms a 4 ms por historia. Las asignaciones de memoria transitoria se reducen en un 75 por ciento. El tiempo de arranque en frío se mejora en un 10-15 por ciento. Hemos reducido el tamaño de almacenamiento en un 15 por ciento.