Android AppWidget框架妄析： Android中的借尸还魂

 

由于初识Android不久，所以一切分析皆可有误，故而只能为之妄析。 题目起的比较恐怖，然非我本意。 只是实在找不到更加贴切的，可以对AppWidget框架一针而见血的比喻了。 闲话少说，且看如何个借尸还魂。

 

首看魂者何来。 大家都知道Widget的宗旨，就是要在同一屏幕（界面上）运行多个具有独立功能的小插件，从而丰富功能的同时简化操作。那么，在Android的4大组件中，何人可以充当该角色，抑或需要再独立设计一个组件？ Activity？ 非也！！ Activity是UI呈现和用户交互的一个组件，具有独特的Task管理机制，同一时刻，框架只允许一个Activity与用户交互并呈现。 而Widget的特点是，多实例的并发交互性。 所以，Activity不能满足，不能满足同时多个Widget的并发交互和呈现。 既然不能前台，那么只能在后台Running， Service or BroadCastReceiver？ 由于Widget需要处理众多的事件交互，所以，BroadCastReceiver更加合适。 既然找到了合适的，那么也就没有必要再创造新的。 够用就可以，不是越多越好，这也是软件设计的准则。 OK， AppWidget的魂已经找到，BroadCastReceive也， 所以，Android中的AppWidget其本质就是一个BroadCastReceive组件。

 

再看尸者何来。 尸者，阳间之物也。 虽已死（本身无用），却能见光（呈现）也。 任何一个期望在其之上运行Widget的前台的应用（Activity），其实就是一个Widget宿主。 其本身而言，无任何Widget功能，但却可以和用户交互并呈现，从此点而言，可谓尸也。 Android中的AppHost即为尸也。

 

最后我们看如何还魂。 AppWidget为魂，功能强大，为所欲为，但却始终位于阴间（后台运行），无法见日，故而众人不可观之。  AppHost为尸，虽见天日，却已无所可为。  我们何不将此二者互补那？？ 但是，阴阳两隔，必须使用特殊的方式， 此即为还魂术。 通过还魂术，可使得魂寄于尸而见天日。 还魂术就是阴间通往阳间的大道。 Android中的还魂术即为RemoteView。 在Android中，由于进程边界的存在，使得AppWidget与AppHost也阴阳两隔，默认是无法直接沟通的。 采用RemoteView，让AppWidget将一切需要呈现的描述构建到RemoteView中，AppHost中再基于该描述，重新创建于属于自己进程中的View进而显示。

 

以上即为借尸还魂。 不知分析是否得当，欢迎众看官批驳。