精华内容
下载资源
问答
  •  有时个为了提高设计的重用性,我们会把一些页面内容(如个人信息、好友列表、文章列表,订阅信息等)设计成组件的形式,这样在不同的页面添加这些资源的时候就非常简单了,只需要做简单的include就行了。例如: ...

    Web组件化中HTML、CSS和JS资源的管理

    (2010-03-14 14:06:24)
    标签:

    杂谈

     

      有时个为了提高设计的重用性,我们会把一些页面内容(如个人信息、好友列表、文章列表,订阅信息等)设计成组件的形式,这样在不同的页面添加这些资源的时候就非常简单了,只需要做简单的include就行了。例如:
    <%@ includefile=”xxx.jsp”%>
    <jsp:include page=”yyy.jsp”flush=”true”/>

    其中xxx.jsp文件通常是静态文件,也即内容是固定的;yyy.jsp通常是动态文件,内容通常是动态生成的。

      但是通常这个web组件又依赖于特定的.js文件和.css文件。对于.js文件倒还好说,因为它可以出现在web页面的任意标签之中。因此你可以在xxx.jsp或者yyy.jsp中加入
    <script type="text/javascript"src="zzz.js"></script>
    来导入JS文件。

      但对于.css文件就没有那么简单了,因为XHTML标准规定
    <link href="CSS/zzz.css"rel="stylesheet" type="text/css" />
    必须出现在<head>标签之中,而通常情况下xxx.jsp和yyy.jsp是没有<head>标签的。一个解决方案就是没整站创建一个包含所有样式的.css文件,但这样就会导致超量定义,使该文件过大,浪费用户带宽和浏览器资源。

      我们这里推荐使用另一个解决方案,即通过Javascript操作DOM的方法动态往<head>标签中添加样式表文件。在xxx.jsp或者yyy.jsp中添加如下内容:
    <script type="text/javascript">
    function addStylesheet(href, rel, type) {
        rel = "stylesheet";
        type = "text/css";   
        var link = document.createElement("link");
        link.href = href;
        link.rel = rel;
        link.type = type;   
       document.getElementsByTagName_r("head")[0].appendChild(link);
    }
    addStylesheet("xxx.css");
    <script>

      这样你就可以在主页面中能过一行include就可以加入你的web组件内容了,这也算是一种web widget技术吧。

      当然,对于多个组件可能会重复使用的CSS或者JS资源,建议在调用页面只include一次,这样会减少资源的浪费和重复定义。另外,通过分解后,虽然资源的可定制化程度提高了,但会引入更多的文件,而每个文件又会引入一个HTTP请求,实际中应当酌情权衡。通常情况下是这样处理,一个站点通常会有一些common的.css文件和.js库文件,在所有页面中都会include这些通用的资源。然后,每个组件再在这个基础上定义自己特殊的CSS样式和JS脚本。

    展开全文
  • PackageManagerService启动详解(二)之对已安装应用怎么进行持久化存储管理? Android PackageManagerService系列博客目录: PackageManagerService启动详解系列博客概要 PackageManagerService启动详解(一)之整体...

    PKMS启动详解(二)之怎么通过packages.xml对已安装应用信息进行持久化管理?


    Android PackageManagerService系列博客目录:

    PKMS启动详解系列博客概要
    PKMS启动详解(一)之整体流程分析
    PKMS启动详解(二)之怎么通过packages.xml对已安装应用信息进行持久化管理?
    PKMS启动详解(三)之BOOT_PROGRESS_PMS_START流程分析
    PKMS启动详解(四)之Android包信息体和包解析器(上)
    PKMS启动详解(五)之Android包信息体和包解析器(中)
    PKMS启动详解(六)之Android包信息体和包解析器(下)
    PKMS启动详解(七)之BOOT_PROGRESS_PMS_SYSTEM_SCAN_START阶段流程分析
    PKMS启动详解(八)之BOOT_PROGRESS_PMS_DATA_SCAN_START阶段流程分析



    引言

      在前面的博客PackageManagerService启动详解(一)之整体流程分析中我们概述了PKMS启动的整体流程,按照正常的逻辑本篇博客将要对PKMS启动的第一阶段BOOT_PROGRESS_PMS_START来个详细的分析,但是发现在这之前非常有必要单独拉出来一篇博客对该阶段将要涉及的Settings以及关联的packages.xml等文件来先分析一番,怎么说呢只有将这块分析透了后续才好进行下去。

    是不是感觉上述的描述有点平淡无奇啊,不抛出点灵魂拷问,估计读者都没有兴趣要拍屁股走人了(是时候展示点真正的技术了):
    1.PKMS对于扫描成功后的应用信息(也包括第三方安装成功的应用),有没有进行持久化的存储,进行持久化的存储位置是什么

    2.如果有进行持久化,那么持久化的形式是什么

    3.为什么PKMS需要对已经安装应用的相关信息进行持久化处理

    4.对于安装应用被持久化的信息,PKSM是怎么加载的呢

    5.PKMS服务既然是加会不会加载上述持久化的数据,如果要加载,是不是应该存在一个管理者,来全局管理,那个这个类是什么

    6.系统应用被覆盖升级(即通过普通安装升级)之后重启,PKMS是怎么辨别是使用安装在data分区的还是使用在系统分区的呢

    7.如果应用安装目录被删除了,那么PKMS对于它的数据目录会怎么处理呢

    是不是前面这一番灵魂大拷问,激起了了你的战斗欲望。读者如果对PKMS服务的管理机制不是很熟悉的话,一时半会回答不上也没有关系!这篇文章要干的就是初步解决上面的疑问,然后为后续具体的PKMS扫描等相关流程打好基础。


    注意:本篇的介绍是基于Android 7.xx平台为基础的(并且为了书写简便后续PackageManagerService统一简称为PKMS),其中涉及的代码路径如下:

    --- frameworks/base/services/core/java/com/android/server/pm/
    	PackageSetting.java 
    	Settings.java
    	PackageSettingBase.java
    	PackageSignatures.java
    	SettingBase.java
    	SharedUserSetting.java
    	
    --- frameworks/base/core/res/res/values/attrs_manifest.xml
    
    --- frameworks/base/core/java/android/os/Process.java
    
    --- frameworks/base//core/java/android/content/pm/ApplicationInfo.java
    



    一.Android安装应用信息持久化区域是什么,涉及到了那些文件

      做人要有始有终方得始终不是,博主是一个负责人的人,所以抛出了问题,必须解决问题不是,这不就安排上了!上面说的安装应用信息持久化区域其实在我们的Android终端的/data/system目录下,这个目录下存储了许多应用运行中生成的配置文件,关于PKMS有如下的几个文件,分别是:

    • packages.xml:记录了系统中所有安装的应用信息,包括基本信息、签名和权限,这个是Android应用信息持久化的关键文件(章节1.2会详细介绍)
    • pakcages-back.xml:packages.xml文件的备份,用于描述系统中所安装的所有 Package 信息,PMS 会先把数据写入 packages-backup.xml,信息写成功后,再改名为 packages.xml
    • pakcages-stoped.xml:记录系统中被强制停止的运行的应用信息。系统在强制停止某个应- 用的时候,会将应用的信息记录在该文件中
    • pakcages-stoped-backup.xml:pakcages-stoped.xml文件的备份
    • package-usage.list:记录了应用的使用情况,譬如使用了多久
    • packages.list:记录了应用的一些简单情况(章节1.1会详细介绍)

    这里我们来看下我当前Android系统中相关存储区域涉及的文件信息,如下:


    在这里插入图片描述


    细心的读者看到上面的截图,估计会说博主你这个骗子,欺骗我们的感情,说好的pakcages-back.xml和pakcages-stoped-backup.xml文件怎么没有看到啊!我是无辜的,真的,我没有欺骗你们。

    当Android对文件packages.xml和pakcages-stoped.xml写之前,会先把它们备份,如果写文件成功了,再把备份文件删除。如果写的时候,系统出问题了,重启后在需要读取这两个文件时,如果发现备份文件存在,会使用备份文件的内容,因为源文件可能已经损坏了。所以正常情况下我们是看不到的。


    1.1 packages.list简介

    packages.list文件内容相对简单,我们打开packages.list文件后,我们会发现其中对于系统中所有安装的应用都有类似如下的描述类容(这里我们选择了一个复杂点的):

    com.android.settings 1000 0 /data/user_de/0/com.android.settings platform:privapp 3002,1023,1015,3003,3001,1021,3004,3005,1000,2002,2950,1010,1007
    

    是不是被上述一长串信息整蒙了,读者朋友先展开想象,每个字符串代表的意思是什么呢!我们先看下Android源码中对于它的描述,如下:

                    // we store on each line the following information for now:
                    //
                    // pkgName    - package name
                    // userId     - application-specific user id
                    // debugFlag  - 0 or 1 if the package is debuggable.
                    // dataPath   - path to package's data path
                    // seinfo     - seinfo label for the app (assigned at install time)
                    // gids       - supplementary gids this app launches with
                    //
                    // NOTE: We prefer not to expose all ApplicationInfo flags for now.
                    //
                    // DO NOT MODIFY THIS FORMAT UNLESS YOU CAN ALSO MODIFY ITS USERS
                    // FROM NATIVE CODE. AT THE MOMENT, LOOK AT THE FOLLOWING SOURCES:
                    //   frameworks/base/libs/packagelistparser
                    //   system/core/run-as/run-as.c
                    //
    

    有了前面的英文注释,估计读者应该了解的差不多了,这里对每行使用用空格符分了六列,分别代表了每个应用六个相关的信息,如下:

    • 第一列表示安装的应用的包名:也就是AndroidManifest.xml文件中的package=”xxx.xxx.xxx”设置的内容
    • 第二列表示安装的应用userid:如果没有在AndroidManifext.xml里使用android:sharedUserId属性指定UID, 在应用安装的时候,系统会给这个应用自动分配一uid,以后应用运行时,就用这个UID运行
    • 第三列表示安装的应用是否处于调试模式:由AndroidManifext.xml里android:debuggable指定,如果没有指定则通常情况默认为非调试模式,其值为0
    • 第四列表示安装的应用的数据存放路径:一般是”/data/data/${package_name}”这样的文件夹
    • 第五列表示安装的应用的seinfo信息:这个和Android的SELinux有关(如果对于SELinux不是很熟悉的读者可以详见博客Android SELinux开发多场景实战指南有非常详细的介绍),此时的platform是它的标签,我们可以通过如下的命令进行查看:

    在这里插入图片描述

    • 第六列是安装的应用的所属的user group:如果一个应用不属于任何group, 这里的值是none。

    这里我们可以看到com.android.settings存在多个user group,这个也比较好理解就好像你,既属于国家,也属于你老婆,也属于你公司的一个组织罢了。


    1.2 packages.xml简介

    关于这块建议读者最好了解一下xml的语法,即元素,标签,属性,文本,XML树结构等概念,不是很清楚的可以简单看下博客XML树结构了解一下!

    Android安装应用信息持久化核心的文件packages.xml要登场了,我们pull到本地听过文本编辑器打开基本是一样望不到头,它非常非常的长。我看了下我当前的Android终端设备中的该文件有6000多行,这还得了我要是贴上来不会爆了去啊,所以先列出这个文件的框架,以便对它有个整体的认知,然后我们逐一分析:

    <?xml version='1.0' encoding='utf-8' standalone='yes' ?>
    <packages>
        <version sdkVersion="xxx" databaseVersion="xxx" fingerprint="xxx" />
        <version volumeUuid="xxx" sdkVersion="xxx" databaseVersion="xxx" fingerprint="xxx" />
    
        <permissions>
            <item name="android.permission.REAL_GET_TASKS" package="android" protection="18" />
            ...
        </permissions>   
        
        <package name="com.android.providers.telephony" codePath="/system/priv-app/TelephonyProvider" nativeLibraryPath="/system/priv-app/TelephonyProvider/lib" publicFlags="1007402501" privateFlags="8" ft="11e8dc5d800" it="11e8dc5d800" ut="11e8dc5d800" version="25" versionName="7.1.2" applicationName="电话和短信存储" sharedUserId="1001" isOrphaned="true">
            <sigs count="1">
                <cert index="1" key="xxx" />
            </sigs>
            <perms>
                <item name="android.permission.WRITE_SETTINGS" granted="true" flags="0" />
    			...
            </perms>
            <proper-signing-keyset identifier="1" />
        </package>  
        ...       
          
        <updated-package name="xxx.xxx.xxx" codePath="/system/app/xxx" ft="11e8dc5d800" it="11e8dc5d800" ut="11e8dc5d800" version="11" nativeLibraryPath="/system/app/xxx/lib" primaryCpuAbi="armeabi-v7a" sharedUserId="1000" />
    
    
        <shared-user name="android.media" userId="10005">
            <sigs count="1">
                <cert index="2" />
            </sigs>
            <perms>
                <item name="android.permission.ACCESS_CACHE_FILESYSTEM" granted="true" flags="0" />
                ...
            </perms>
        </shared-user>
        ...
    
        <keyset-settings version="1">
            <keys>
                <public-key identifier="1" value="xxx" />
                <public-key identifier="2" value="xxx" />
                <public-key identifier="3" value="xxx" />
    			...
            </keys>
            <keysets>
                <keyset identifier="1">
                    <key-id identifier="1" />
                </keyset>
                <keyset identifier="2">
                    <key-id identifier="2" />
                </keyset>
                <keyset identifier="3">
                    <key-id identifier="3" />
                </keyset>
    			...
            </keysets>
            <lastIssuedKeyId value="6" />
            <lastIssuedKeySetId value="6" />
        </keyset-settings>
    </packages>   
    

    虽然packages.xml行数着实有点吓人,但是我们抛开表层看本质发现该xml按照层级主要分为下面几个模块标签:

    • permission块标签: 里面包含了系统中所有定义的权限的信息
    • package块标签:里面包含了系统中所有安装的应用的详细信息
    • updated-package块标签:里面包含了被覆盖升级的系统应用的相关信息(如果系统应用存在于这个块中表示被禁用了)

    这个块非常重要,因为PKMS服务正是通过它来表明系统应用被升级了,对于这类应用的扫描会采取特殊的规则,从而根据特殊规则确定是使用系统分区的还是data分区的应用最后被安装(因为这其中可能存在着覆盖升级系统应用安装在data分区的应用被异常卸载了,或者系统分区的被root之后异常删除了等等可能的原因)

    • shared-user块标签:里面包含了所有系统定义的shareuser的信息
    • keyset-settings块标签:里面包含了已安装app签名的public key信息

    下面我们详细对其中的块的内容,详见的看下(这也是为后续PKMS服务扫描打下基础)。

    1.2.1 permissions块标签

    permissions块标签的内容如下所示:

        <permissions>
            <item name="android.permission.REAL_GET_TASKS" package="android" protection="18" />
            ...
        </permissions>   
    

    它里面定义了系统中所有的申明的权限信息,可以看到每个item标签块代表一个权限。name属性表示权限的名字,package属性表示申明权限的package, protection表示权限的级别,如normal, dangerous之类的。比较常见protection的含义如下:

    • normal:低风险权限,只要申请了就可以使用(在AndroidManifest.xml中添加标签),安装时不需要用户确认;
    • dangerous:高风险权限,安装时需要用户的确认才可使用;
    • signature:只有当申请权限的应用程序的数字签名与声明此权限的应用程序的数字签名相同时(如果是申请系统权限,则需要与系统签名相同),才能将权限授给它;
    • signatureOrSystem:签名相同,或者申请权限的应用为系统应用(在system image中)

    关于protection详细介绍可以参见源码的frameworks/base/core/res/res/values/attrs_manifest.xml的grantUriPermissions标签,其中有非常详尽的解释。在这里插入图片描述


    1.2.2 keyset-settings块标签

    我们接着来看看keyset-settings块标签内容:

        <keyset-settings version="1">
            <keys>
                <public-key identifier="1" value="xxx" />
                <public-key identifier="2" value="xxx" />
                <public-key identifier="3" value="xxx" />
    			...
            </keys>
            <keysets>
                <keyset identifier="1">
                    <key-id identifier="1" />
                </keyset>
                <keyset identifier="2">
                    <key-id identifier="2" />
                </keyset>
                <keyset identifier="3">
                    <key-id identifier="3" />
                </keyset>
    			...
            </keysets>
            <lastIssuedKeyId value="6" />
            <lastIssuedKeySetId value="6" />
        </keyset-settings>
    

    keyset-settings块标签里收集了所有安装应用签名的公钥信息,和后面介绍的package块中的信息息息相关,这里我们对keyset-settings块标签每个子标签详细介绍下:

    • keysets块标签中包含了很多keyset子标签, 每个keyset都有一个属性编号用identifier表示,keyset里包含的key-id里的identifier和上面keys中public-key的identifier的值相对应
    • keys块中public-key里的value属性值就是从应用安装包中的apk包里的签名文件里提取出来的的公钥的值
    • lastIssuedKeyId和lastIssuedKeySetId标签表示的是最近一次取出来的公钥所属的set编号

    1.2.3 shared-user块标签

    shared-user块标签在packages.xml中有好几个,我们这里以最最常见的android.uid.system为例来说明:

        <shared-user name="android.uid.system" userId="1000">
            <sigs count="1">
                <cert index="1" />
            </sigs>
            <perms>
                <item name="android.permission.BIND_INCALL_SERVICE" granted="true" flags="0" />
    			...
            </perms>
        </shared-user>
    
    • name表示这个shared-user的名字,userId表示这个user在系统中的编号,具体可以查看Process.java文件

    在这里插入图片描述


    • sigs块里的count表示这个当前这个shared-user有多少个签名信息,有的shared-user可能会被多个证书签名。cert里的index表示这个shared-user使用的证书的序号,当系统发现一个新的证书,这个号就会加1,key是shared-user使用的证书内容的ascii码值
    • perms 表示这个user所具有的权限。在开机扫描应用文件时,它会将所有使用了相同uid的应用的权限收集到一起,然后放在这里。并且最后还会把这些权限再下发给那些使用了相同uid的应用。最后的结果就是,系统中使用相同uid的应用它们具有一样的权限

    1.2.4 package块标签

    激动人心的时刻来了,还记得我们前面所说的Android系统被安装应用持久化存储管理的吗,这里的package标签就是终极答案,这里我们以安装的"支付宝"应用为例,可以看到在packages.xml中通过标签记录了一个应用的基本信息,签名和声明的权限,从而将一个安装应用的信息进行了持久化的存储。我们来对其中牵涉的标签元素来一一揭秘:

        <package name="com.eg.android.AlipayGphone" codePath="/data/app/com.eg.android.AlipayGphone-1" nativeLibraryPath="/data/app/com.eg.android.AlipayGphone-1/lib" primaryCpuAbi="armeabi" publicFlags="941112900" privateFlags="0" ft="17748d73b68" it="17748d80025" ut="17748d80025" version="146" versionName="10.1.70.8308" applicationName="支付宝" userId="10042">
            <sigs count="1">
                <cert index="6" key="30820244308201ad02044b28a3c9300d06092a864886f70d01010405003068310b300906035504061302636e3110300e060355040813076265696a696e673110300e060355040713076265696a696e67310f300d060355040a1306616c69706179310f300d060355040b1306616c69706179311330110603550403130a73686971756e2e7368693020170d3039313231363039303932395a180f32303531303131303039303932395a3068310b300906035504061302636e3110300e060355040813076265696a696e673110300e060355040713076265696a696e67310f300d060355040a1306616c69706179310f300d060355040b1306616c69706179311330110603550403130a73686971756e2e73686930819f300d06092a864886f70d010101050003818d0030818902818100b6cbad6cbd5ed0d209afc69ad3b7a617efaae9b3c47eabe0be42d924936fa78c8001b1fd74b079e5ff9690061dacfa4768e981a526b9ca77156ca36251cf2f906d105481374998a7e6e6e18f75ca98b8ed2eaf86ff402c874cca0a263053f22237858206867d210020daa38c48b20cc9dfd82b44a51aeb5db459b22794e2d6490203010001300d06092a864886f70d010104050003818100b6b5e3854b2d5daaa02d127195d13a1927991176047982feaa3d1625740788296443e9000fe14dfe6701d7e86be06b9282e68d4eff32b19d48555b8a0838a6e146238f048aca986715d7eab0fb445796bbd19360a7721b8d99ba04581af957a290c47302055f813862f3c40b840e95898e72a1de03b6257a1acad4b482cd815c" />
            </sigs>
            <perms>
                <item name="com.android.launcher3.permission.READ_SETTINGS" granted="true" flags="0" />
    			...
            </perms>
            <proper-signing-keyset identifier="7" />
        </package>
    
    • package标签,其中包含了安装应用的详细信息,我们对其中的属性来详细解读一下:

      • name:表示已安装应用的包名

      • codePath:表示的是已安装应用apk文件存放的路径,如果是系统应用app, 通常存放在system分区(也可能是vendor分区),如果是第三方app, 存在data分区

      • nativeLibraryPath表示应用的native库的存储路径

      • primaryCpuAbi:表示当前应用以哪种abi架构运行

      • publicFlags和privateFlags:是指应用的属性,如FLAG_SYSTEM、FLAG_PERSISTENT等,通常根据AndroidManifest.xml里的设置生成的,譬如android:debuggable,至于它支持那些属性可以在ApplicationInfo.java中查看,如下:
        在这里插入图片描述

      • ft:表示apk文件上次被更改的时间,

      • it:表示app第一次安装的时间

      • ut:表示app上次被更新时间,它的值好像一直和ft相同( 当应用被OTA或被重装之后,这里的ft和ut会发生变化)

      是不是被上面的英文简称搞糊涂了,请看大屏幕如下:

          serializer.attribute(null, "ft", Long.toHexString(pkg.timeStamp));
          serializer.attribute(null, "it", Long.toHexString(pkg.firstInstallTime));
          serializer.attribute(null, "ut", Long.toHexString(pkg.lastUpdateTime));
      
      • version:是app的版本号信息, 也就是在AndroidManifest.xml里配置的android:versioncode
      • userId:是为app分配的user id, 如果有使用shareUserId, 这里出现的就是SharedUserId

    • sign标签,表示已安装应用的签名信息,我们对其中的属性以及它的子标签来详细解读一下:

      • count:表示这个应用有多少个签名信息(有的应用可能会被多个证书签名)
      • cert子标签:cert里的index表示这个应用使用的证书的序号,当系统发现一个新的证书,这个号就会加1,key是应用使用的证书内容的ascii码值。PKMS在扫apk文件过程中,如果发现它和之前扫描到的apk使用的是相同的签名证书,这里就只会有个index的值,并没有key的值。拥有相同的index的package, 表明它们使用的是相同的签名

    • perms标签,表示应用声明使用的权限,每一个子标签代表一项权限,。我们对其中的属性以及它的子标签来详细解读一下:

      • item:表示当前应用所拥有的权限, 对于一般的应用,这些权限是在AndroidManifest.xml里写明的;那些使用了相同UID的应用, 这里的权限就是所有使用相同UID的应用申请的权限的总和。 granted表示这个权限是不是已经被允许

    • proper-signing-keyset标签,它的的identifier属性值就是上面说的keysets里identifier的值。它是用来标明这个应用使用的是哪个公钥,这个我们就不需要展开了

    1.2.5 updated-package块标签

    updated-package标签通常是用来存储那些系统应用被覆盖升级之后,系统应用之前被安装的信息。这块标签非常重要,因为它会决定PKMS最后到底使用的是系统分区中的应用,还是data应用目录的应用,这个是一个关键。

    这个标签可以解决我们前面提出的问题六,关于存在同包名的应用分别在data和system分区到底选择谁的问题。

        <updated-package name="xxx.xxx.xxx" codePath="/system/app/xxx" ft="11e8dc5d800" it="11e8dc5d800" ut="11e8dc5d800" version="11" nativeLibraryPath="/system/app/xxx/lib" primaryCpuAbi="armeabi-v7a" sharedUserId="1000" />
    

    至于该标签中的属性含义,可以详见前面的,这里就不再赘述了。

    1.2.6 renamed-package块标签

    renamed-package标签表示是否有被重命名的安装应用,这个标签我也一时半会解释不清楚,大伙可以详见博客Android “original-package” 机制解析机制。

    <renamed-package new="com.android.newpackage" old="com.android.original" />
        <package name="com.android.original" realName="com.android.newpackage" codePath="/system/app/NewPackage.apk" nativeLibraryPath="/system/lib/NewPackage" primaryCpuAbi="armeabi-v7a" publicFlags="940097095" privateFlags="0" ft="1774cbd5ed8" it="1774cbd0500" ut="1774cbd0500" version="1" versionName="1.0" applicationName="NewPackage" sharedUserId="1000" isOrphaned="true">
            <sigs count="1">
                <cert index="1" />
            </sigs>
            <perms>
                <item name="android.permission.BIND_INCALL_SERVICE" granted="true" flags="0" />
    			...
            </perms>
            <proper-signing-keyset identifier="1" />
    

    1.3 Android安装应用信息持久化小结

      至此我们可以回答最开始提出的几个灵魂拷问的前三问了,即Android有没有对已安装信息进行持久化,持久化的区域是什么,持久化存储的格式是什么,为什么需要持久化等。如果对于上述三个问题,读者还没有得到答案,可以继续回看一下(当然我们反过来思考,对于Android系统新安装的APK,肯定也是把新安装的APK相关信息写入这个packages.xml文件中)。

    对于上述几个持久化的文件是必要但是非必须的的,假如我们将其都进行删除,然后重启Android终端,终端依旧能正常运行。但是重启过程中会对上述文件进行重构,就好像Android设备第一次启动一样。




    二.Android安装应用信息持久化怎么被加载和管理

      Android系统这么大费周章的设计了这么一套安装应用信息持久化系统,那么对于持久化区域的信息是怎么进行加载和管理的呢?这就是本章节需要重点讨论的,我想有过一定开发经验的读者大概很容易的会想到,Android中一定存在对应的数据结构类对应上述的持久化信息特别是packages.xml中的各个标签,然后使用一个整体的数据结构来管理上述的各个标签对应的数据结构。答案是肯定的,Android系统的确是这样设计的,packages.xml中的每个标签记录信息都对应着一个特定的类,所以在正式开始分析持久化信息怎么被加载和管理前,我们又必要先来看下这其中将要涉及的类图关系图,如下:


    在这里插入图片描述


    应该读者看了前面的类图关系图,心理应该就大概有数Android系统怎么对持久化信息进行加载和管理了。即一个大标签对应一个数据结构,然后通过一个大管家类对上述的数据结构统一管理。

    下面我们对其中各种标签对应的数据结构类和管理类一一梳理梳理一下,为后续开启PKMS总攻做好准备!


    2.1 BasePermission

      BasePermission对应packages.xml中permissions标签的子标签item,对于上述所定义的每一项权限都会生成一个BasePermission,并且所有BasePermission最后都会聚集在Settigns中,其对应的标签如下:

        <permissions>
            <item name="android.permission.REAL_GET_TASKS" package="android" protection="18" />
            ...
        <permissions/>    
    

    其中BasePermission的类图如下,可以和上面的permissions标签的子标签item是一一对应的。


    在这里插入图片描述


    注意上述标签主要表明的是权限的持有者相关信息,这个信息最后会被添加到Setings大管家类mPermissions列表中统一管理。


    2.3 PermissionsState

      这个类封装了应用程序安装包或共享用户的权限,它聚合了包中所有权限的授予状态,在多用户的场景下,不同用户的授权情况不同,因此要区分出一个权限针对每个用户的授予情况,为此设计了一个数据封装类PermissionData(注意,这是单数),记录了一个BasePermission与多个用户mUserState之间的关系。每一个用户的权限授予状态用PermissionState(注意,这是单数)来记录。其中PermissionsState涉及的类图关系如下:


    在这里插入图片描述


    这里我们可以看到其中的PermissionState对应的是<package>标签中的子标签<perms>标签中的内容:

                <item name="android.permission.BIND_INCALL_SERVICE" granted="true" flags="0" />
    
    • name: 对应权限名称
    • granted: 表示赋予情况

    PermissionState和BasePermission之间牵涉到Android应用授权的关系,这个不在本章的讨论分为之内!我们可以简单理解为BasePermission为权限持有者,而PermissionState记录的是权限申请者的相关信息譬如有被授权等。关于它们之间的关系的总结墙裂建议读者参见一篇牛逼博客Android包管理机制章节3.3应用授权。


    2.4 PackageSetting

      PackageSetting这个数据结构类是packages.xml里面记录安装包信息标签<package>相对应的类,可以看到PackageSetting继承了PackageSettingBase类,PackageSettingBase类继承自SettingBase类。应用的基本信息保存在PackageSettingBase类的成员变量中,签名则保存在PackageSignatures中,权限状态保存在父类的SettingBase的PermissionsState中。

    PackageSetting中存储的应用安装信息,最终会被添加到Settings中的mPackages列表中统一进行管理。


    2.5 SharedUserSetting

      SharedUserSetting这个数据结构类是packages.xml里面记录安装包信息标签<shared-user>相对应的类,它和PackageSetting有一个共同的父类即SettingBase,即都是通过父类的PermissionsState来保存权限信息。SharedUserSetting被设计的用途主要用来描述具有相同的sharedUserId的应用信息,它的成员变量packages保存了所有具有相同sharedUserId的应用信息引用,而成员变量userId则是记录多个APK共享的UID。共享用户的应用的签名是相同的,签名保存在成员变量signatures中(这里有一点需要注意,由于签名相同,Android运行时很容易检索到某个应用拥有相同的sharedUserId的其他应用)。


    在这里插入图片描述


    这里来补充一下shareUserId与UID的关联知识:
    1、两个或多个APK或者进程声明了同一种sharedUserId的APK可以共享批次的数据,并且可以在运行在同一进程中(相当于进程是系统的用户,某些进程可以归为同一用户使用,相当于Linux系统中的GroupId)

    2、通过声明特定的sharedUserId,该APK所在的进程将被赋予指定的

    3、通过声明特定的sharedUserId,该APK所在的进程将被赋予指定的UID,将被赋予该UID特定的权限。

    4、并且有一点需要注意在pacakge的标签中sharedUserId和userId是不能共存的,因为安装应用申请了同一个sharedUserId它们的UID就已经是固定的了

    SharedUserSetting中存储的应用安装信息,最终会被添加到Settings中的mSharedUsers列表中统一进行管理。


    2.6 Settings终极大管家类

      分析到这里是不是感觉前面的数据结构还是一盘散沙,这些数据结构照科学的架构设计,是不是应该存在一个管理类,来进行全局的管理呢?毋庸置疑答案是肯定的,在PKMS的设计中存在一个这么的类就是Settings终极大管家类(注意此Setings并非设置中的Settings),Settings被设计为Android的包的全局管理者,用于协助PKMS保存所有的安装包信息,同时用于存储PKMS在执行过程中的一些设置信息。

    既然Settings这个终极大管家这么重要,那么它是是怎么管理前面的各种标签对应的数据类(即将它们聚合在一起呢),这个就离不来各种数据容器了,而这些数据容器都被定义在其成员变量中,我们先来看下它的类图,如下:


    在这里插入图片描述


    我们还是从源码入手来解读一下,它的重要成员变量

    final class Settings {
    	//被安装应用的包名为key,以安装应用相关信息为value,对应的是packages.xml中的<package>标签
        final ArrayMap<String, PackageSetting> mPackages = new ArrayMap<>();
    
    
        /*
        	对应packages.xml中的<updated-package>标签被覆盖升级的系统应用
    		其中key为被覆盖升级的应用包名,value为被覆盖升级前的安装信息
        */
        private final ArrayMap<String, PackageSetting> mDisabledSysPackages =
            new ArrayMap<String, PackageSetting>();
    
    	/*
    		对应packages.xml中的<cleaning-package> 标签用来记录那些已经删除,但是数据目录还暂时保留的应用的信息。
    		对应的是PackageCleanItem
    
        */
    	final ArrayList<PackageCleanItem> mPackagesToBeCleaned = new ArrayList<PackageCleanItem>();
    
    	// 存储所有package.xml中shared-user标签的信息
    	// 是一个以String类型的name(比如"android.uid.system")为"key",以SharedUserSetting对象为"value"的HashMap
        final ArrayMap<String, SharedUserSetting> mSharedUsers =
                new ArrayMap<String, SharedUserSetting>();
    	
    	// 存储是非系统应用的PackageSetting
        private final ArrayList<Object> mUserIds = new ArrayList<Object>();
    	
    	// 存储是系统应用的的的PackageSetting
        private final SparseArray<Object> mOtherUserIds =
                new SparseArray<Object>();
    }
    
    

    这里将Setings大管家类牵涉的核心数据摆出来,读者应该很容找到对应的关系了。但是这里Settings里面有牵涉到的四个非常重要的成员变量:mPackages,mSharedUsers,mUserIds ,mOtherUserIds 还是有必要重点介绍一下:

    • mPackages:是一个以String类型的name为"key",PackageSetting对象为"value"的ArrayMap

    • mSharedUsers:是一个以String类型的name(比如"android.uid.system")为key,ShareUserSetting对象为"value"的ArrayMap,它对应着各种常见的共享用户信息

    • mUserIds:它存储是的非系统应用的PackageSetting列表对象

    • mOtherUserIds :它存储是系统应用的的PackageSetting相关信息




    总结

      至此,"PackageManagerService详解之对已安装应用怎么进行持久化存储管理?"到这里就告一段落了,不知道我前面提出的灵魂拷问是否已经有答案了,如果没有墙裂建议读者再回过头再去看看(如果这么详细还是没有办法理解的话,那我真的也没有办法了!)。

    是不是感觉上述的描述有点平淡无奇啊,不抛出点灵魂拷问,估计读者都没有兴趣要拍屁股走人了(是时候展示点真正的技术了):
    1.PKMS对于扫描成功后的应用信息(也包括第三方安装成功的应用),有没有进行持久化的存储,进行持久化的存储位置是什么

    2.如果有进行持久化,那么持久化的形式是什么

    3.为什么PKMS需要对已经安装应用的相关信息进行持久化处理

    4.对于安装应用被持久化的信息,PKSM是怎么加载的呢

    5.PKMS服务既然是加会不会加载上述持久化的数据,如果要加载,是不是应该存在一个管理者,来全局管理,那个这个类是什么

    6.系统应用被覆盖升级(即通过普通安装升级)之后重启,PKMS是怎么辨别是使用安装在data分区的还是使用在系统分区的呢

    7.如果应用安装目录被删除了,那么PKMS对于它的数据目录会怎么处理呢

    总之读者如果想深入PKMS一定要了解它对于Android安装应用持久化管理的设计思想,因为在后续应用扫描升级,权限管理中会非常依赖这些数据。不要觉得这些不重要,一定在干一个大事件之前先处理好小细节,对于PKMS尤其如此,先把利器打磨好,才开干我想一定会取得事半功倍的成果的。

    好了,到这里“PackageManagerService详解之对已安装应用怎么进行持久化存储管理?”分析就告一段落了,各位青山不改绿水长流,各位江湖见!当然各位读者的点赞和关注是我写作路上前进的最大动力了,如果有啥不对或者不爽的也可以踩一踩也无妨!如果对PKMS感兴趣的读者可以继续下一篇章PackageManagerService启动详解(三)之BOOT_PROGRESS_PMS_START流程分析,我们接着分析!

    展开全文
  • 而现在大多数医疗制药企业都遇到不少的挑战与困难,每天会产生成百上千的文件,信息量大,文件查阅难,存储成本高,版本控制难、数据追溯难,影响协同作业,线下文件管理流程复杂,文档管理面临挑战。 医院一般都有...

    医疗制药企业也是体现一个国家综合实力的表现,像这次疫情席卷全球影响了千千万万的人,还有一些国家因为政策的问题导致治理不利,进而影响到国家影响到人民,医疗制药行业也是必须要进行全面发展提升的行业,不断的去研究不断的去探讨,最终的目的都是为了人民,造福于人类。

    而现在大多数医疗制药企业都遇到不少的挑战与困难,每天会产生成百上千的文件,信息量大,文件查阅难,存储成本高,版本控制难、数据追溯难,影响协同作业,线下文件管理流程复杂,文档管理面临挑战。

    医院一般都有不同的科室严格划分,权责分明,不同科室对于文件的访问权限不同,对文件进行精益化质量管理比较困难。

    每个医院每一年都会带实习生,那么存储的这些专业数据文档会比较容易流失,造成知识财富的浪费,数据完整性无法达到监管的要求,知识的管理面临挑战。
    在这里插入图片描述

    医药企业业务系统遇到壁垒,患者病例诊断或印象及治疗处理意见不断更新,资料频繁改动,病例原始版本管理困难。

    那么在制药生产企业内部信息化系统较多,又是彼此独立,造成数据城堡,数据共享不便。

    在制药生产过程中,从原料药到成品药的谱系和批次流转追踪不便,在生产中的偏差情况、返工情况、不合格品处理情况没有记录存档。

    生产过程中实施历史生产过程数据得不到保存,问题出现后无法查找原因和追责。

    运用企业云盘则可以解决这个问题,通过业务流程和业务表单的电子化,全面实现数据的线上采集;同时,基于权限管理,合理控制已有的电子数据,保障数据安全,从而帮助企业高效、合规地管理CAPA、偏差、变更、审计等质量流程。

    药品生产从与上游供应商的原材料采购、加工过程,成品到下游的产品,全生命周期的过程文件都存储到企业网盘,每一份文件有规范、有秩序地进行归档,实现文档集中式统一管理,沉淀文档经验,以多重加密、备份保护重要文档安全。
    在这里插入图片描述

    医药企业可以根据自己的需求,同企业内其他信息系统进行集成。与企业各信息系统打通后,各系统产生的数据集中存储到yotta平台上,在企业云盘上用户可以轻松调取各系统资料信息,实现数据在各类系统中顺畅流转和无缝对接,从而推动研发、生产、经营管理各环节信息集成和业务协同。

    同时,本地文件也可以通过同步上传到云端。信息系统、本地电脑和云端的任何文件修改,都会保持同步更新,同时保存历史版本,支持多个历史版本的保留,可以随时追溯查看。

    制药过程产出文件从新建、修改、流转到删除的整个文件生命周期都记录在文件日志中。在日志可以了解到哪些人员在什么时间对文件做了什么操作,方便追踪文件的动向,了解文件的分享流向。

    通过平台的集成能力,整合和打通企业内部各信息化系统,并对企业数据统一存储与管理,实现企业信息的集中处理和有效共享,yotta帮助医药企业实现文件统一的归档和管理,无缝对接现有的信息化系统,帮助企业完成数据资产保护从被动防御到主动管理的转变。

    展开全文
  • 怎么信息系统项目管理

    千次阅读 2008-08-29 12:33:00
    信息系统项目管理师”是 2005 年新增加的计算机软件水平专业考试的高级级别考试,考试大纲指出:通过本考试的合格人员能够掌握信息系统项目管理的知识体系,具备管理大型、复杂信息系统项目和多项目的经验和能力;...
    “信息系统项目管理师”是 2005 年新增加的计算机软件水平专业考试的高级级别考试,考试大纲指出:通过本考试的合格人员能够掌握信息系统项目管理的知识体系,具备管理大型、复杂信息系统项目和多项目的经验和能力;能根据需求组织制订可行的项目管理计划;能够组织项目实施,对项目的人员、资金、设备、进度和质量等进行管理,并能根据实际情况及时做出调整,系统地监督项目实施过程的绩效,保证项目在一定的约束条件下达到既定的项目目标;能分析和评估项目管理计划和成果;能在项目管理进展的早期发现问题,并有预防问题的措施;能协调信息系统项目所涉及的相关人员;具有高级工程师的实际工作能力和业务水平。 
    “系统分析师”、“信息系统项目管理师”和 2006 年即将开考的“系统架构师”将逐步形成三国鼎立的局面。当然“系统分析师”级别即原来的“系统分析员”级别,由于开考比较早,从影响力和报考规模上看处于明显的优势地位。但从考试大纲要求看,三个高级级别的考试对考生要求区别比较明显,应根据实际工作需要报考相应级别的考试。 “信息系统项目管理师”属于新开设的考试级别,考试不确定性因素比较多,比如对于下午一案例分析和下午二论文基本上找不到针对性很强的参考资料,这就大大增加了考生复习的难度。作者有幸参加了 2005 年上半年第一次“信息系统项目管理师”考试,并取得了
    “57/52/70”的好成绩。分享本人的考试复习经验,以帮助大家掌握有效的复习应试方法,提高复习效率,顺利通过考试。
    1.确立正确的复习应试思想
    所谓“思路决定出路!”,确立正确的应试思想很重要。我们不能为了考试而考试,也不是为了“高级工程师”证书而考试。通过考试不是我们复习和学习的唯一目的,复习备考的过程实际上是一个学习提高的过程,因为我们需要在工作和学习中不断成长。如果说自身素质、理论水平和工作能力等方面都达不到相应的水准,即使通过了考试也意义不大。所以我们应该借助考试复习的机会,结合工作实际,多学习一些实用的知识。目前软件考试已经相当成熟,与实际工作,技术发展方向都结合得越来越好,已不再停留在以前“考的不是工作中用的!”的水平。
    相信大家都是有一定项目管理理论基础和实际项目管理经验的,否则就更应该花多些时间去学习学习了。其实把项目管理的思想和方法用到考试复习上来是合情合理的事,我也知道很多朋友会潜移默化的那么去做。“信息系统项目管理师”级别考试知识点相当多,复习的根本策略是“善于分解,逐个击破”,最好有个较详细的复习进度计划,制定计划时考虑必要的缓冲时间,相信很多考生会为了遵守“项目工作上的进度计划”而占用“复习进度计划”中有工作安排的一些时间,因为我很清楚我们所在的是一个怎样的行业。优秀项目经理的基本素质要求是在工作中能严格按进度计划完成各阶段工作量,起积极的示范作用,一方面体现对工作的高度责任,另一方面体现其出众的项目计划和控制能力。你也能做到就说明你是优秀的,具有“信息系统项目管理师”的潜质,到项目结项的时候你的交付成果是“顺利通过考试”;如果你不能做到就说明你还需要努力,你的目标很明确,也是“顺利通过考试”,只是应该花更多的时间下去,“快赶工吧!”。找了个小故事,以帮助大家记住“分解”的思想。
    一只新组装的小钟放在了两只旧钟当中,两只旧钟“滴答”、“滴答”一分一秒地走着。
    其中一只旧钟对小钟说:“来吧,你也该工作了。可我有一点担心,你走完3200万次以后,恐怕便吃不消了。”
    “天哪! 3200万次!”小钟吃惊不已,“要我做这么大的事?我办不到,办不到!”
    另一只旧钟说:“你别听他胡说八道,不用走3200万次,你只要每秒钟滴答一声、摆一下就行了。”
    “天下哪有这样简单的事情,”小钟将信将疑,“如果这样,我就试试吧。”
    小钟很轻松地每秒钟“滴答”摆一下,不知不觉中,一年过去了,它轻松地摆了3200万次。
    在工作和学习中,不要强迫自己对一个庞大的目标产生自信。因为这种强迫会使自信产生太多的“水份”、一遇到困难或时间太久就会动摇甚至坍塌。如果把大目标分成一个个小目标,就可以很自然地产生自信。这样的自信才有利于目标的最终实现。“信息系统项目管理师”级别考试知识点多并不可怕,关键看你怎样合理分解,逐个击破。当然复习是需要以一定的时间为保证,如果有人说“工作实在是很忙,看书的时间也没有!”,那么请记住一句话“时间就象一块湿海绵里的水,真要挤还是有的!”。
    2.上午试题的备考建议
    扎实的信息系统项目管理综合知识是在上午试题取得合格以上分数的基本条件。上午试题主要涉及信息系统基础、信息系统项目管理、信息系统项目管理高级知识、信息化基础知识、信息安全知识、法律法规和标准规范、管理科学基础知识、项目管理师职业道德、专业英语等几个方面的知识点,考查面比较广。“信息系统项目管理师”上午试题与“系统分析师”上午试题有部分是相同的,但也突出了对“项目管理”方面知识点的考查,特别是“专业英语”的10分都以项目管理专业英语为主,2005年上半年考试“专业英语”题目全部来源于美国项目管理学院PMI的PMP认证考试试题,因此对于“专业英语”大家可以参考PMP考试的有关试题进行准备,当然也不排除命题老师和命题思路等因素而带来的变动。
    为了能顺利通过考试,项目管理综合知识复习必须到位。分析2005年上半年考试全国考生的成绩,发现很多考生因为上午试题没有达到45分而功亏一篑。基础知识不扎实,即使下午二论文写很顺手也是很难通过考试的。做人和做事都要踏实,“书也没看就过了”那是侥幸,真正优秀的人是不应该考虑侥幸的,而是讲实力,“有实力才有发言权嘛!”。
    要扎扎实实的掌握项目管理综合知识,唯一的办法就是看书了。当然看书也是要讲技巧的,回答“看什么,怎样看?”的问题。
    上午试题的复习主要以国家软考办编写的《信息系统项目管理师教程》、《信息系统项目管理师考试大纲》为主。对于《信息系统项目管理师教程》上没有涉及而考试大纲要求的知识点如“信息系统基础”、“信息化基础知识”、“法律法规和标准规范”、“管理科学基础知识”可以参考“系统分析师”的考试用书。“项目管理师职业道德”和“专业英语”可以参考PMP考试的有关资料。如果时间允许,也可以利用网络资源,按照知识点进行整理,但作者不推荐这么做。
    复习书有一堆,不能到了考试前几天还是在看一堆书。比较土的办法是“压缩”,根据考试大纲进行复习,把考试的知识点归纳出来。很多复习参考书很厚的一本,考试考到的知识点其实没几个。归纳总结一下,也就20页A4纸的内容。一般考试前2周就不用再看书了,开始看笔记和做练习题。
    有时间的话,“系统分析师”历年的上午试题最好能看一遍。虽然从考试大纲看,“系统分析师”和“信息系统项目管理师”上午试题考查知识点交叉部分不是很多。但从模块化命题的思路看,以后的考试两者共用部分试题是很正常的。

    3.下午试题一的备考建议
    下午试题一是信息系统项目管理案例分析题,属于主观题难度相对较大。2005年上半年考试试题涉及“人力资源和团队建设”、“软件变更控制和配置管理”、“项目收尾、合同管理、过程控制和项目沟通管理”等知识点。没有按照考试大纲“1题必答+4选2”的命题方式,而采用3个必答题。试题案例没有很好结合项目工程背景,而有“简单问答题”的感觉。
    在阅卷评分标志上也没有提出较严格的要求,比较有利于考生得分,考生成绩都比自己估计的要高,
    根据作者的判断:在以后的考试中,案例分析题质量将逐步提高,主要体现在案例的选择上应该能较好结合部分项目技术背景和实际工作背景,至少让考生感觉考题的案例题材是
    实实在在的工作中的问题,空洞的“简单问答题”式的案例分析实在不能够让大家接受,当然评分标准要求也应该逐步提高。“信息系统项目管理”与“系统分析师”下午一试题考查方向区别比较明显,“信息系统项目管理师”以纯项目管理实际案例问题考查为主,而“系统分析师”侧重于信息系统分析与设计方面案例,同时也可能考查项目管理方面的案例。
    对于“信息系统项目管理师”下午试题一没有特别合适的复习材料可以参考,项目管理案例分析方面的网络资源也很少。“项目管理者联盟”网站(http://www.mypm.net)上有较丰富的项目管理案例资源,可以帮助大家培养解决项目管理实际问题的能力。中国系统分析员顾问团希赛网(http://www.csai.cn)也开辟了项目管理案例分析专栏,如果你有好的项目案例也可以公布出来与大家一起分析与共享。

    4.下午二论文的备考建议
    下午试题二为信息系统项目管理方面论文,主要考查考生在信息系统项目管理方面实际工作经验。考试大纲指出:根据试卷上给出的与项目管理有关的四个论文题目,选择其中一个题目,按照规定的要求写论文和摘要。论文命题范围包括:①信息系统项目管理;②信息安全;③信息系统工程监理;④信息化战略与实施;⑤大型、复杂信息系统项目和多项目的管理;⑥项目绩效考核与绩效管理等六个方面。
    虽然2005年上半年考试下午二论文没有按照考试大纲的要求来命题,只出了单一的论文题目“论信息系统项目的需求管理和范围管理”,没有达到“四选一”的要求。第一次考试命题确实出乎考生意料,一定程度地提高了考试的难度。但考虑到命题上的因素,在评卷过程中,对评分标准做了必要的调整。根据作者的判断:在以后的考试中,将严格按照考试大纲组织试题,论文试题命题质量将逐步提高,评分标准要求也将逐步提高。
    “信息系统项目管理师”与“系统分析师”在下午试题二论文存在较大的关联性,从命题方式和评分标志上都是相同的。“系统分析师”命题范围包括:①信息系统工程;②数据库工程;③系统安全;④应用系统集成;⑤企业信息化和政府信息化;⑥新技术的应用等六个方面。其中“信息系统工程”包含“项目管理”命题点,因此“系统分析师”试卷中也可能出项目管理方面的题目。随着考试的标志化和模块化命题方式的推行,在以后的“信息系统项目管理师”与“系统分析师”考试试题中将会有相同的1-2个论文题目。分析历年“系统分析师”试题,可以发现历年考试试题中一般都有1题项目管理方面的论文。“信息系统项目管理师”的考生在复习准备论文时不妨多参考“系统分析师”考试中项目管理方面的试题,
    相信能起到事半功倍的效果。能出的题目也就是那么几个,对于信息系统项目而言,总逃不出“范围”、“进度”、“成本”、“风险”等项目管理范围。“系统分析师”历年论文命题情况请参考表1。
    (1)注重项目管理经验总结
    考生要注重项目管理经验总结,所谓“胸有成竹”,实实在在的项目经验当然是写好论文的必须的基础。实际工作中项目做多了,肚子里就有东西了。“巧妇难为无米之炊”,没有实际工作经验的考生要写好论文,就必须能巧妙的“借经验”、“借项目”。因为论文要结合实际项目,你必须那么做,而且要做到“天衣无缝”。“至于怎么借?”的问题,多读读历年的“系统分析师”样例论文吧(张友生博士主编的《系统分析师考试辅导》中就有很多论文范例),会有帮助的。工作的同时,多看一些应用和技术方面的文章,及时了解最新的技术发展趋势,养成“持续学习”的好习惯。
    (2)考前多练习
    一般为准备考试下午二的论文,只要选择 1-2 个项目就可以了。在项目的选择上注意项目规模和技术指标,尽量选择采用规模较大,技术较新的项目。在考前 1 个月就可以开始准备论文草稿,尽量提前准备,特别是部分平时没有在纸头上写字习惯的考生。因为考试时采用“方格纸”纸面考试,平时练习建议在“方格纸”上练习,严格控制练习时间。对于很多考生来说“在 2 个小时内写 3000 字”是有相当难度的,只有平时多练习,才有可能提高写作速度,写得顺手,写出合格甚至优秀的考试论文。
    (3)注意写作方法和技巧
    同时写作技巧也是很重要的,要有合理的表达项目经验的方式和方法。与“系统分析师”的论文格式相似,“信息系统项目管理师”考试论文也是有一定格式的。按照考试评分标准: “解答应分摘要和正文两部分。在书写时,请注意以下两点:①摘要字数在 400 字以内,可以分条叙述,但不允许有图、表和流程图。②正文字数为 2000 字至 3000 字,文中可以分条叙述,但不要全部用分条叙述的方式”。要想在考试下午二试题中取得高分就必须严格按照评分标志来组织论文。
    建议大家有时间读读有关论文写作方法和技巧方面的几篇文章:《系统分析员级下午试题 II(论文)解答方法》、《系统分析员--论文应试准备》和《也谈系统分析员论文试题的应试方法》(http://edu.csai.cn/rjsp/)。
    (4)摘要的写法
    实际考试中,摘要一般以 250 到 350 字为比较合理。这里提供希赛网(CSAI)软考学院(http://edu.csai.cn)辅导老师建议的两种格式:
    ①“…年…月,我参加了……项目的开发,担任……(作者的工作角色)。该项目……(项目背景、简单功能介绍)。本文结合作者的实践,以……项目为例,讨论……(论文主题),包括……(技术、方法、策略)。”
    ②“本文讨论了……系统项目的……(论文主题)。该系统……(项目背景、简单功能介绍)。在本文中首先讨论了……(技术、方法、策略),最后……(不足之处/如何改进、特色之处、发展趋势)。在本项目的开发过程中,我担任了……(作者的工作角色)。”
    建议考生在复习备考时,能按上述格式把自己工作中参与的项目,写成摘要的形式。
    (5)正文的写法
    正文部分可以分 3 部分来写,项目概要部分,论文主题部分,发挥部分。其中“项目概要部分”和“发挥部分”是固定部分,无论论文题目是什么都是项目固定的,当选择了合适的项目后就可以准备。
    如考试大纲提供的“软件开发成本花费估算”论题, 提出三个问题“①概要叙述你参与分析和开发的应用项目以及你所担任的主要工作;②论述在估算软件开发成本可以采用的方法和模型,并进一步分析这些估算方法和模型的有缺点。③详细论述在你参与分析和开发的应用项目中具体采用的估算软件开发成本的技术,方法,模型,工具及其实际效果”。
    考试时论文必须很好的回答试题提出的三个问题。根据考试命题的方式,事实上考生在考试前就可以完成 1500 字左右的固定部分和 500 字左右的发挥部分,用 1000 字来有针对性的回答考题主题部分就可以了。其中 1500 字左右的固定部分分布在以下三个方面:用于回答第一个问题“①概要叙述你参与分析和开发的应用项目以及你所担任的主要工作”,“承上起下过渡到第二个问题的部分”,“回答完第三个问题后的项目实际效果部分”。500 字左右的发挥部分主要用于针对项目的技术层面,结合技术发展趋势和项目管理经验进行。对于“信息系统项目管理师”考生而言,在论文运用“技术发展趋话题”可以达到“画龙点睛”的效果,让阅卷老师认识到作者在技术层面的深刻理解和丰富的项目管理经验。
    一般观点论文控制在 2500 字左右就可以了,但要取得 60 分以上的高分最好达到 3000 字。 对于固定部分,考生最好能在考前背诵下来,考试时只要默写出来就可以了。“花 1 个小时默写事先准备的 2000 字,还有 1 个小时用于针对主题完成 1000 字”。考前就已经准备好了2000 个字,“胸有成文”,考试时就只是体力劳动而已了。
    5.结束语
    最后,还是那句话“不能为了考试而考试”。考试只是我们督促自己学习提高的方式和手段,利用考试的机会多学习实用的东西,不断提高自身素质。对于日常工作比较忙,复习时间相对比较少的考生,建议参加合适的培训辅导,例如,希赛网(CSAI)软考学院,以增加顺利通过考试的几率。当然不要忘记“自己的努力才是最重要的”,“天下没有免费的快餐”,为顺利考试去努力吧,相信你行的。
    展开全文
  • 管理3百台服务器的方式: ... 2)使用salt、ansiable、puppet进行系统的统一调度与配置的统一管理。...3)建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。 ...
  • 1.论述信息管理的方法问题。 (1)逻辑顺序方法。逻辑顺序方法是指把信息看作资源对其进行管理,从业务角度考虑问题的逻辑顺序。这里把信息资源的管理划分为信息调查、信息分类、信息登记、信息评价四个基本步骤。 ...
  • 原创不易,看过点个赞吧前言 对于项目版本管理,你是否存在这样的痛点:项目分支多而杂不好管理,git log界面commit信息错乱复杂无规范,版本回退不知道选择什么版本合适……。 项目版本管理的最佳实践系列,笔者将...
  • 【IT168 资讯】Java Web应用程序的会话管理崩溃会涉及到以下几点:一般流程、Cookie使用情况、URL重写和会话...3. 服务器识别到请求中没有“会话相关信息/标识符”。所以它创建了一个新的会话(和一个新的会话标识符-...
  • 通过本考试的合格人员能对信息系统的功能与性能、日常应用、相关资源、运营成本、安全等进行监控、管理与评估,并为用户提供技术支持;能对信息系统运行过程中出现的问题采取必要的措施或对系统提出改进建议;能建立...
  • 时代在进步,充满新科技的东西一样一样诞生,如今多数景点,商场,超市都采用了智慧停车系统,但是我们在使用时难免会遇到问题,那么智能停车场管理系统怎么设置免费车辆信息?我们一起来了解一下。首先车子开进停车...
  • 主要包括管理图书的库存信息、每一本书的借阅信息以及每一个人的借书信 息。每一种图书的库存信息包括编号、书名、作者、出版社、出版日期、金额、 类别、总入库数量、当前库存量、已借出本数等。每一本...
  • Python实现图书管理系统功能描述1.界面分为两个部分,分别是(1)登录注册界面(2)图书管理系统界面2.用户名和密码提前存储在列表中,输入用户名或密码错误提示重新输入,未注册的需要先注册帐号密码,再进行登录。3....
  •  备考信息系统项目管理师,正确的学习方法很重要,所以下面就针对题型对学习方法做了以下总结: (一)上午选择题  上午综合题:  项目管理知识是重点。建议大家一定要重点按《每天一小时 两月拿证》的视频...
  • 实验室信息管理云平台第三方检测实验室作为企业研究中心的核心部门,随着业务的不断开展,检测数量也在不断快速的增加,每天有上千上万份样品检测的情况下仍然使用传统人工管理模式必然会带来许多问题:人工运作下...
  • 下面来说说怎么快速使用servlet +jsp进行一个简单的信息管理系统搭建吧。 二、环境 1.开发工具:eclipse (符合教学,虽然开发效率低,但是锻炼技术) 2.数据库:“MySQL 三、具体步骤 1.系统定位 (1)给系统取个名...
  • 管理信息系统 医院的化验设备 这两者是用什么技术连接的? 原理是什么?

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,697
精华内容 678
关键字:

怎么进行信息管理