今天我们来初步介绍一下有关使用picker选择媒体库资源的使用，在很多的开发场景中我们都需要选择图片或者调用图库选择照片，在鸿蒙中给我们提供了那么一个API让我们可以很轻松的就开发出我们想要的图片选择器业务。到了我们的第四步，我们上述三步创建了图片文件选择项的实例，配置了文件的类型和文件的最大数目，到了第四步，我们要开始创建以恶搞图库选择器的实例，也就是从这一步开始我真正的要开始进入图库了。但是我

在我们的开发目录中有个resources的目录，该目录下的base下面的media就是我们存放图片的文件夹，其中Image()这个组件我们点进去之后可以看到它支持加载string， PixelMap 和Resource类型的数据源，其中支持的图片类型为png，jpg， bmp， svg和gif 类型的图片格式。其中该代码中的.fonSize, .width, .height都是叫做样式属性，其中的

在上一篇章中我们了解到了PersistentStorage的状态持久化内存状态，但是这个PersistentStorage有许多限制条件和存在一些不足，比如说如果我们写入大量的数据持久化，那么就会影响性能，因为PersistentStorage写入磁盘的操作是同步的，大量的数据本地化读写会同步在线程中执行，从而导致性能的下降。2.往仓库中存储，注意写入后要记得加上store.flush() //将

我们先来个简单的介绍。UI和业务逻辑不直接访问PersistentStorage中的属性，所有属性访问都是对AppStorage的访问,AppStorage中的更改会自动同步到PersistentStorage,也就是说，我们和之前访问AppStorage是一样的，只不过需要提前使用PersistentStorage来声明。PersistentStorage的用法就是如此简单，只是向磁盘中存储的数

但是它们的“脾气”都是一样的，都不愿意“一个屋子里住多个人”它们都是仅仅支持一个子组件，但是这个Grid不同它的子组件不能是Column等，他只能是GridItem所以我们要使用的话也只能配合它，但是假如我们直接干的话又发现，没想到GridItem也仅支持一个子组件，它的“脾气”和他“老爸”几乎一样，假如我们按照“规定”再给他套一套会呈现什么效果呢?我们观察可以看的出来他貌似“自动”的帮我们分配好

就比如说我们定义一个对象或者定义了一个类，然后再定义一个数组里面有多个对象，那么这样嵌套起来，我们上一篇中讲到的修饰器就无法进行监听改变了，因为它们只能观察到第一层的变化也就是说我们嵌套进入第二层或者多层的时候就无法再进行改变了。这篇内容的"主角"因此而诞生 ---@Observed和@ObjectLink。在上一篇的基础上中我们大致了解了@State，@Prop， @Link， @Provide

在我们很多的开发场景中都会用到很多重复的样式，这会出现大量代码在进行重复的样式设置，@Styles装饰器可以将多条样式设置成一个方法， 直接在组件声明的位置调用。@Extend装饰器，从上面描述中我们便可以知晓@Styles用于样式的复用但是限制于通用样式，于是为了弥补这个缺失，@Extend装饰器便产生出来，用于扩展原生组件样式。在上一个篇章中我们介绍和了解了基本的样式组件方法属性等，在这一篇内

我们给new 的LocalStorage(key)输入一个key让@LocalStorageProp或者@LocalStorageLink知道是哪一个对象。从视频演示和代码中我们不难看出被LocalStorageLink修饰的变量可以双向的传递而LocalStorageProp只能单向的传递无法更改数据源，从其中我们也得知LocalStorage的基本用法，是可以跨页面进行数据的共享，不过需要传递