在Android上实现多进程构架的浏览器（浏览器开发）的讨论

从以下几个方面进行考虑： 1. android 的service理解，考虑service实现多进程。 2. 分析参考chrome多进程构架在android上的实现，提出渲染进程用service实现。 3. 多进程构架的优缺点，比如从内存，ipc通信等方面 4. 给出一个设计思路和实现思路。？？？

从浏览器服务于几乎没有动态的代码的网页，到大量网页转而使用动态网页，从含有大量javascript和flash的网页到像完全成熟的网络应用如GMail。浏览器一是必须要让这些应用互相分离，二是要解决好导致渲染引擎崩溃；三是要解决用户浏览的安全性。

向用户提供多进程浏览。以期达到在浏览器中添加多进程浏览功能之后，即使是浏览器其中的一个进程出现了崩溃现象，其他的进程也不会受到影响的目的。类似Android虚拟机的实例。有很多的浏览器厂商采用了多进程标签浏览的概念，其中包括谷歌Chrome、微软IE8和Mozilla Firefox，而众多基于WebKit的浏览器也将在不久之后采用多进程标签浏览这个功能，例如苹果的Safari浏览器。其中大致包括：浏览器进程、渲染进程、插件进程和扩展进程。如果创建太多的进程，内存占用较大，电脑的性能会降低。对于较低配置的机器而言，长时间浏览会导致整个系统变慢甚至失去响应。影响用户体验效果。一般限定创建渲染进程的最大数量大多数情况下是20。同一个渲染器进程可以被用于多个站点。

》Android架构设计思想、原则及系统的核心
1、Android的核心在Framework层，本质上，这是一个基于组件的应用开发系统，组件间通过消息（Intent）进行通信。一方面，Intent是通信信息的载体，另一方面，Intent也定义了Android组件的通信协议。
2、Android的权限系统是基于Linux，但又增加了很多自己的控制模块。Android架设在Linux之上，因此，继承了Linux可移植性、用户管理机制、文件系统，等等。
总体上来说，其分为以下几部分权限系统：
（1）userid : 继承于linux，对于多个app，通过shareuid的方式可以使用同一个userid，主要承担一些目录访问权限之类的工作，比如私有目录只能由同一uid应用访问。
（2）安装level：system level or app level，这个是根据应用的安装位置决定的，在system/app下安装的应用就是system level，在权限访问中会得到更多的权限，比如静默安装应用的权限等。
（3）permission : 这个是最主要的权限控制，一般开发者开发应用主要是接触这个部分，在这部分中，会根据应用在AndroidManifest.xml中声明的use-permission而在访问相应api或资源时判断其是否有访问权限，比如常用的android.permission.INTERNET等。
（4） signature: 签名，是Android权限系统中的重要组成部分，对于系统签名的应用，会有一些特殊的功能，而shareuid等特性也是需要同一签名作基础。此外，permission在设置/自定义其权限时也经常会使用到签名，比如控制只有我自己的应用才可以访问我自己定义的公开API。

》可以借鉴chrome多进程构架在android上实现多进程架构的浏览器设想。在Android中，进程概念相当薄弱。Android可以对组件所运行的进程做托管，依赖于进程托管，Android可以轻松支撑多任务多进程的应用模型。只要控制好多进程浏览开发的数量与内存占用的比例，解决好多进程构架的最大的优缺点之一就是对内存（CPU）资源的占用，如果能解决资源对内存的占用，及ipc通信等方面的用户体验，多程功能在Android上开发还是有价值的。除了组件，资源体系也是Android中比较特色的一块，它提供了完整的资源支持，可以用来描述一切与UI相关的内容，并实现多设备的适配。

》进程开销过大，不建议实现多进程，就目前安卓手机的配置而言，多进程必然导致高CPU高耗电，我相信用户更喜欢一个轻便快速的APP，进程是常驻的，通常来说为一个程序开启多个进程，是完全没有必要的，由此我们通常采用多线程的手段；
   线程好处显而易见，可以提高CPU的利用率。在多线程程序中，一个线程必须等待的时候，CPU可以运行其它的线程而不是等待，这样就大大提高了程序的效率；当然线程也不要设置过多，因为线程也是程序，所以线程需要占用内存，线程越多占用内存也越多；多线程需要协调和管理，所以需要CPU时间跟踪线程；线程之间对共享资源的访问会相互影响，必须解决竞用共享资源的问题；线程太多会导致控制太复杂，最终可能造成很多Bug；而且现在各种机型的配置不同，可以考虑因为机器配置CPU的采集而分配多少线程的思路；

》启动多个后台service进程,并发运行JS,CSS解析引擎,再通过一个前端service接收解析后的结果,生成渲染数据或者JS操作指令,根据渲染数据及JS操作指令,边执行,边渲染,经过几次渲染调整的过程,页面最终就会呈现出来. 多进程的优点: 1. 流水作业, 效率最大化, android是通过移植JAVA虚拟机来运行APP程序,虽然内存管理在不断得到优化,但频繁的内存分配及释放, 在ANDROID手机上也会难担重负. 流水化作业后,各工序分配的内存资源可分隔反复重用. 2 由于各工序分配在不同的service流水线进程中, 如果某工序所在流水线(即service进程)停止,可单独重启该作业流水线service,不会造成其它流水线停止. 缺点有: 进程之间的通讯通过IPC进行, 效率比共享内存低, 同时需要协调管理各进程的状态, 开发难度加大.

》对当前机器 CPU＋内存＋网络IO＋磁盘IO 四项进行分析，
多进程／多线程方式虽然是充分的利用了这前述的四项资源，但当大量的多进程／多线程的时候，内外存交换又成为了新的瓶颈。 
V8就是一个相当不错的解决的方案，基于事件的程序模式将是未来的一种趋势和方向。

》在Android上实现多进程构架的浏览器肯定是没有问题的。
从浏览器的构架上来说，这样做合理吗？
如果用进程的方式，无疑对内存的占用，系统的功耗这些都会产生问题。
但是好处也是不容质疑的，采用进程的方式对稳定性的提高是不容质疑的。
一个浏览器页面至少存在三个线程:js引擎线程(处理js)、GUI渲染线程(渲染页面)、浏览器事件触发线程(控制交互)。即使是线程模式，浏览器多个页面的时候也存在为数众多的线程。
考虑当前的浏览器主要有两个对性能要求较高的两个部分：
JS引擎
Render引擎
对于JS引擎，较旧的引擎一般都是单线程的，新的引擎都开始支持多线程的实现了，例如chrome的JS引擎中的webwork调度单元就是以多线程为基础的。
对于Render引擎，涉及的面就更复杂，特别是最进HTML5中WebGL引入之后，涉及到的模块就跟多。
所以从架构的方向上来说，偏向于进程实现，否则这么多的线程在一个进程中，系统的复杂度和维护成本会越来越高，同时可扩展性也变差。
从移动SoC的发展来看，未来提供的可计算的单元越来越多，主流SoC都已经进入到八核阶段，以及相应的移动GPU也都4核，内存也从1G向4G过渡，总线也由32位向64位过渡，所以新的硬件架构下，进程模式的优势会越来越大。
对于Android系统中的浏览器部分，不管是service也好还是Activity也好都是属于Application Framework的部分，他们的设计目的是不同应用之间的交互或者为系统提供应用间的交互，而对于浏览器这样基础的，庞大的应用，其内部各个引擎只为应用内部服务，所以不应该采用Application framework里面的组建来提供对外的服务接口，除非楼主希望完成一套标准话的Android浏览器架构。
对于现存的浏览器来说基本都是采用本地化的C/C++库来实现这些功能。

》  1. android 的service理解，考虑service实现多进程。
2. 分析参考chrome多进程构架在android上的实现，提出渲染进程用service实现。
3. 多进程构架的优缺点，比如从内存，ipc通信等方面

一个进程崩溃不会损害到其他进程以及操作系统。同时系统会严格的限制一个用户访问另外一个用户空间的数据。