تجزیه و تحلیل جامع توابع پایه Asset Store Kit در HarmonyOS Next

Summarize this content to 400 words in Persian Lang

هدف این مقاله بررسی عمیق جزئیات فنی سیستم Huawei HarmonyOS Next (تا API 12 تا کنون) در توسعه پلتفرم‌های تجارت الکترونیک چندزبانه است و بر اساس شیوه‌های توسعه واقعی خلاصه می‌شود. این عمدتا به عنوان وسیله ای برای اشتراک گذاری و ارتباطات فنی عمل می کند. اشتباه و کوتاهی اجتناب ناپذیر است. از همکاران استقبال می شود که نظرات و سوالات ارزشمندی را مطرح کنند تا بتوانیم با هم پیشرفت کنیم. این مقاله محتوای اصلی است و هر نوع تجدید چاپ باید منبع و نویسنده اصلی را ذکر کند.در معماری امنیتی سیستم HarmonyOS Next، Asset Store Kit نقشی محوری دارد. این یک پایه محکم برای ذخیره سازی و مدیریت دارایی های حیاتی است و بخش مهمی از تضمین امنیت سیستم و حریم خصوصی داده های کاربر است.

(I) مقدمه

شرح وضعیت مهم
– کیت فروشگاه دارایی بخشی ضروری از اکوسیستم HarmonyOS Next است. این مانند یک قلعه محکم است که به طور خاص برای محافظت از آن دارایی های حیاتی که برای برنامه ها و کاربران حیاتی هستند طراحی شده است. این دارایی‌های حیاتی شامل داده‌های رمز عبور (مانند رمزهای عبور حساب)، داده‌های رمز (مدارک اعتبار برنامه)، و سایر اطلاعات متن ساده حساس (مانند شماره کارت بانکی و غیره) است. در عصر دیجیتال امروزی، امنیت این داده‌ها مستقیماً با ایمنی دارایی کاربران، حفاظت از حریم خصوصی و عملکرد عادی برنامه‌ها ارتباط دارد. به عنوان مثال، در برنامه های پرداخت موبایلی، شماره کارت بانکی و رمزهای عبور پرداخت و سایر دارایی های حیاتی کاربران باید به درستی محافظت شود. در غیر این صورت با خطرات بزرگی مواجه خواهند شد. Asset Store Kit امنیت این دارایی‌های حیاتی را در حین ذخیره‌سازی، دسترسی و مدیریت از طریق یک سری عملکردها و مکانیسم‌های قدرتمند تضمین می‌کند، بنابراین پشتیبانی قوی برای عملکرد پایدار کل سیستم HarmonyOS Next فراهم می‌کند.

تاکید بر نقش کلیدی
– نقش کلیدی آن عمدتاً در دو جنبه منعکس می شود. از یک طرف، رابط‌ها و روش‌های یکپارچه را فراهم می‌کند و توسعه‌دهندگان را قادر می‌سازد تا دارایی‌های حیاتی را به راحتی و کارآمد ذخیره و مدیریت کنند. توسعه دهندگان نیازی به درک عمیق از مکانیسم های امنیتی پیچیده اساسی ندارند. آنها فقط باید رابط های ساده و کاربردی ارائه شده توسط Asset Store Kit را فراخوانی کنند تا به ذخیره سازی و عملکرد ایمن دارایی های حیاتی دست یابند. از سوی دیگر، Asset Store Kit به طور موثر از به دست آوردن غیرقانونی و دستکاری دارایی های حیاتی از طریق اقدامات امنیتی مختلف مانند الگوریتم های رمزگذاری و مکانیسم های کنترل دسترسی جلوگیری می کند. این نه تنها از منافع کاربران محافظت می‌کند، بلکه اعتماد کاربران را به برنامه‌ها افزایش می‌دهد و استفاده گسترده و توسعه برنامه‌ها را ترویج می‌کند. ### (II) اصل ذخیره سازی دارایی های حیاتی

وابستگی به سیستم فروشگاه کلید عمومی
– ذخیره ایمن دارایی های حیاتی به شدت به سیستم ذخیره کلید عمومی زیربنایی بستگی دارد. سیستم ذخیره کلید عمومی مانند یک گاوصندوق امن است که مسئول ذخیره و مدیریت کلیدهای مورد استفاده برای رمزگذاری و رمزگشایی دارایی های حیاتی است. هنگامی که یک برنامه نیاز به ذخیره دارایی های حیاتی دارد، Asset Store Kit با سیستم ذخیره کلید عمومی برای به دست آوردن کلیدهای مربوطه تعامل برقرار می کند. سپس با استفاده از این کلیدها، دارایی‌های حیاتی را از طریق الگوریتم‌های رمزنگاری پیشرفته (مانند الگوریتم AES256-GCM) رمزگذاری می‌کند و قبل از ذخیره‌سازی در پایگاه داده ASSET، آنها را به شکل متن رمزی تبدیل می‌کند. به عنوان مثال، هنگام ذخیره رمز عبور کاربر، ابتدا کلید رمزگذاری از سیستم ذخیره کلید عمومی دریافت می شود و سپس رمز عبور با استفاده از این کلید رمزگذاری می شود تا از محرمانه بودن رمز عبور در هنگام ذخیره سازی اطمینان حاصل شود.

اجرای رمزگذاری و رمزگشایی در یک محیط امن
– عملیات رمزگذاری و رمزگشایی در یک محیط امن (مانند یک محیط اجرای قابل اعتماد) انجام می شود. این امنیت اضافی را برای دارایی های حیاتی فراهم می کند. محیط اجرای مورد اعتماد یک منطقه سخت افزاری مستقل و ایزوله با سطح امنیت بالا است. در این محیط، حتی اگر سایر بخش‌های سیستم به طور مخرب مورد حمله قرار گیرند، عملیات رمزگذاری و رمزگشایی همچنان می‌تواند با خیال راحت بدون درز اطلاعات دارایی‌های حیاتی اجرا شود. به عنوان مثال، هنگامی که یک کاربر به یک برنامه وارد می شود و باید رمز عبور را تأیید کند، عملیات رمزگشایی رمز عبور در محیط اجرای مورد اعتماد انجام می شود. رمز عبور رمزگشایی شده با رمز عبور ورودی کاربر مقایسه می شود. تنها زمانی که مقایسه موفقیت آمیز باشد، کاربر می تواند حقوق دسترسی مربوطه را به دست آورد. چنین طراحی تضمین می کند که رمز عبور همیشه در یک وضعیت امن در طول کل فرآیند تأیید قرار دارد و به طور موثر از دزدیده شدن یا دستکاری رمز عبور جلوگیری می کند. ### (III) مکانیسم های کنترل دسترسی

کنترل دسترسی بر اساس مالکیت
– همه دارایی های حیاتی به شدت توسط کنترل دسترسی مالکیت محافظت می شوند، که ابتدایی ترین روش کنترل دسترسی است و نیازی به تنظیمات اضافی برای تجارت ندارد. اصل اصلی این است که تنها کسب و کاری که دارایی حیاتی را می نویسد (یعنی مالک) می تواند به آن دسترسی داشته باشد. به عنوان مثال، در یک برنامه تجارت الکترونیک، اطلاعات سفارش کاربر توسط برنامه تجارت الکترونیکی در ذخیره سازی دارایی حیاتی نوشته می شود. سپس، فقط این اپلیکیشن تجارت الکترونیکی حق دسترسی و مدیریت این اطلاعات سفارش را دارد. حتی اگر برنامه های کاربردی دیگر تلاش کنند این اطلاعات سفارش را به دست آورند، به دلیل نداشتن هویت مالک، از دسترسی به آنها جلوگیری می شود. این مکانیزم کنترل دسترسی مبتنی بر مالکیت به طور موثر از دسترسی متقابل به داده ها بین مشاغل مختلف جلوگیری می کند و استقلال و امنیت داده های هر کسب و کار را تضمین می کند.

کنترل دسترسی بر اساس حالت قفل صفحه
– این کنترل دسترسی به سه سطح تقسیم می شود: قابل دسترسی پس از روشن شدن، قابل دسترسی پس از اولین باز کردن قفل و قابل دسترسی هنگام باز شدن با افزایش سطوح امنیتی. – قابل دسترسی پس از روشن شدن: برای برخی از حالات با الزامات امنیتی نسبتاً پایین اما نیاز خاصی به راحتی قابل استفاده است. به عنوان مثال، برای برخی از برنامه های خبری و اطلاعاتی، کاربران ممکن است امیدوار باشند که پس از روشن شدن بدون نیاز به باز کردن قفل دستگاه، به سرعت به محتوای برنامه دسترسی پیدا کنند. در این حالت، برنامه می‌تواند دارایی‌های حیاتی مربوطه (مانند سوابق سابقه مرور کاربران و غیره) را طوری تنظیم کند که پس از روشن شدن، برای بهبود تجربه کاربر قابل دسترسی باشند. – قابل دسترسی پس از اولین باز کردن قفل: این یک تنظیم رایج است که برای اکثر برنامه های معمولی قابل استفاده است. به عنوان مثال، برای سوابق چت کاربران و سایر دارایی های مهم در برنامه های اجتماعی، پس از اینکه کاربر ابتدا قفل دستگاه را باز کرد، می توان به آنها دسترسی داشت. این امر سطح معینی از امنیت را تضمین می‌کند و از دسترسی غیرقانونی به دارایی‌های حیاتی در زمانی که قفل دستگاه باز نیست جلوگیری می‌کند، و همچنین به کاربران امکان می‌دهد پس از باز کردن قفل به راحتی از برنامه استفاده کنند و قابلیت استفاده برنامه را بهبود بخشد. – قابل دسترسی هنگام باز شدن قفل: برای برنامه‌هایی با الزامات امنیتی بسیار بالا، مانند برنامه‌های بانکی یا برنامه‌های کاربردی سازمانی که شامل اسرار تجاری مهم هستند، معمولاً دارایی‌های حیاتی به گونه‌ای تنظیم می‌شوند که هنگام باز شدن قفل قابل دسترسی باشند. این بدان معناست که تنها زمانی که دستگاه در حالت قفل است و کاربر تأیید هویت (مانند رمز عبور، اثر انگشت، چهره و غیره) را گذرانده باشد، می‌توان به این دارایی‌های حیاتی دسترسی داشت. به عنوان مثال، برای موجودی حساب‌های کاربران، جزئیات تراکنش و سایر اطلاعات مهم در برنامه‌های بانکی، تنها پس از باز کردن قفل دستگاه و تأیید هویت توسط کاربر، می‌توان به آن‌ها دسترسی پیدا کرد که این امر حفاظت از امنیت وجوه کاربران و حریم خصوصی را به حداکثر می‌رساند.

کنترل دسترسی بر اساس وضعیت تنظیم رمز عبور صفحه قفل
– این کنترل دسترسی به طور پیش فرض خاموش است و توسعه دهندگان می توانند تصمیم بگیرند که آیا آن را مطابق با سناریوی واقعی برنامه روشن کنند یا خیر. هنگامی که این عملکرد روشن است، تنها زمانی که کاربر رمز عبور صفحه قفل را تنظیم کرده باشد، به دارایی های مهم دسترسی داده می شود. برای مثال، در یک برنامه آلبوم عکس که عکس‌های حریم خصوصی شخصی کاربران را ذخیره می‌کند، توسعه‌دهندگان می‌توانند کنترل دسترسی را بر اساس وضعیت تنظیم رمز عبور صفحه قفل روشن کنند. بنابراین، تنها زمانی که کاربر رمز عبور صفحه قفل را برای اطمینان از سطح خاصی از امنیت دستگاه تنظیم کرده باشد، می‌تواند به عکس‌های آلبوم دسترسی داشته باشد و به‌طور مؤثری مانع از آن می‌شود که دیگران به راحتی عکس‌های حریم خصوصی کاربران را در زمانی که دستگاه با رمز صفحه قفل تنظیم نشده است به دست آورند. .

کنترل دسترسی بر اساس احراز هویت کاربر
– این نیز به صورت پیش فرض خاموش است و توسعه دهندگان می توانند در صورت نیاز آن را روشن کنند. پس از روشن شدن، دسترسی به دارایی‌های حیاتی تنها پس از تایید هویت کاربر (مانند اثر انگشت، چهره، کد پین و غیره، هر یک از روش‌های احراز هویت) مجاز خواهد بود. علاوه بر این، توسعه دهندگان می توانند مدت اعتبار احراز هویت را با حداکثر 10 دقیقه تنظیم کنند. به عنوان مثال، در برنامه های اداری مورد استفاده در یک شرکت، کاربران ممکن است نیاز داشته باشند که به طور مکرر به برخی از فایل های حساس (مانند صورت های مالی شرکت و سایر دارایی های حیاتی) دسترسی داشته باشند. با روشن کردن کنترل دسترسی بر اساس احراز هویت کاربر و تنظیم یک دوره اعتبار احراز هویت مناسب (مانند 5 دقیقه)، کاربران نیازی به تکرار احراز هویت در هنگام انجام چندین عملیات دسترسی به فایل در عرض 5 دقیقه پس از اولین احراز هویت ندارند، که نه تنها باعث بهبود می شود. کارایی کار بلکه امنیت فایل ها را نیز تضمین می کند. پس از پایان دوره اعتبار احراز هویت، اگر کاربر بخواهد دوباره به دارایی های حیاتی دسترسی پیدا کند، باید احراز هویت را دوباره انجام دهد. ### (IV) توضیح ویژگی‌های دارایی حیاتی

فهرست صفات و معانی (به صورت جدولی)
| نام ویژگی | معنی | آیا لازم است؟ | توضیح | |—|—|—|—| | نام مستعار (Alias) | رشته ای که برای شناسایی منحصر به فرد هر دارایی حیاتی، از نوع Uint8Array، با طول 1 – 256 بایت استفاده می شود | اختیاری | این یک مبنای مهم برای کسب و کار است که دارایی های مهم را پیدا کرده و به کار ببندد، شبیه به یک شاخص در یک پایگاه داده. نام مستعار هر دارایی حیاتی باید منحصر به فرد باشد. | | ACCESSIBILITY (سطح کنترل دسترسی) | تنظیم کنترل دسترسی بر اساس وضعیت صفحه قفل، از نوع شماره، با محدوده مقادیر به تفصیل در دسترس‌پذیری | اختیاری | تعیین می‌کند که تحت کدام حالت صفحه قفل می‌توان به دارایی حیاتی دسترسی داشت، مانند بعد از روشن کردن، پس از اولین باز کردن قفل یا زمانی که قفل آن باز شد. | | REQUIRE_PASSWORD_SET (الزام رمز عبور صفحه قفل) | اینکه آیا فقط زمانی که رمز عبور صفحه قفل تنظیم شده باشد، از نوع bool |، می توان به دارایی مهم دسترسی داشت یا خیر اختیاری | می تواند امنیت دارایی حیاتی را بیشتر افزایش دهد. تصمیم بگیرید که آیا این محدودیت را با توجه به نیازهای تجاری فعال کنید یا خیر. | | AUTH_TYPE (نوع احراز هویت) | نوع احراز هویت کاربر مورد نیاز برای دسترسی به دارایی حیاتی، از نوع شماره، با محدوده مقادیر به تفصیل در AuthType | اختیاری | روش احراز هویت کاربر مورد نیاز برای دسترسی به دارایی مهم مانند اثر انگشت، چهره، کد پین و غیره را مشخص می کند | | SYNC_TYPE (نوع همگام سازی) | نوع همگام سازی پشتیبانی شده توسط دارایی حیاتی، از نوع شماره، با محدوده مقدار به تفصیل در SyncType | اختیاری | برای کنترل رفتار همگام سازی دارایی حیاتی در بین چندین دستگاه مانند همگام سازی خودکار و غیره استفاده می شود. | IS_PERSISTENT (ویژگی پایداری) | این که آیا دارایی حیاتی باید در هنگام حذف نصب برنامه حفظ شود، از نوع bool | اختیاری | وضعیت حفظ دارایی حیاتی را پس از حذف نصب برنامه تعیین می کند. برای برخی از داده هایی که باید برای مدت طولانی ذخیره شوند (مانند اطلاعات پیکربندی مهم کاربران)، می توان آن را به گونه ای تنظیم کرد که حفظ شود. | | DATA_LABEL_CRITICAL_1 – 4 (اطلاعات کمکی حیاتی) | اطلاعات جانبی دارایی حیاتی، با محتوای سفارشی شده توسط کسب و کار و دارای حفاظت یکپارچگی، از نوع Uint8Array، با طول 1 – 2048 بایت (1 – 512 بایت قبل از API 12) | اختیاری | برای ذخیره اطلاعات اضافی مهم مربوط به دارایی حیاتی و اطمینان از یکپارچگی اطلاعات استفاده می شود. پس از نوشتن، از به روز رسانی پشتیبانی نمی کند. | | DATA_LABEL_NORMAL_1 – 4 (اطلاعات جانبی عادی) | اطلاعات جانبی دارایی حیاتی، با محتوای سفارشی‌سازی شده توسط 512字节）| 可选 | 存储一般的附属信息，业务可根据需要自由更新内容 | | DATA_LABEL_NORMAL_LOCAL_1 – 4 (本地附属信息) | 关键资产附属的本地信息，内容由业务自定义且无完整性保护，该项信息不会进行同步，类型为Uint8Array，长度为1 – 2048字节 | 可选 | 用于存储仅在本地使用的关键资产相关信息，不会在多设备间同步，可减少不必要的数据传输和存储| | RETURN_TYPE (查询返回类型) | نوع برگشتی | 可选 | 指定查询关键资产时返回结果的格式和内容类型 | | RETURN_LIMIT (查询返回数量限制) | 关键资产查询返回的结果数量，类型为شماره | 可选 | 限制查询操作返回的关键资产数量，可用于控制数据量和提高查询效率 | | RETURN_OFFSET (查询返回偏移量) | 指定从第几个关键资产开始返回查询结果，取值范围为1 – 65536，类型为شماره | 可选 | 用于分批查询场景，可实现对大量关键资产的分页查询，提高查询性能和 | | RETURN_ORDERED_BY (查询结果排序依据) | 仅支持按照附属信息排序，取值范围为asset.Tag.DATA_LABEL_xxx，类型为number | 可选 | 决定查询结果的排序方式，方便业务根据特定需求获取有序的关键资衡产刧 |

نقش ویژگی ها در شناسایی دارایی، کنترل دسترسی و مدیریت
– ویژگی ALIAS نقش مهمی در شناسایی دارایی ایفا می کند. از طریق یک نام مستعار منحصر به فرد، توسعه‌دهندگان می‌توانند به سرعت و با دقت دارایی‌های حیاتی خاص را پیدا کرده و از آن بهره‌برداری کنند. به عنوان مثال، در برنامه ای که حاوی رمزهای عبور حساب کاربری چند کاربر است، هر رمز عبور حساب دارای نام مستعار مربوط به خود است. توسعه دهندگان می توانند رمز عبور یک کاربر خاص را با توجه به نام مستعار پیدا کرده و به روز کنند. – ویژگی ACCESSIBILITY مستقیماً بر کنترل دسترسی دارایی های حیاتی تأثیر می گذارد. سطوح مختلف کنترل دسترسی تعیین می‌کنند که تحت چه شرایطی می‌توان به دارایی‌های حیاتی دسترسی داشت، بنابراین از دارایی‌های حیاتی در برابر دسترسی غیرمجاز محافظت می‌کند. – ویژگی REQUIRE_PASSWORD_SET امنیت کنترل دسترسی را افزایش می دهد. این تضمین می‌کند که تنها زمانی که دستگاه رمز عبور قفل صفحه را تنظیم کرده باشد، می‌توان به دارایی‌های حیاتی دسترسی داشت، و یک مانع محافظ اضافی برای دارایی‌های حیاتی ایجاد می‌کند. – ویژگی AUTH_TYPE روش احراز هویت کاربر مورد نیاز برای دسترسی به دارایی های حیاتی را روشن می کند. با تعیین یک نوع احراز هویت مناسب، مانند نیاز به احراز هویت با اثر انگشت یا احراز هویت کد پین، امنیت دسترسی به دارایی‌های حیاتی بیشتر بهبود می‌یابد. – ویژگی SYNC_TYPE در مدیریت دارایی های حیاتی در چندین دستگاه نقش دارد. توسعه‌دهندگان می‌توانند تعیین کنند که آیا و چگونه دارایی‌های حیاتی با توجه به الزامات برنامه هماهنگ شوند تا تجربه ثابت کاربران از استفاده از برنامه در دستگاه‌های مختلف را برآورده کنند. – ویژگی های دیگر مانند IS_PERSISTENT، ویژگی های مختلف DATA_LABEL و غیره، عملکردهای غنی را در جنبه هایی مانند ذخیره سازی دائمی دارایی ها، مدیریت اطلاعات اضافی و کنترل نتایج پرس و جو ارائه می دهند و به توسعه دهندگان کمک می کنند تا دارایی های حیاتی را بهتر مدیریت و استفاده کنند. ### (V) مثال نمایش کد
در زیر یک نمونه کد ArkTS است که نحوه ایجاد یک دارایی مهم با ویژگی‌های خاص را نشان می‌دهد (با فرض ذخیره اعتبار ورود کاربر):

import { asset } from ‘@kit.AssetStoreKit’;
import { util } from ‘@kit.ArkTS’;
import { BusinessError } from ‘@kit.BasicServicesKit’;
function stringToArray(str: string): Uint8Array {
    let textEncoder = new util.TextEncoder();
    return textEncoder.encodeInto(str);
}
// 创建一个关键资产，包含用户名、密码和相关属性
let attr: asset.AssetMap = new Map();
attr.set(asset.Tag.SECRET, stringToArray(‘userPassword123’)); // 假设密码为”userPassword123″
attr.set(asset.Tag.ALIAS, stringToArray(‘loginCredential’)); // 设置别名为”loginCredential”
attr.set(asset.Tag.ACCESSIBILITY, asset.Accessibility.FIRST_UNLOCKED); // 设置为首次解锁后可访问
attr.set(asset.Tag.DATA_LABEL_NORMAL_1, stringToArray(‘userLoginInfo’)); // 存储一些普通附属信息，如登录相关的其他说明
try {
    asset.add(attr).then(() => {
        console.info(‘Key asset created successfully.’);
    }).catch((err: BusinessError) => {
        console.error(‘Failed to create key asset. Code is ${err.code}, message is ${err.message}’);
    });
} catch (error) {
    let err = error as BusinessError;
    console.error(‘Failed to create key asset. Code is ${err.code}, message is ${err.message}’);
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

(VI) خلاصه و بازتاب

خلاصه ای از نکات کلیدی توابع اساسی
– عملکردهای اساسی Asset Store Kit حول ذخیره سازی امن، کنترل دسترسی و مدیریت دارایی های حیاتی می چرخد. با تکیه بر سیستم ذخیره کلید عمومی برای ذخیره سازی ایمن، استفاده از مکانیسم های کنترل دسترسی مختلف برای اطمینان از امنیت دارایی، و ارائه ویژگی های غنی برای رفع نیازهای مختلف مدیریت. توسعه‌دهندگان باید اصل ذخیره‌سازی دارایی‌های حیاتی را درک کنند، بر ویژگی‌ها و سناریوهای کاربردی روش‌های کنترل دسترسی مختلف تسلط داشته باشند، و با معانی و کاربردهای ویژگی‌های دارایی حیاتی آشنا باشند تا بتوانند به طور کامل از مزایای Asset Store Kit در توسعه برنامه‌ها استفاده کنند.

راهنمای تفکر در مورد الزامات برنامه
– برای توسعه ما، در توسعه واقعی برنامه، باید به طور منطقی از عملکردهای Asset Store Kit با توجه به نوع برنامه، نیازهای کاربر و الزامات امنیتی استفاده کنیم. به عنوان مثال، برای برنامه های مالی، ما باید بر روی کنترل دسترسی با قدرت بالا (مانند قابل دسترسی در هنگام باز بودن، بر اساس احراز هویت کاربر و غیره) و سیاست های رمز عبور سختگیرانه (مانند تنظیم طول رمز عبور، الزامات پیچیدگی و غیره) تمرکز کنیم. در حالی که برای برخی از برنامه‌های سرگرمی معمولی، می‌توانیم در حین اطمینان از سطح خاصی از امنیت، انتخاب سطح کنترل دسترسی مناسب (مانند قابل دسترسی پس از اولین باز کردن قفل) به تجربه کاربر توجه بیشتری داشته باشیم. در عین حال، ما همچنین باید در نظر بگیریم که چگونه به طور منطقی ویژگی‌های دارایی‌های حیاتی را برای بهینه‌سازی ذخیره‌سازی داده‌ها و کارایی پرس و جو طراحی کنیم. در یک سناریوی برنامه چند دستگاهی، ما باید از عملکرد همگام سازی استفاده کامل کنیم تا از ثبات و امنیت داده های کاربران در دستگاه های مختلف اطمینان حاصل کنیم. در پایان، ما باید عمیقاً در نظر بگیریم که چگونه عملکردهای Asset Store Kit را با الزامات خاص برنامه ترکیب کنیم تا تجربه کاربردی امن و راحت را برای کاربران فراهم کنیم.

import { asset } from '@kit.AssetStoreKit';
import { util } from '@kit.ArkTS';
import { BusinessError } from '@kit.BasicServicesKit';
function stringToArray(str: string): Uint8Array {
    let textEncoder = new util.TextEncoder();
    return textEncoder.encodeInto(str);
}
// 创建一个关键资产，包含用户名、密码和相关属性
let attr: asset.AssetMap = new Map();
attr.set(asset.Tag.SECRET, stringToArray('userPassword123')); // 假设密码为"userPassword123"
attr.set(asset.Tag.ALIAS, stringToArray('loginCredential')); // 设置别名为"loginCredential"
attr.set(asset.Tag.ACCESSIBILITY, asset.Accessibility.FIRST_UNLOCKED); // 设置为首次解锁后可访问
attr.set(asset.Tag.DATA_LABEL_NORMAL_1, stringToArray('userLoginInfo')); // 存储一些普通附属信息，如登录相关的其他说明
try {
    asset.add(attr).then(() => {
        console.info('Key asset created successfully.');
    }).catch((err: BusinessError) => {
        console.error('Failed to create key asset. Code is ${err.code}, message is ${err.message}');
    });
} catch (error) {
    let err = error as BusinessError;
    console.error('Failed to create key asset. Code is ${err.code}, message is ${err.message}');
}