1.创建自己的ContentProvider,需要继承ContentProvider类
2.如果你的数据和已存在的ContentProvider数据结构一致,可以将数据写到已存在的ContentProvider中
当然前提是获取写该ContentProvider的权限.比如把OA中的成员通讯信息加入到系统的联系人ContentProvider中
ContentProvider基础
所有ContentProvider都需要实现相同的接口,用于查询ContentProvider并返回数据.也包括增加、修改和删除数据.
步骤:
1.获得一个ContentResolver的实例,可通过Activity的成员方法getContentResovler()方法:
ContentResolver cr = this.getContentResolver()
ContentResolver实例带的方法可实现找到指定的ContentProvider并获取到ContentProvider的数据
ContentResolver的查询过程开始,Android系统将确定查询所需的具体ContentProvider,确认它是否启动并运行它.
android系统负责初始化所有的ContentProvider,不需要用户自己去创建.实际上,ContentProvider的用户都不可能直接访问到ContentProvider实例,只能通过ContentResolver在中间代理.
2.数据模型
ContentProvider展示数据类似一个单个数据库表.
其中:
每行有个带唯一值的数字字段,名为_ID,可用于对表中指定记录的定位.
ContentProvider返回的数据结构,是类似JDBC的ResultSet,在android中,是Cursor对象.
URI,每个ContentProvider定义一个唯一的公开的URI,用于指定到它的数据集.
一个ContentProvider可以包含多个数据集(可以看作多张表),这样,就需要有多个URI与每个数据集对应.
这些URI要以这样的格式开头:
content://
表示这个URI指定一个ContentProvider.
如果你想创建自己的ContentProvider,最好把自定义的URI设置为类的常量,这样简化别人的调用,并且以后如果更新URI也很容易.
android定义了CONTENT_URI常量用于URI,如:android.provider.Contacts.Phones.CONTENT_URI
2.查询ContentProvider
要想使用一个ContentProvider,需要以下信息:
定义这个ContentProvider的URI,返回结果的字段名称,这些字段的数据类型
如果需要查询ContentProvider数据集的特定记录(行),还需要知道该记录的ID的值.
构建查询
查询就是输入URI等参数,其中URI是必须的,其他是可选的,如果系统能找到URI对应的ContentProvider将返回一个Cursor对象.
可以通过ContentResolver.query()或者Activity.managedQuery()方法.
两者的方法参数完全一样,查询过程和返回值也是相同的.
区别是,通过Activity.managedQuery()方法,不但获取到Cursor对象,而且能够管理Cursor对象的生命周期.
比如当Activity暂停(pause)的时候,卸载该Cursor对象,当Activity Restart的时候重新查询.另外,也可以对一个没有处于Activity管理的Cursor对象做成被Activity管理的,通过调用Activity.startManaginCursor()方法.
类似这样:
Cursor cur = managedQuery(myPerson,null,null,null,null)
其中第一个参数myPerson是Uri类型实例.
如果需要查询的是指定行的记录,需要用_ID值,比如ID值为23,URI将是类似:
content://....../23
android提供了方便的方法,让开发者不需要自己拼接上面这样的URI,比如类似:
Uri myPerson = ContentUris.withAppendedId(People.CONTENT_URI,23)
或者:
Uri myPerson = Uri.withAppendedPath(People.CONTENT_URI,"23")
二者的区别是一个接收整数类型的ID值,一个接收字符串类型.
其他几个参数：
names,可以为null,表示取数据集的全部列,或者声明一个String数组,数组中存放列名称,比如:People._ID.一般列名都在该ContentProvider中有常量对应
针对返回结果的过滤器,格式类似于SQL中的WHERE子句，区别是不带WHERE关键字，如果返回null表示不过滤，比如name=?
前面过滤器的参数,是String数组,是针对前面条件中?占位符的值
排序参数,类似SQL的ORDER BY字句,不过不需要写ORDER BY部分,比如name desc,如果不排序,可输入null.
返回值是Cursor对象,游标位置在第一条记录之前.
下面实例适用于android 2.0及以上版本,从android通讯录中得到姓名字段:
java代码：
Cursor cursor = getContentResolver().query(ContactsContract.CommonDataKinds.Phone.CONTENT_URI,null,null,null,null)
读取返回的数据
如果在查询的时候使用到ID,那么返回的数据只有一条记录.在其他情况下,一般会有多条记录.和JDBC的ResultSet类似,需要 *** 作游标遍历结果集,在每行,再通过列名获取到列的值,可以通过getString()、getInt()、getFloat()等方法获取值.
比如类似下面:
java代码:
while(cursor.moveToNext()) {
builder.append(cursor.getString(cursor.getColumnIndex(ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME))).append("-")
}
和JDBC中不同,没有直接通过列名获取列值的方法,只能先列名获取到列的整型索引值,然后再通过该索引值定位获取列的值.
编辑数据
可以通过ContentProvider实现以下编辑功能:
增加新的记录:
在已经存在的记录中增加新的值、批量更新已经存在的多个记录、删除记录.
所有的编辑功能都是通过ContentResolver的方法实现.一些ContentProvider对权限要求更严格一些,需要写的权限,如果没有会报错.
增加记录
要想增加记录到ContentProvider,首先,要在ContentValues对象中设置类似map的键值对,在这里,键的值对应ContentProvider中的列的名字,键值对的值,是对应列希望的类型.
然后,调用ContentResolver.insert()方法,传入这个ContentValues对象,和对应ContentProvider的URI即可.返回值是这个新记录的URI对象.这样你可以通过这个URI获得包含这条记录的Cursor对象.
比如:
java代码：
ContentValues values = new ContentValues()
values.put(People.NAME,"Abraham Lincoln")
Uri uri = getContentResolver().insert(People.CONTENT_URI, values)
在原有记录上增加值
如果记录已经存在,可在记录上增加新的值,或者编辑已经存在的值.
首先要找到原来的值对象,然后要清除原有的值,然后像上面增加记录一样即可:
java代码：
Uri uri = Uri.withAppendedPath(People.CONTENT_URI, "23")
Uri phoneUri = Uri.withAppendedPath(uri, People.Phones.CONTENT_DIRECTORY)
values.clear()
values.put(People.Phones.TYPE, People.Phones.TYPE_MOBILE)
values.put(People.Phones.NUMBER, "1233214567")
getContentResolver().insert(phoneUri, values)
批量更新值
批量更新一组记录的值,比如NY改名为Eew York.可调用ContentResolver.update()方法.
删除记录
如果是删除单个记录,调用ContentResolver.delete()方法,URI参数,指定到具体行即可.
如果是删除多个记录,调用ContentResolver.delete()方法,URI参数指定Contentprovider即可,并带一个类似SQL的WHERE子句条件.这里和上面类似,不带WHERE关键字.
创建自己的ContentProvider
创建contentprovider,需要设置存储系统.大多数ContentProvider使用文件或者SQLite数据库,不过你可以用任何方式存储数据.android提供SQLiteOpenHelper帮助开发者创建和管理SQLiteDatabase.
继承ContentProvider,提供对数据的访问.在manifest文件中声明ContentProvider.继承ContentProvider类
必须定义ContentProvider类的子类,需要实现如下方法:
java代码:
query()
insert()
update()
delete()
getType()
onCreate()
在实现子类的时候,还有一些步骤可以简化ContentProvider客户端的使用:
定义public static final Uri常量,名称为CONTENT_URI:
java代码:
public static final Uri CONTENT_URI = Uri.parse("content://com.example.codelab.transportationprovider")
如果有多个表,它们也是使用相同的CONTENT_URI,只是它们的路径部分不同.
声明ContentProvider
创建ContentProvider后,需要在manifest文件中声明,android系统才能知道它,当其他应用需要调用该ContentProvider时才能创建或者调用它.
语法类似:
<provider android:name="com.easymorse.cp.MyContentProvider"
android:authorities="com.easymorse.cp.mycp">
</provider>
android:name要写ContentProvider继承类的全名.
android:authorities要写和CONTENT_URI常量的B部分
2021年6月2日，对于华为和很多关心华为的人来说，都是一个重要的日子，因为千呼万唤的华为鸿蒙 *** 作系统（HarmonyOS）正式发布，虽迟但到。就像HDC 2019上鸿蒙初次发布那样，准随着它的争议从未消失，且更随着手机鸿蒙系统的推出在即，有愈演愈烈之势。
在HDC 2019之后，我曾写过一篇《关于华为鸿蒙系统的那些事儿》的文章，此时此刻，我觉得是时候再说说华为鸿蒙系统那些事儿了——虽然我知道，在这个当口，写这样一篇文章很可能给我自己挖一个大坑……
不搞懂Android，你就看不懂鸿蒙
关于鸿蒙的最大争议点无非就是：“HarmonyOS是不是套壳Android？”要说不是，不服气的人肯定大把，要说是，那也一样不得了，那就一层层地说清楚。首先，让我们看看Google手中的Android *** 作系统是怎么回事。
回顾一下Android *** 作系统的起源。它是由知名IT人Andy Rubin于2003年10月成立的Android公司推出的产品，其本身是基于Linux内核开放源代码的 *** 作系统；2005年8月，Google收购了Android公司；2007年11月，Android *** 作系统首次亮相，同时Google宣布以Apache免费开源许可证的授权方式，发布Android的源代码，Google牵头的OHA也正式创立（OHA，Open Handset Alliance，该组织最初由34家手机制造商、软件开发商、电信运营商以及芯片制造商共同组成）；2008年9月，Android 1.0版本正式推出，首款Android智能手机G1发布，宣告了一个新的时代开启。现在，Android *** 作系统已经成为智能手机市场第一大 *** 作系统，也广泛使用在智能手机之外的很多设备上。
Android的起源和开源两个字分不开。是的，Android系统底层所使用的Linux内核，是必须遵照GPL协议进行开源传播的(GPL协议，General Public License，简称GPL，通用性公开许可证)。这个协议中的一项原则就是：确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。
因此，采用Linux内核的Android *** 作系统，也不能违反这个协议， 前边提到的Android免费开源许可证授权，就是指Google要向使用该 *** 作系统的智能手机厂商提供开放的源代码，即AOSP（Android Open Source Project），但这部分源代码并不代表“Android” *** 作系统的全部。
Google当初看上Android，可不是想要将这个开源系统作为一个免费的“慈善”项目来推动，而是在意Android这个平台的商业化潜力。于是，在收购了Android系统之后，Google就按自己的设想打造Android系统，即在开源代码的部分之外，基于自家在移动互联网上强大的控制力，把Gmail、Maps、Google Play、YouTube、Chrome这些我们耳熟能详的应用服务整合为GMS（Google Mobile Services）服务包植入，从而形成了这个系统的核心竞争力—— 简单理解Android系统的本质，就是AOSP+GMS的合体。
换句话说，智能手机厂商可以自由使用AOSP提供的免费源代码进行自家 *** 作系统的开发，但想要卖得好，拥有更多的用户，却离不开GMS包含的应用，在Android的商业模式中，Google有一套严格的机制在免费开源与付费授权之间取得平衡的。
之前有数据显示，从2008年~2016年间，Android *** 作系统为Google供贡献了高达310亿美元的营收，而利润更是高达220亿美元，也就是说，数以亿计的搭载Android *** 作系列和GMS服务包的智能硬件们，都成为了Google帝国的现金奶牛。
只是，Google这个庞大的商业帝国，却总有不能企及的地方——中国大陆。早年因为不愿意服从法律监管，Google几乎将整个互联网服务都移出了中国大陆市场，但是Android *** 作系统却随着移动互联网和智能手机的发展，在中国市场壮大。
这里有一个非常有意思的现象：因为Google不能在中国提供服务，中国的智能手机厂商们，早就习惯了自主开发没有GMS，但又包含完整本地化服务的自主UI，但因为要面向全球市场，所以又会在自主UI中保留Google GMS框架，这样就可以在海外市场很方便地接入GMS并激活一系列的服务。
因为GMS服务不能进入中国大陆市场，手机厂商们会在这个基础上接入很多自己的服务，比如应用商店、主题商店、内容、支付、推送等，可是没有Google Play的应用审核机制，国内的软件生态是啥样大家都看到的，到最后手机厂商自己都受不了了，才有了“统一推送联盟”、“软件绿色联盟”之类的组织，且随着国家监管力度的加强，现在已经好多了。
随着Android的市场地位越来越强，Google也开始做一些小动作——毕竟这家公司的口号在2015年就从“Do not be evil”变成了“Do the right thing”。如将一些关键特性和重要代码的更新放入GMS包的版本迭代中，比如部分组件、驱动等，有意拉开Android与AOSP的代数差距，从而凸显自己的地位，进一步强化对Android生态的控制力。所以，为了能让自家的UI能有更强的市场竞争力，智能手机厂商们对Android的魔改从来就没有停止过。
回到华为。2019年5月16日，华为被美国商务部列入实体清单，被视为美国对华为终极打压的开始，首当其冲的就是销往全球的华为新款手机不能再使用Android系统。
是的，华为的确是不能使用Google的Android *** 作系统了，但更具体的描述应该是： “华为不能在自家手机新品中内置GMS服务，但AOSP源代码的使用丝毫不受影响”， 而非那段时间盛传的华为手机从此变砖。但是，无法内置GMS，对于华为手机在全球市场的销售影响是实实在在的，但好在对于系统本身进化影响并不大——现在让我们来到第二个话题：“华为掏空Android。”
华为真的掏空了Android？
华为是否掏空了安卓？这应该是每过一段时间就会被拉出来遛一圈儿的问题。其实在我看来， 答案：是也不是。为什么说不是？因为AOSP还在呢，华为从来没有说过要排斥这个开源项目的，毕竟在这个软件生态上运行着数以百万计的应用，真要把这个掏了，难不成华为要自己做一个全新的软件生态，脑子抽了还差不多。为什么说是？因为华为对Android *** 作系统的改变也是真实的，很多谷歌做的东西，很多都被华为自己的东西替代了。
这个涉及一个主角， 即EMUI，华为自主开发的UI，或者说两个主角也行，EMUI+HMS。 在这其中，现任华为消费者BG软件部总裁王成录王博带领的EMUI团队显得尤其重要，从他2016年加入这个团队之后，EMUI的根本性改变就发生了，用他的话说：“EMUI不仅仅是一个UI，而是一个平台。”EMUI是如何从UI变为平台的呢？简单梳理一下：
-EMUI 4.X时代，主要的变化还只是TEE OS（即用于指纹的TustZone）以及SensorHub这样基于硬件功能的模块上；
-EMUI 5.X时代，这是一个战略级别的关键版本。解耦Android底层组件，精简各子模块。虚拟机在这个版本也得到了优化，特别涉及了垃圾回收机制（GC）、AOT（运行前编译）、数据库优化（IO并行）等。在这个版本，新的文件系统F2FS（针对闪存推出，大幅度减少文件碎片），还有UltraMemory（即4GB运存达到友商6GB运存效果）的推出，通过对各个Android底层技术模块的深度开发，让EMUI团队敢于将“十八月不卡顿”放到了公众面前，没记错这就是EMUI第一个大争议点出现；
-EMUI 8.X时代，人工智能技术加入系统，iAware借着算力，整个系统的后台管理模式更合理，图形引擎得到升级，即半路加入的GPU Turbo，这是EMUI对Android系统全栈图形模块修改的开始，EROFS超级文件系统也在此期间亮相开源社区；
-EMUI 9.X时代，也是“Turbo”的时代，GPU Turbo 2.0、CPU Turbo、LinkTurbo都是在这一代出现的，系统性能继续优化，EROFS正式加入，连接能力得到强化。2019年MWC上，华为“1+8+N”智慧全场景战略首次浮出水面，在这背后，鸿蒙的研发其实已经悄悄进行了不短的时间了；
-EMUI 10.X时代，分布式技术、软总线、超级终端这一系列的概念出现了，它在HDC 2019上推出，伴随着它一起发布的就是鸿蒙1.0，其时还是一个半成品，只能叫 *** 作系统内核。只是因为2019年5月16日的事件，它不得不作为战略产品提前亮相，在推出的时候，鸿蒙就直接宣布将会开源；
-EMUI 11.X时代，鸿蒙来到了2.0版本，但HDC 2020的主角是HMS和AppGallery，不但前边提到的一系列系统底层的能力变化全部被涵盖其中，连Google最引以自傲的营收来源GMS服务、Google Play也被替代了。
看完上边这个简单的梳理，你是不是对本章节开头的那个问题概念更明晰了？ 如果说华为掏空了Android，没错，华为EMUI团队觉得Google做得不好的地方，要么魔改，要么就干脆换掉，比如底层连接协议。 特别是在2019年5月16日之后，即EMUI10和11两代，这样的动作愈加突出，幅度也越来越大。
要说华为没有掏空Android，也没错， 因为现在华为完全自主运营的AppGallery应用商店，里边的应用都是基于AOSP规范开发，但又置入了HMS服务的华为版，目的就是为了解决这些应用在没有GMS支持下的消费者体验问题。 毕竟在全球范围内，华为已经积累了7亿多终端用户，在他们换机或是华为解决手机硬件产品问题之前，用户还是要继续使用这些华为手机和软件服务的。
到这里，为什么会有鸿蒙这个东西了应该也有答案了。 “低情商”的说法，它有点像是华为在EMUI进化过程中，用来解决多设备连接协作问题中的“副产品”；“高情商”的说法，它是包涵底层互联协议、芯片能力调用、多设备协同过程中交互界面等全方位解决方案的集合体，高效率的连接（HiLink）、低时延（HiLink）以及微内核（比如LiteOS）是它的三大特点，所以，从软硬件一体化的整体度来说，鸿蒙肯定就是一个全新的 *** 作系统。
因为华为的工程师认为，当前物联网的连接协议太过碎片化，从业厂商开发理解能力参差不齐，所以最后出来的产品也就五花八门，这样的情况，将会严重影响华为“1+8+N”战略的推进效果，“1+8”都是华为自己的好说，“N”怎么办呢？那就交给鸿蒙来解决吧。
这是发布会后宣布的消息：2020年和2021年，华为按计划分两次把HarmonyOS的核心基础能力全部捐献给开放原子开源基金会，由开放原子开源基金会整合其他参与者的贡献，形成 OpenHarmony 开源项目——这和AOSP是不是差不多？这就是为了能让其他有兴趣加入华为“1+8+N”战略的设备制造和服务提供商能更好的理解这个生态系统。在2021年5月18日上海的华为HarmonyOS Connect伙伴峰会上，华为消费者业务AI与智慧全场景业务部副总裁杨海松还提到了鸿蒙的商业模式，包括免费认证服务这些内容，我有整理专访，大家有兴趣也可以了解一下。
在2019年发布鸿蒙1.0的时候，华为的确是没有那么快的计划将它放在智能手机上。HDC 2019之后对余承东的专访中，他是这样说的：“如果我们确认谷歌不再为华为提供 *** 作系统，那么，我们可以在一夜之间通过升级，将所有的华为手机 *** 作系统的内核更换为鸿蒙，但是我们现在并不打算这么做，因为我们还是希望可以让合作伙伴（主要是指美国公司）的利益最大化。”
但同时，他也说了三个“Ready”，意即华为是可以随时这么做，而在6月2日的发布会上，华为手机的鸿蒙升级计划是何等规模大家也看到了。同样的问题王博早些时候的回答也是：“做 *** 作系统并没有难度，关键是商业模式的问题。”
时间来到2020年5月16日，美国针对华为的终极制裁到来，手机SoC芯片断供，蓬勃发展的华为手机业务随时面临停摆的问题。虽然现在看，华为还可以通过购买第三方公司的芯片，在全球继续推出4G手机产品，但GMS同样不能使用，出货量也会从过去的亿级下降到千万级，决定华为消费者业务未来的“1+8+N”也随之面临巨大的挑战。两年前还是商业模式的问题瞬间就变成生死存亡的关键，HarmonyOS变得意义更加重大，不得不发。
并肩前行的OpenHarmony和HarmonyOS
我相信有了前边两个部分的铺垫，再进入第三个部分，很多人的困惑应该会少很多。华为目前对鸿蒙这个 *** 作系统的定义是： “HarmonyOS是新一代智能终端 *** 作系统，为不同设备的智能化、互联与协同提供了统一的语言” ，它与我们使用的Android这种宏内核系统在思路上有着本质的区别。
宏内核 *** 作系统我们用得很多，电脑上的Windows、手机上Android都是，它最大的特点是设备要装载这个 *** 作系统，就得所有的系统组件全部加包一起装载，不管用不用得着，同时在运行时，系统也会依据内存大小，自动加载组件，响应速度是提升了，但会消耗极大的系统资源。
到2021年我们已经能见到最高达18GB RAM的安卓手机了，而在当前主流的Android 11系统描述中写到：“设备最小运行内存为512MB”。如果设备的运行内存小于512MB，要到不能用最新版本的Android系统，要么就只能用老版本——这也是为什么我们能看到有些车机还在跑Android 4.4版本……
但是鸿蒙的设想就恰恰是反过来，它从架构设计上就进行了全栈解耦，将庞大的 *** 作系统打散，拆解成很小的颗粒，不同能力的设备只需要按自己的要求来选择相应的模块能力加载即可， 比如鸿蒙系统的前身LiteOS，它最小的体积只有10KB，你能相信它是 *** 作系统么？可它就是！华为认为这是未来物联网时代和必然趋势，巧的是Google也同样这样认为，所以，足足被其孕育了5年的微内核 *** 作系统Fuchsia，刚刚于近日才正式推送，它的目标就是替代Android和ChromeOS，从而更好地适应物联网时代的多样终端和生态。
为了更好地让合作伙伴与开发者适配设备与系统的能力，华为将采用鸿蒙系统的设备从L0~L5做了6个分级，其中从L0~L2这三个级别的设备，要么没有交互界面，要么交互和功能都非常简单，家电、手环就算这种设备，运行内存也非常小，甚至低到KB级，其被定义为瘦终端，它们采用的鸿蒙系统，代码百分之百来自华为，不包含AOSP的任何部分；而L3~L5这三个级别的设备，有交互界面，可应用扩展，手机、平板、笔记本电脑、车机、VR/AR等这些设备就属于富终端的类别，它们采用的鸿蒙系统，就会引用AOSP的部分代码。在这其中，手机无疑是功能最复杂的核心设备，会跑最多的应用，它引用AOSP顺理成章。
所以，这次发布的HarmonyOS是何物就好解释了。 华为软件团队开发出的OpenHarmony开源项目用来构建“1+8+N”生态的基础，在这个基础上，华为手机终端团队加入HMS服务包，提供全套华为服务和连接能力，包括嵌入HMS服务的华为版应用，再加上部分AOSP开源代码，支持Android广泛的应用生态，保证消费者可以继续无障碍地使用已有的应用 ，这就是今天发布的HarmonyOS。看到这里，是不是有人感觉眼熟？
没错，苹果现在M1平台的MacBook就差不多是类似的情况，它既可以运行macOS应用，又可以运行iOS应用，而HarmonyOS呢，既可以运行原来的Android（APK）应用，又可以运行鸿蒙平台开发的应用（APK）。所以，6月2日发布会王博演讲的最后一个环节的话不晓得各位注意到没有： “HarmonyOS是基于OpenHarmony的第一个公开发行版” ，也算是把两者的关系做了一个比较明确的定义了。
关于鸿蒙系统是否是完全自主开发，要是没记错，华为自己是从来没有说过这样的话，但“我们要站在巨人的肩膀上”之类的话倒是看到过不少， 这个巨人放在HarmonyOS上，就是AOSP。至于有人说到的鸿蒙上使用的代码老旧，经过前边两个章节的介绍你应该明白，这对现在的华为和EMUI来说并不太重要，因为Android *** 作系统最核心的模块，华为早就已经是脱离谷歌自己在做更新，包括HMS加入后，连应用验证都自己在做，依赖度已经非常低了。
所以，现在EMUI 11还只基于Android 10版本的AOSP代码，但其对比采用Android 11版本的友商系统体验如何，相信大家心里是有数的。只是因为环境的关系， 本来应该“慢工出细活”的事情，全部被按下了快进键，很多还没来得做的事情，也都因为时间不够没有完成，比如代码替换等，相信今年的HDC 2021上华为软工团队会有更多新消息放出。
选择在现在推出HarmonyOS，对于华为也是有风险的，早年阿里YunOS与Android商业生态的冲突让我们第一次理解到了Google对“开放”的态度。现在，HarmonyOS可能面临的情况也差不多，但好在华为有HMS和初具规模的AppGallery可以进行一些对冲。
但对比这样的风险，真正的风险还是时间。从2020年5月16日算起，到现在已经过去了一年，消费者的换机周期是28个月左右，留给华为以手机产品为中心推进“1+8+N”战略的时间并不多，在余下的短短1~2年时间里，华为除了继续保留尽可能多的存量用户，还需要完成去手机中心化的“1+8+N”战略，还需要团结尽可能多的手机厂商来形成新的中心，从之前与杨海松的对话来看，新战略中的“1”，很有可能就是App了。
但另一方面，杨海松也说过： “华为擅长做产品而不擅长做生态”，这也是一个现实的问题，以前华为做产品，秉持的是“进入一个行业，就一定要做到世界第一”的“霸道”原则，现在做生态，华为应该想的是如何交到更多朋友，合作共赢，姿态非常重要……
写在最后
“华为推出HarmonyOS，中国骄傲”，发布会之后，以此为主题，各种各样的鸡血文章、小视频又出现在各大内容平台上，好一场流量盛宴。类似的场景也出现在一年前，在他们口中，似乎华为能以一己之力，一夜之间厘清中国整个芯片产业的 历史 欠账。华为人并非没有看到这些，但现在的他们，哪里有功夫去理会这些论调，有太多事要做了。虽然这篇长文，也许看到的人和看完的人有限，但我觉得能把那些关于HarmonyOS的事儿解释清楚，足矣。
下面写个小程序测试一下。private Runnable runnable = new Runnable() { @Override
public void run() {
List<Book>bookList = new ArrayList<>() for (int i = 0i <5000i++) {
Book book = new Book()
book.setUuid(UUID.randomUUID().toString())
book.setName("name") //其他set方法略
bookList.add(book)
} try {
Thread.sleep(1000)
} catch (InterruptedException e) {
e.printStackTrace()
}
mBookDao.insertOrReplaceInTx(bookList)
Log.d(TAG, "插入book数据：" + bookList.size())
}
}private void insert() {
Log.d(TAG, "线程池开始")
mBookDao.deleteAll() long time = System.currentTimeMillis()
ExecutorService executorService = Executors.newFixedThreadPool(3) for (int i = 0i <200i++) {
executorService.submit(runnable)
}
executorService.shutdown() for () {if (executorService.isTerminated()) {break
}try {
executorService.awaitTermination(1, TimeUnit.SECONDS)
} catch (InterruptedException e) {
e.printStackTrace()
}
}
Log.d(TAG, "线程池完成：" + (System.currentTimeMillis() - time) + "ms")
}
runnable任务模拟1秒从网络拉取5000条数据并插入DB，insert方法使用线程池执行runnable任务。
执行时间超过1000秒，查看内存占用超过180M。如果数据量更多，肯定会发生OOM，基本上可以定位是greenDAO的问题。现在需要在两个方面优化，一是寻找内存占用的原因，二是提高数据的插入速度。
查看内存堆
内存的占用随着insert的数据量越多而递增，从中间dump出java堆，得到hprof文件。注意这个文件不是标准格式，只能用AndroidStudio打开。
图1
右击文件导出标准的hprof文件，用更加强大的MAT分析。
图2
图3
看到IdentityScope占了一半内存，可以确定是greenDAO缓存了插入数据。
mBookDao.insertOrReplaceInTx(bookList)mBookDao.detachAll()
greenDAO的缓存功能是有用的，没必要关闭，改成在插入数据后，调用一次detachAll，将identityScope清空。
public void detachAll() {if (identityScope != null) {
identityScope.clear()
}
}
重建索引
对表插入大量数据，如果中间没有涉及到业务，可以先失效索引，待插入完成后重建索引。
String sql = "drop index index_isbn"
mDb.execSQL(sql)
sql = "drop index index_publisherid"
mDb.execSQL(sql)
sql = "drop index index_author"
mDb.execSQL(sql)
插入数据前，drop掉表中的索引。没有见到greenDAO有 *** 作索引的方法，直接执行sql命令。
sql = "create index index_isbn on book(isbn)"
mDb.execSQL(sql)
sql = "create index index_publisherid on book(publisherid)"
mDb.execSQL(sql)
sql = "create index index_author on book(author)"
mDb.execSQL(sql)
插入数据完成后，重建索引。最后执行100w数据插入大约耗时450秒，比什么都不做快了两三倍。
异步 *** 作
上一个步骤的耗时包含了模拟网络和数据库 *** 作的时间，使用多线程将两个环节分离，可以减少总时间。
greenDAO提供了AsyncSession这个异步 *** 作类，使用daoSession.startAsyncSession()获取实例，内部实现使用了线程池和阻塞队列，原理很简单不用多讲。
mAsyncSession.runInTx(new Runnable() {@Override
public void run() {
mBookDao.insertOrReplaceInTx(bookList)
mBookDao.deleteAll()
}
})
获取数据后，提交给AsyncSession异步插入数据库。要注意在合适地方使用waitForCompletion，等待AsyncSession完成已有任务。如果获取数据速度很快，而 *** 作数据库很慢，会导致过多数据缓存在AsyncSession的内部阻塞队列。
最后测试一下100w数据插入数据库，耗时不到150秒，又快了几倍。
作者：展翅而飞
链接：https://www.jianshu.com/p/6589c6d3f551
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）