i51跨平台中间件 i51

• 授权协议: GPL
• 开发语言: C/C++
• 操作系统: 跨平台
• 软件首页: http://i51.googlecode.com/
• 软件文档: https://i51.googlecode.com/svn/trunk/Documents

软件介绍

在某一些操作系统中因为没有“Application Programming Framework（以下简称APF）”，因而给应用开发者带来了很多不便之处，在这种平台下开发产品只能把应用程序的代码跟系统代码放在一起编译，并最终将IMG烧录到设备上才能得以验证。这种开发模式的最大问题在于效率极低，比如当我们要真机调试时，哪怕是只修改了一个log，你也必须得重新编译整个系统，非常耗时。相比之下，Android的开发就简单多了，开发者可以基于Android SDK，或第三方开发框架做交叉开发，PC端基于仿真器调试APP，真机端发布APP也很简单，只需要将APP文件放入T卡即可。这也正是“智能手机”的定义：“用户可以任意安装删除应用程序”，按照这个定义来说“i51”就是一个可以让平台智能化的技术。
“i51”就是在这个技术背景下产生的，所谓让“用户可以任意安装删除应用程序”是一种很产品化的描述。作为一个技术平台的设计方，除了要满足产品满足市场的需求之外， 必须要把在这个平台上的产品开发体验考虑在内，所以说它对应用开发者必须具备良好的编程体验，例如开发一个APP还要让开发者配置一大堆脚本，背熟一大堆命令，这种繁琐啰嗦的体验就非常不好了。对应用程序来说要跟操作系统无关，这样才可能降低维护跟运维的成本，而对技术平台本身的维护方面，它应该尽可能的减少需要移植的代码，结合这几点“i51”需要有跨平台能力。i51的跨平台思路很简单，我们在系统底层搭起了与系统无关的抽象层，它的实现是一百多个API，上层只对这些API编程，自然就做到了平台无关了。原理是很简单的，但要从多个具体系统中设计出这一百多个抽象的API是件很有挑战性的工作，就这些抽象接口设计我们大概反反复复做了2个多月才最终定型。我们印象最深的是MMI模块的音频播放部分，这类接口在不同的系统中差异都非常大，比如有些是异步的，有些是同步的，并且参数各有差异。虽然就是设计若干接口的事情，可直到i51都已经上线半年后我们才算有了一个完美的声音播放方案，跨平台的设计难度就在这。
概括来说“i51”由两部分组成，（一）为了实现跨平台“APF”，我们在操作系统中内置了一个中间件，它的主要功能是加载跟管理上层的“i51应用程序”，它的核心是“动态加载技术”，并且中间件本身也是基于抽象接口开发的，因此它也具备跨平台能力，这样我们的移植工作变得非常简单了。（二）“APF”是一种框架，或者说是应用程序开发所要遵循的规范，它的实现并没有很多实质性内容，无非就是定义“i51中间件”与“i51应用程序”之间如何交互，如何传递消息等等。定义好“APF”后，我们在此基础上开发了大量 “i51 Software Developing Kit”（俗称SDK），它可以帮助开发者更方便的开发产品，比如为了让i51的应用程序具备更好的表现力，我们开发了自己的物理引擎跟粒子系统，它的表现力满足了我们在ARMv7&ARMv9上的需要。
引用Jelo的话：

“i51是一整套解决方案，下到应用加载、卸载、消息机制、应用程序管理。上到SDK、模拟器、编程框架、各类工具、运行库应有尽有。这个i51是我们公司的核心技术，现在这个技术用不上了，我就申请拿出来开源了，老大一口就同意了，很感动。好处是，这是个商用技术，可靠性完全靠谱，这个技术还申请了广东省科技局的创新基金作为创新鼓励。
对了，我们现在主要用在了MTK、Mstar、展讯、互芯上做了移植，性能靠谱。系统资源普遍在800KB左右，ROM只用35 KB。CPU是ARM7、ARM9居多。”

接下来我们从架构的角度系统地做一下解读，如上图 “i51”是在底层操作系统基础上搭建起来的一个中间件平台，它为应用层提供了统一的、系统无关的编程接口，它的跨平台性可以让应用团队无需关心操作系统的差异，较好地控制了各个环节的复杂度，因此“i51”应用程序可以运行在所有具有“i51”中间件的设备环境中。
i51体系结构其架构由“Dynamic Components Layer”、“Static Components Layer”构成，动态层中的“对象”具备高度灵活特性，应用程序的发布不受操作系统束缚，并且相关编程框架为应用开发提供了统一且平台无关的编程接口。而，静态层与动态层的特点正相反，它的作用是屏蔽操作系统特征，并为动态层提供最基本的运行时机制，因为这一部分较少变化，所以它的实现通常作为内置代码嵌入到设备的ROM之中。
§ Applications
i51体系的动态层只有一种应用程序，它的实现受“i51编程框架”约束。应用间处于平级关系，所谓平级是指应用间相互独立、不存在依赖关系。另外， 应用程序之间的交互基于静态层提供的“消息机制”完成，整个交互过程受静态层监管。
§ Dynamic Library
“动态库”是操作系统中非常核心的技术，在i51中同样将其作为了体系结构的核心特性，它的价值主要体现在应用层，基于动态库，应用程序生命周期的三个阶段：开发、部署、维护都是完全可重构的，例如按照业务逻辑将应用程序划分多个动态库，当业务发生变化时只需要替换相关动态库即可，而在传统的静态库做法中，一旦业务逻辑发生了变化整个应用必须要重新经过“开发”、“部署”、“维护”三个阶段方可完成业务更换。
§ Static Applications
“静态应用”简称SAP是位于静态层的一组应用程序，因为它跟i51体系的具体实现有关，因此其功能特征在体系结构中并不作限制，开发者可根据不同需求定义这组应用的特征。 § Kernel “内核”负责应用管理、进程管理、资源管理、进程通信等工作。严格来说它也是一个“静态应用”，区别在于它与业务逻辑无关可作为一个体系结构中的标准化部件，如果将其泛化将很难保证体系结构在机制层面的完整，因此它的功能特征必须标准化，开发者需要以此为依据严格实施。
§ SL-API 全称是“Service Logical API”，一组与业务逻辑有关的接口集合，该接口集同时对静态层以及动态层开放，但是其功能特征在体系中同样不做任何约束，开发者可以根据不同需求实现。
§Adapter
“适配器”为上层屏蔽了操作系统特征，提高架构整体的维护性，其接口定义、功能特征作为体系标准化内容实施。
※运行时性能
基于内存快照技术，使应用间可无缝切换，并支持多应用同时执行。基于动态库技术，一个应用可以有多个动态库组成，而动态库可以由应用任意装卸，简化了应用间的关系。
※维护性能
所有业务逻辑屏蔽在动态层，由开发者通过应用程序或动态库实现。动态库基于适配器实现，使应用程序开发框架具有平台无关性。
若干技术创新
1. 多任务，同一时段可同时加载多个应用程序；

• 多应用可以用来做什么呢？举个例子，比如爱疯的“推送”机制，或PC的各种“弹窗”，无论用户在做什么系统时不时地总会有一个“对话框”告知用户世界又发生了什么，而基于“i51”的多应用机制开发者也可以走得更远。
  

2. 动态库，降低了产品开发以及代码维护的复杂度；

• 动态库的好处实在是太多了，在产品设计、进度管理、架构设计、代码实现各个阶段都有体现。
  
• 对产品设计来说，可以把软件“界面”或游戏 “地图”按照不同的动态库实现，有效节省内存、对于后期的升级来说也更具灵活性。
  
• 对进度管理来说，动态库更直观、容易感知。
  
• 对架构设计来说，动态库可以简化系统复杂度，架构中的“模块”基于动态库实现，模块之间的交互仅通过接口完成。
  
•  对代码实现来说，模块基于动态库实现，开发者可以把所有注意力放在自己的模块上，涉及到模块间交互的时候只需要调用彼此的接口。
  

3.  跨平台，编译一次多处运行；

• 对产品开发的好处是，团队可以只关心一个“代码版本”。
  
• 对产品运营来说，可以只关注一个“平台”。
  
• 总之，省时、省力、省钱、高效。
  

4.  傻瓜轻量级SDK，开发快速、友好、易用、优雅，接口的命名上足以显示技术控在细节上的追求；C/C++开发；可定制其它开发语言。

• 有多快速？以“HelloWorld”为例，新建一个“Win32 Console”工程到编译生成“执行文件”需要40秒。而新建一个“i51”工程到编译生成“执行文件”只需要20秒。整个开发过程完全可视化操作，“i51”可视化编程不需要人工敲打各种不友好的“脚本”、“命令”。
  
• 专为Soft-Rending设计的游戏引擎，以PNG为例，i51图像的绘制效率是PNG的几十倍。以一张带透明色的320x480图片为例，用PNG 绘制需要十五万三千六百次数值比较运算，大约七万六千八百次赋值运算。而“i51”的图像技术，不需要一次像素比较运算，赋值运算大约也仅有一千六百次。在内存开销方面，一张320x480的图，PNG解码后需要300KB内存存储，而i51的图像解码后只需要150KB。
  

5. 自动化测试工具。

• 覆盖“文件系统”、“内存系统”、“短信”、“电话”、“网络”、“输入法”、“Benchmark”，提高测试人员的工作效率。
  

6.  敏锐的内存管理系统。

•  可侦测“内存溢出”、“内存泄露”，为开发者解决C语言那令人纠结的内存调试问题。
  

7. 内存快照技术。

• 可永久记录应用程序使用的内存数据，等下次启动时会被“i51”自动恢复，对应用程序来说感觉就像没退出过一样，断电关机无妨。
  

8. 中间件体积。

• Only 35 KB ROM！！！
  

架构设计
* 王全伟（jelo.wang@gmail.com），热爱开源，零八年至今发起并独立完成析码编译器核心的开发，并于同年创立突壳开源社区（TOK.CC），至今已完成正则表达式引擎（REEC）、arm-elf动态链接器、i51、ELL、Hello3D等开源项目。技术完美主义者，现任深圳豆游网络首席技术官。
开发团队
* 王全伟，负责“Kernel”的开发，QQ:66970490；
* 颜天显，负责“MTK Adapter”的开发，QQ:1093235028；
* 吴平，负责“MTK Adapter”的开发，QQ:273357112；
* 吴练，负责“SPRD Adapter”的开发，QQ:471648306；
* 向荣，负责“SPRD Adapter”的开发，QQ:502495295；
* 苏言华，负责“SPRD Adapter”的开发，QQ:370532256；
* 史龙龙，负责“MStar Adapter”的开发，QQ:410886148；
* 林可，负责“MStar Adapter”的开发，QQ:112140555；
* 田敏，负责“MStar Adapter”的开发，QQ:470373759；
* OSCA，负责“MStar Adapter”的开发，QQ:45594280；
* 李雪峰，负责“i51 SDK”的开发，QQ:273642539；
* 叶盼，负责“i51 SDK”的开发，QQ:450763942；

本文地址：https://www.codercto.com/soft/d/5151.html