项目启动会应该注意的几点

    摘要:开个好头,万事不难。项目启动会作为项目建设生命周期的开始,其意义和难度不言而喻。作为项目管理办公室的负责人,需要特别重视项目启动会的召开,杜绝走过场,避免虽然知道其重要但不知道如何才能将其开好。本文结合公司信息系统项目的实际经验,总结归纳出项目外部启动会议的目的(作用)、需要参会的人员和会上需要介绍的主要内容,为甲乙各方项目经理更好地组织和召开项目外部启动会议提供参考。

    这里的项目启动会,指的是项目外部启动会,需要甲乙双方共同考虑组织、参与的会议。

   (一) 项目启动会议所处的项目生命周期时间点
    一般而言,项目启动会议在项目招投标结束,甲方选定了项目乙方后,双方基本谈拢了合同,就会商议在合适的时间召开项目启动会。因此,项目启动会在双方签署完合同后即可召开项目启动会。

    (二)项目启动会由谁来组织
    项目启动会,由甲方来组织。具体到人,由甲方的项目管理办公室负责人来组织。但在国内,很多企业因在项目立项前期就指定了项目经理,因此项目启动会的组织工作由甲方的项目经理来负责。因在中标通知工作完毕后,项目乙方也会指定项目经理,故乙方的项目经理一般会被要求配合甲方的项目启动会工作。

    (三)项目启动会召开的场地和目的
  项目启动会议一般选择在建设方或用户方现场召开。主要是让项目建设方、用户方、监理方(如有)等项目主要干系方对该项目的整体情况(包括项目的建设背景、项目总体规划及项目团队成员等信息)有一个清晰的认识和了解,让项目各主要干系方清楚各自的职责和义务,让项目建设方、用户方在项目建设的过程中所需要给予的支持和配合给予承诺,从而让各方就项目建设的相关事宜达成共识。

    (四)与会人员有哪些
     一般而言,甲方乙方监理方的主管领导、甲方的项目团队成员、甲方业务部门代表、甲方系统用户代表、监理方团队代表、乙方项目团队成员均需要参加项目启动会。其中,甲方的副总级别人员主持项目启动会,甲乙双方的老总人员均需要在会上宣讲。
  (五)会议议程及主要内容
    A.甲方会议主持人(通常是甲方副总)宣布召开启动会议,介绍与会领导和人员,介绍会议议程。
    B.甲方项目管理办公室负责人介绍项目总体情况(项目立项、资金预算、项目招投标、项目建设周期)、项目中标方名称、甲方项目经理名称。
    C.乙方项目主管介绍项目情况和项目的建设方案,通常由乙方技术主管、总工程师、分管领导负责介绍。同时宣告乙方项目经理名字。
    D.乙方领导发言。就本项目的建设做出工作指示,许诺项目的支撑资源,向甲方保证将按质按量完成项目建设。
    E.甲方领导发言。甲方领导重申项目重视情况,并宣布项目正式启动。



    在乙方项目主管介绍项目情况和项目的建设方案时,将讲述如下内容:
     A.介绍乙方基本情况,让甲方各参与者对乙方的实力有所了解,对完成系统建设的能力充满期待。
     B.介绍项目背景,说明项目立项之前甲方存在哪些问题,进而引出现在做的工作将是为了解决XX问题。需要注意的是,介绍资料要详细列出存在哪些问题,如沟通不畅,是哪些部门/单位沟通不畅,哪些系统之间无数据或者弱数据沟通。信息孤岛,哪里存在信息孤岛,这些孤岛不串接起来会怎样?串接起来又怎样?
     C.接下来讲述将如何去解决这些问题。如在部门/单位/现有业务系统之间构建一个XXX系统(包括系统功能介绍),完成什么样的业务串联,有什么样的意义,对于甲方现有内部管理流程、服务能力、商业价值等方面有些什么样的帮助。需要注意的是,由如何解决这些问题来阐述系统建设的意义,是领导真正关心的价值点,要尽可能说明白这方面的内容。
     D.有提出了解决方案后,PPT还应该讲述期待甲方、业务单位如何配合工作,哪些工作需要甲方、业务单位积极参与。如需求调研工作,详细列出将去哪些单位了解组织架构、业务过程,希望部门/单位提供业务能手协助和讲解单位现有业务系统、现有业务流程;需求评审工作,将组织甲方业务部门代表,逐条评审确认需求说明书内容;系统用户验证测试与试运行工作,希望XXX部门/单位提供测试场地、组织测试资源,进行测试与试运行工作。同时阐述项目总体规划、项目各主要干系方的责任和义务项目存在的风险及其应对策略(包括项目实施计划、项目开展)。
     E.最后介绍乙方对项目的寄语,展望。


  

  需要注意的是,由于项目启动会议主要是信息展示而不是讨论,一般时间都比较短,因此一些需要与会各方认可或承诺的事宜,需要在启动会议前沟通清楚,否则会严重影响启动会议的效果。

   (五)总结
  能否开好项目启动会议,关键取决于前期准备工作是否做得充分和到位,当然启动会议文稿的组织、会议的形式、各发言人的临场表达也非常重要。“片言以居要,一目能传神”,愿启动会议的组织者、参与者能充分利用项目启动会议上有限的时间,达到非常的效果;同时借用项目启动会议这一契机,用团队的智慧点亮项目前进道路上的明灯。
  • 5
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论
Android-Plugin-Framework 此项目是Android插件框架完整源码以及实例。用来开发Android插件APK,并通过动态加载的方式在宿主程序中运行。 若插件APK是完全独立的APK,那么插件apk也可独立安装运行。 若插件APK不是完全独立的apk,比如和插件宿主程序共用一些依赖库,那么插件apk只能在宿主程序中运行。不可独立运行。 因为此时插件apk的代码是不完整的。 目录结构说明: PluginCore工程是插件库核心工程。用于提供对插件功能的支持。 PluginMain是用来测试的插件宿主程序Demo工程。 PluginShareLib是用来测试的插件宿主程序的依赖库Demo工程 PluginTest是用来测试的插件Demo工程。此工程下有用来编译插件的ant脚本。 宿主程序工程可以通过ant编译或者导入eclipse后直接点击Run菜单进行安装。 插件Demo工程需要通过插件ant脚本编译。编译命令为 “ant clean debug” 原因是Demo中引用了宿主程序的依赖库。需要在编译时对共享库进行排除。 插件编译出来以后,可以将插件复制到sdcard,然后在宿主程序中调用PluginLoader.installPlugin("插件apk绝对路径")进行安装 还有一种简易的安装方式,是使用编译命令为 “ant clean debug install” 直接将插件apk安装到系统中,PluginMain工程监听系统的应用安装广播,监听到插件apk安装广播后, 再自动调用PluginLoader.installPlugin("/data/app/插件apk文件.apk")进行插件安装。免去复制到sdcard的过程。 (虽然没有用过apkplug、以及另外一个插件框架作者singwhatiwanna写的DL框架,但是看过他们的一些介绍文档,感觉自己的这份实现应该是更简单易用更完善。。。哈哈,是不是有王婆卖瓜的嫌疑。) 已支持的功能: 1、插件apk无需安装,由宿主程序动态加载运行。 2、插件形式支持fragment和activity代理。 这两种形式是插件开发中的两种主要形式。 3、插件支持activity非代理模式,真正实现Activity无需注册,既不用反射,也不用代理,实现Activity完整生命周期。 4、插件库apk可无任何特殊代码。如插件中的fragment,activity等无需继承任何特定基类或接口。完全和普通app代码没有区别. 5、支持插件共用宿主程序依赖库提供的自定义控件 6、支持插件中使用自定义控件 7、支持插件资源和宿主资源混合使用。意即支持如下场景: 插件程序和宿主程序共用依赖库时插件中的布局文件中使用了宿主程序中的自定义控件,而宿主程序中的自定义控件中又使用 了宿主程序中的布局文件。 插件代码中无需做任何特殊处理,即可支持这种布局文件。 8、插件中的各种资源、布局、R、以及宿主程序中的各种资源、布局、R等可随意使用、也无任何特殊代码。 10、支持插件使用宿主程序主题和系统主题 11、解决资源id冲突问题。尝试做过插件开发的同学应该都遇到,插件资源id和宿主程序资源id可能相同,导致获取的资源不是想要的资源。 此问题其实在android提供的编译器aapt中早已提供了支持。 12、需要关注PluginTest工程的ant.properties文件和project.properties文件以及custom_rules.xml文件,插件使用宿主程序共享库,以及共享库R引用,和编译时排除的功能,都在这3个配置文件中体现 暂不支持的功能: 1、暂不支持使用插件中自定义主题, 2、支持在插件中通过R文件使用宿主程序中的资源,暂不支持插件资源文件中直接使用宿主程序中的资源。但是支持间接使用。 例如在上述“已支持的功能”6中描述的,实际就是间接使用。 后续需要解决的问题: 1、使支持插件自定义主题 2、使插件中对activity的支持更稳定。 由于此框架没有实际的项目应用,目前对activity的提供标准API的测试还不够完全,可能在其他开发场景中,activity的部分标准API可能出现问题。毕竟这里使用了很多反射,涉及到多机型多系统版本的兼容问题。后续还需要持续测试和完善 上述第2点问题已解决、请看已支持的功能第3条。 3、使支持插件资源文件中直接引用依赖库中的资源。目测可能需要重写android自带的aapt程序。 实现原理简介: 1、插件apk的class 通过构造插件apk的Dexclassloader来加载插件apk中的类。DexClassLoader的parent设置为宿主程序的classloader,即可将主程序和插件程序的class贯通 2、插件apk的资源 通过构造插件apk的AssetManager和Resouce类即可。 本项目最关键一点功能、也是和网上其他插件项目不同的地方之一,在于 通过addAssetsPath方法添加资源的时候,同时添加了插件程序的资源文件和宿主程序的资源。这样就 可以做到插件资源合并。很多资源文件都迎刃而解。 3、插件apk中的资源id 完成上述第二点以后,还有需要解决的难题,是宿主程序资源id和插件程序id重复的问题。 这个问题解决办法也很简单 我们知道,资源id是在编译时生成的,其生成的规则是0xPPTTNNNN PP段,是用来标记apk的,默认情况下系统资源PP是01,应用程序的PP是07 TT段,是用来标记资源类型的,比如图标、布局等,相同的类型TT值相同,但是同一个TT值不代表同一种资源,例如这次编译的时候可能使用03作为layout的TT,那下次编译的时候可能使用06作为TT的值,具体使用那个值,实际上和当前APP使用的资源类型的个数是相关联的。 NNNN则是某种资源类型的资源id,默认从1开始,依次累加。 那么我们要解决资源id问题,就可从TT的值开始入手,只要将每次编译时的TT值固定,即可是资源id达到分组的效果,从而避免重复。 例如将宿主程序的layout资源的TT固定为03,将插件程序资源的layout的TT值固定为23,即可解决资源id重复的问题了。 固定资源idTT值的版本也非常简单,提供一份public.xml,在public.xml中指定什么资源类型以什么TT值开头即可。 具体public.xml如何编写,可参考PluginMain/res/values/public.xml 以及 PluginTest/res/values/public.xml俩个文件,它们是分别用来固定宿主程序和插件程序资源id的范围的。 4、插件apk的Context 构造一个Context即可,具体的Context实现请参考PluginCore/src/com/plugin/core/PluginContextTheme.java 关键是要重写几个获取资源、主题的方法,以及重写getClassLoader方法 5、插件中的LayoutInfalter 通过第4步构造出来的Context获取LayoutInfater即可 6、如何实现插件代码不依赖任何特殊代码,如继承特定的基类、接口等。 要做到这一点,最主要的是实现上述第4步,构造出插件的Context后,所有问题都可以得到解决。 7、插件中Activity无需注册,拥有完整生命周期是如何实现的。 众所周知、Activity是系统组件,必须在manifest中注册才能被系统唤起并拥有完整生命周期,通过Activity代理和放射的方式实现的 实际是伪生命周期。并非完整生命周期。那么如果才能实现activity免注册,而且拥有完整的生命周期呢,这要从activity的启动流程中 入手。 App安装时,系统扫描app的Manifest并缓存到一个xml中,activity启动时,系统现在查找缓存的xml,如果查到了,再通过classLoad去load这个class,并构造一个activity实例。那么我们只需要将classload加载这个class的时候做一个简单的映射,让系统以为加载的是A class,而实际上加载的是B class,达到挂羊头买狗肉的效果,即可将预注册的Aclass替换为未注册的activity,从而实现插件中的Activity 完全被系统接管,而拥有完整生命周期。 在PluginMain和PluginTest已经添加了这种实现方式的测试实例。 8、通过activity代理方式实现加载插件中的activity是如何实现的 要实现这一点,同样是基于上述第4点,构造出插件的Context后,通过attachBaseContext的方式,替换代理Activiyt的context即可。 另外还需要在获得插件Activity对象后,通过反射给Activity的attach()方法中attach的成员变量赋值。 这样可解决另外一个插件框架作者singwhatiwanna实现的代码中所谓this和that的问题。也是可以使插件Activity不需要继承任何特定基类或者接口的原因。 9、activity代理实现后,其他组件,如service等,如法炮制即可。 10、插件编译问题。 如果插件和宿主共享依赖库,那边编译插件的时候不可将共享库编译到插件当中,包括共享库的代码以及R文件,但是需要在编译时添加到classpath中,且插件中如果要使用共享依赖库中的资源,需要使用共享库的R文件来进行引用。这几点在PluginTest示例工程中有体现。 11、插件开发模式 插件UI可通过fragment或者activity来实现 如果是activity实现的插件,则最终在PluginProxyActivity中运行 如果是fragment实现的插件,又分为两种 1种是fragment运行在任意支持fragment的activity中,这种方式,在开发fragment的时候,fragmeng中凡是要使用context的地方,都需要使用通过PluginLoader.getPluginContext()获取的context,那么这种fragment对其运行容器没有特殊要求 还有1种是,fragment运行在PluginCore提供的PluginSpecDisplayer中,这种方式,由于其运行容器PluginSpecDisplayer的Context已经被PluginLoader.getPluginContext获取的context替换,因此这种fragment的代码和普通非插件开发时开发的fragment的代码没有任何区别。 需要注意的问题 项目插件开发后,特别需要注意的是宿主程序混淆问题。宿主程序混淆后,可能导致插件程序运行时出现classnotfound 标签:Android
1. 前言CIDRAM (无类别域间路由访问管理器)是一个PHP脚本,旨在保护网站途经阻止请求该从始发IP地址视为不良的流量来源,包括(但不限于)流量该从非人类的访问端 点,云服务,垃圾邮件发送者,网站铲运机,等等。它通过计算CIDR的提供的IP地址从入站请求和试图匹配这些CIDR反对它的签名文件(这些签名文件包 含CIDR的IP地址视为不良的流量来源);如果找到匹配,请求被阻止。CIDRAM COPYRIGHT 2013 and beyond GNU/GPLv2 by Caleb M (Maikuolan)。本脚本是基于GNU通用许可V2.0版许可协议发布的,您可以在许可协议的允许范围内自行修改和发布,但请遵守GNU通用许可协议。使用脚本的过程中,作者不提供任何担保和任何隐含担保。更多的细节请参见GNU通用公共许可证,下的LICENSE.txt文件也可从访问:http://www.gnu.org/licenses/。http://opensource.org/licenses/。现在CIDRAM的代码文件和关联包可以从以下地址免费下载GitHub。2. 如何安装我可能在将来创建一个安装程序来简化安装过程,但在之前,按照下面的这些安装说明能在大多数的系统和CMS上成功安装:1) 在阅读到这里之前,我假设您已经下载脚本的一个副本,已解压缩其内容并保存在您的机器的某个地方。现在,您要决定将脚本放在您服务器上的哪些文件夹中,例如/public_html/cidram/或其他任何您觉得满意和安全的地方。上传完成后,继续阅读。。2) 重命名config.ini.RenameMe到config.ini(位于内vault),和如果您想(强烈推荐高级用户,但不推荐业余用户或者新手使用这个方法),打开它(这个文件包含所有CIDRAM的可用配置选项;以上的每一个配置选项应有一个简介来说明它是做什么的和它的具有的功能)。按照您认为合适的参数来调整这些选项,然后保存文件,关闭。3) 上传(CIDRAM和它的文件)到您选定的文件夹(不需要包括*.txt/*.md文件,但大多数情况下,您应上传所有的文件)。4) 修改的vault文件夹权限为“755”。注意,主文件夹也应该是该权限,如果遇上其他权限问题,请修改对应文件夹和文件的权限。5) 接下来,您需要为您的系统或CMS设定启动CIDRAM的钩子。有几种不同的方式为您的系统或CMS设定钩子,最简单的是在您的系统或CMS的核心文件的开头中使用require或include命令直接包含脚本(这个方法通常导致在有人访问时每次都加载)。平时,这些都是存储的在文件夹中,例如/includes,/assets或/functions等文件夹,和将经常被命名的某物例如init.php,common_functions.php,functions.php。这是根据您自己的情况决定的,并不需要完全遵守;如果您遇到困难,访问CIDRAM支持论坛和发送问题;可能其他用户或者我自己也有这个问题并且解决了(您需要让我们您在使用哪些CMS)。为了使用require或include,插入下面的代码行到最开始的该核心文件,更换里面的数据引号以确切的地址的loader.php文件(本地地址,不是HTTP地址;它类似于前面提到的vault地址)。(注意,本人不是PHP程序员,关于这一段仅仅是直译,如有错误,请在对应项目上提交问题更正)。<?php require '/user_name/public_html/cidram/loader.php'; ?>保存文件,关闭,重新上传。-- 或替换 --如果您使用Apache网络服务器并且您可以访问php.ini,您可以使用该auto_prepend_file指令为任何PHP请求创建附上的CIDRAM。就像是:auto_prepend_file = "/user_name/public_html/cidram/loader.php"或在该.htaccess文件:php_value auto_prepend_file "/user_name/public_html/cidram/loader.php"6) 这就是一切! :-)3. 如何使用CIDRAM 应自动阻止不良的请求至您的网站,没有任何需求除了初始安装。更新是手工完成,和您可以定制您的配置和您可以定制什么CIDR被阻止通过修改您的配置文件和/或您的签名文件.如果您遇到任何假阳性,请联系我让我知道这件事。
注意:本项目使用android studio开发,eclipse可能无法使用。 豆芽的名字取自“Douban, Yet Another”的缩写和中文词语“豆芽”的拼音正好相同的巧合。 取名之后,我才得知豆瓣的 Windows Phone 客户端的名字也叫做“豆芽”。所以相对于豆瓣官方应用“一个叫‘豆瓣’的App”,也正好将这个应用称为“另一个叫豆芽的应用”了。 为什么要有豆芽? 直接访问豆瓣的所有人里,最普遍而一致的用法是围绕电影、电视、书、唱片、活动(我们叫做”条目”的东西)的评分评论、发现和讨论。我们把和网站同步的评分评论作为一个起点和基础,在手机上重新构建围绕个人兴趣的发现和讨论。 一个叫“豆瓣”的App——豆瓣日志 豆瓣从来不是一个单一的网站,而对于豆瓣的用法自然不尽相同。使用豆瓣是为了获取信息,但信息的获取是基于条目和算法,还是基于友邻和人,这个问题在豆瓣的多次改版中大概一直悬而未决。 这次,一个叫“豆瓣”的应用选择的是基于条目的推荐。但我个人作为一个重度豆瓣用户,重视的却恰好是基于人的推荐,喜欢的是友邻间的鸡犬相闻,以及闲逛时从条目评论、广播、日记中发现新友邻的惊喜。正如我在某次“还我旧版”运动中听到的声音,“不管怎么改版,只要友邻们还在就好”,改版是豆瓣不断良好发展的必经之路,但这句话中对友邻的珍重又令我感受到了豆瓣最宝贵的特质。 豆瓣作为一个工具的价值可以通过条目很好体现,但豆瓣作为一个独一无二的社区,只能通过它独有的、克制的、以人为本的方式才能维系。作为一个普通但也深爱豆瓣的用户,我希望豆瓣在这个方向上也不要失落,因为一个只有工具属性的网站对我而言将再也没有这样的归属感。 我在这一点上与豆瓣应用有了不同的追求,并且恰好有一些这方面的能力,又恰好豆瓣提供了开放的 API,于是就想要将这个想法实现出来了。 选择开始豆芽这个项目,还有一个原因是我希望在豆瓣继续看到平台原生的设计。 豆瓣广播在几年前就已经是国内少有的几个 Android Design 的应用,这一点一直令我钦佩和喜爱。在豆瓣应用最开始的版本中,也曾有过 Material Design 的尝试,但随着和 iOS 风格设计的杂糅,逐渐显得不合时宜,以至于最终选择了完全的 iOS 风格。我对此一直感到有些遗憾,况且 Material Design 也是一款更加优秀的设计语言。所以,我希望实现未能见到的另一种可能性。 部分特性 Material Design 首页友邻广播 启动速度优化 界面动画 支持屏幕旋转 平板多列视图 支持使用 Custom Tabs 打开网页 支持切换长/短链接显示 关于名字 指导原则 豆芽的最终目标是为豆瓣中基于友邻的信息获取方式提供在移动端的便利。为了优雅地实现这个目标,豆芽将主要遵循以下的原则: 遵循 Material Design 规范,且指导思想优先于细节规定。 像素完美,但更注重以人为本。 实现精确,代码可以自我辩护。 行为合格,支持屏幕旋转和平板布局。 功能崇尚简约,不打扰用户。 行为默认值合理,且用户可调节。 积极表现豆瓣特性,如广播、友邻、豆邮等。 通过细节设计,提倡用心、考虑到他人的内容。 规则可以被打破,但前提是理解规则。 功能架构 豆芽的架构将与当前网站的设计十分类似。 你可能问,难道豆芽只是要做一个豆瓣网站的移动端界面么?并非如此。豆芽的最终目标是为基于友邻的信息获取方式提供便利,所以架构设计也是为此服务。而架构与当前网页端设计基本相同,则是因为现在网页端正是一个符合这个目标的设计,并且与移动端的导航也可以很好地契合。 让我们详细地规划一下豆芽吧。 导航采用抽屉一级导航 选项卡二级导航的方式。工具栏上将显示全局的动作。 工具栏 提醒:所有类别的提醒,可以查看历史提醒 豆邮:用户间的邮件往来,希望鼓励郑重而非聊天。 搜索:立即访问想要的内容。 用户:点击后显示个人页面,相当于“我的豆瓣”。 首页 友邻广播:友邻互动、友邻推荐、系统定制的推荐。 九点:友邻的日记、博客文章等,有深度的内容。 一刻:全站范围的热门内容推荐。 同城:基于地理位置的内容。 线上活动:基于共同兴趣的内容。 读书 分类浏览、首页推荐:入口,以及最有可能发现新内容的地方。 我读:管理自己的读书标记、创造内容。 动态:查看友邻的阅读动态,互动、获得推荐。 豆瓣猜:基于算法的推荐。 电影 类似读书。 音乐 类似读书。 设置:提供应用设置等。 在子页面设计中,豆芽将尽量鼓励长内容和用心的互动。因为我相信只有豆瓣值得这样尝试。 实现状况 我在最初的二十天内冲刺实现了应用的网络层、账户系统等基础架构,和查看友邻广播需要的大部分功能,大约 8000 行代码。 在接下来的八十天中,由于课业、其他事情和速度瓶颈,实现过程有所减慢。但是,应用的细节功能和界面交互都正在不断地被实现和优化。代码量达到了 14000 行,同时为此应用而写作的多个开源库的数千行代码并没有被计入。 此后项目经历了大型的重构,以适应代码复用和支持屏幕旋转的需求。在此之后,我得以实现了一个较为美观的个人资料页,并且对应用的许多细节进行了完善。 目前实现了原“豆瓣广播”应用的大部分功能。剩下的工作也正在继续进行中。 实现架构 数据层面 应用除了对少数内容进行缓存,其他内容均直接从网络获取。 基于 Android 账户系统提供用户账户和身份认证。 使用 Volley 及部分自定义增强处理网络请求。 使用 Gson 自动填充数据模型。 使用 Glide 加载图片。 使用 DiskLRUCache 及自定义增强对首页数据进行缓存。 使用 EventBus 同步不同页面间对象状态。 界面层面 使用 Support Library 中的 AppCompat、Design、CardView、RecyclerView 进行 Material Design 实现,在必要时引入/自己写作第三方库以实现部分界面元素和效果。 使用框架的 Shared Element Transition 实现在 Android 5.0 以上的界面过渡动画。 界面实现一般分为 Activity、Fragment、Adapter 三个模块,分别负责作为容器,发起请求、展示数据和用户交互,以及数据/交互绑定。 实现难点 网络请求 Volley 本身是一个不算十分完备的库,对于请求参数、重试、认证等方面都需要开发者自己实现。在豆芽中,应用对 Volley 进行了包装,增加了以上功能,并且尽力做到了通用,为之后 API 层建立提供了很多方便。 磁盘缓存 DiskLRUCache 是一个只实现了同步读取写入的库,因此豆芽对其进行了包装,提供了异步读写的 API,正确实现,提高了应用的响应速度。 状态同步 由于各个界面独自获取数据,数据本身与常规的 ContentProvider 机制中不同,是去中心化的,即可能遇到状态不同步的问题。 具体地说,即有可能用户在广播详情界面中点赞后,回到主界面列表视图,发现并未更新状态。 而豆芽解决方案则是使用 EventBus,在请求完成后通知所有界面刷新同一数据。 界面动画 Android 5.0 以上提供了 SharedElementTransition,然而默认情况下共享的界面元素在动画时却被放置在其他界面元素之上,导致其突然越过 AppBar 或 StatusBar 的情况。 通过大量的文档阅读、源代码分析和调试,经过大约一周的时间,最终实现了较为理想的效果。 屏幕旋转 Android 在屏幕旋转时,销毁视图和 Activity 并重建,此时如何保存视图状态和已加载的数据、正在进行的网络请求即是问题。 Android 对部分视图状态提供了自动保存恢复,而豆芽对于其他需要保存的状态则通过自定义的 onSaveViewState() 和 onRestoreViewState()。 对于数据,豆芽通过自定义的一个无界面的 RetainDataFragment 进行数据保留,并且接口十分简单易用。 同时,由于网络请求的异步特性,豆芽通过自定义的一个 RequestFragment 实现了网络请求在 Activity 重建期间的保留,并且能够在 Activity 重建完成后将请求前的状态和请求结果回调至新的 Activity。 平板适配 Android 本身的资源系统提供了对不同配置的很好支持,通过建立不同的资源文件,即可在手机和平板上使用不同的界面设定。 此外,由于采用了 RecyclerView,通过在运行时判断当前设备配置,可以动态给界面设置为 1、2、3 列视图,充分利用屏幕空间。 启动速度 Android 默认在冷启动应用进程至能够调用 Activity.onCreate() 前加载应用主题中的背景作为预览,而默认背景是白色,与应用在上部拥有绿色 AppBar 的效果不相匹配。 为了生成适应于不同屏幕大小、系统版本的图片,我使用 bash 编写了一系列脚本,并实现了一个通用的模板化 SVG 格式,详情见 MaterialColdStart 和 AndroidSVGScripts。 经过自定义窗口背景和其他优化,应用在手机上已经可以达到立即启动的视觉效果。 派生开源库 为此项目诞生的五个开源库: MaterialColdStart,800 Stars MaterialProgressBar,500 Stars CustomTabsHelper,200 Stars MaterialEditText SystemUiHelper 第三方库 PhotoView Glide Gson ButterKnife DiskLruCache ThreeTenABP Volley EventBus CustomTabsHelper MaterialEditText MaterialProgressBar SystemUiHelper MaterialColdStart 构建 APK 文件可以在本项目的 Releases 中找到。 至于手动构建本项目的基本步骤: 创建 signing.properties: storeFile=YOUR_STORE_FILE storePassword= keyAlias= keyPassword= 执行 ./gradlew build。 使用 安装应用后,请安装 豆芽 API Key 设置向导 以设置 API Key。 暂时没有内置的更新渠道,请关注本项目的 Release。 请不要安装从不可靠的来源获取的 APK,以免泄漏您的用户名和密码。 本项目git地址:https://github.com/DreaminginCodeZH/Douya

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

机场信息系统研究员

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值