.config、AbilityPackage、Ability与Slice

.config可以理解为Android中的manifest文件，权限、主题、Ability、卡片等需要在此文件中声明。
AbilityPackage可以理解为Android中的Application，鸿蒙sdk在接管了app的生命周期后会将Application的生命周期回调分发到AbilityPackage中。

Ability可以理解为Android中的四大组件，一个Ability可以对应一个也可以是多个四大组件，比如当Ability既是入口Ability也是服务卡片对应的Ability，那么此Ability会生成一个Activity和一个Service。值得注意的是，由Ability去生成对应的四大组件时是有固定的套路的，比如名为MainAbility其对应的Activity名就是MainAbilityShellActivity。

image.png

image.png

image.png

Slice可以理解为Android中的Fragment。

.hap

.hap是用DevEco Studio打包出来的鸿蒙特有的应用格式，解压后的文件结构如下所示。

image.png

assets是hap的资源目录。resources目录中是具体的资源文件；resources.index可以理解为android中的arsc文件，记录了资源整型值和资源相对路径的映射表。

image.png

classes.dex是我们的业务逻辑代码。

entry_debug_signed_entry.apk是由.hap生成的对应的壳应用，包含了ability对应的四大组件、.config中声明的权限等，扮演着一个牵线木偶的角色。

image.png

image.png

image.png

HarmonyApplication会在app启动时初始化资源和classloader，以及鸿蒙自有的一些类似于Context、Application的类，并接管app的启动流程，再将Application的生命周期分发到AbilityPackage中。

image.png

AbilityShellActivity接管了Activity的生命周期，并在其中初始化对应的Ability，再将Activity的生命周期分发到对应的Ability中。

image.png

image.png

image.png

config.json即为工程中的config.json。

pack.info不知道啥作用，看上去只有一部分config.json的信息。

类

image.png

image.png

值得一提的是，这种动态加载dex的方式在dex较大时，会存在因dex2oat导致的cpu飙升和应用加载时间过长的问题，一般会通过开机时禁用dex2oat放在后台去做去规避这个问题，不知道鸿蒙的处理方式是怎样的。

资源

可以以LayoutScatter.getInstance(this.mContext).parse(i, null, false);为入口看下资源文件的加载流程。

image.png

image.png

image.png

可以看到鸿蒙上资源的查找过程是类似于android资源的查找过程，从一个类似于ContextImpl的ContextDeal的类入手，传入一个类似于R.xxx的ResourceTable.xxx的整型值，到类似于arsc作用的resources.index文件中找到该资源对应的相对路径。

至于.apk文件的arsc中其实只包含了应用名等基本的资源，还有卡片服务的相关资源。
[图片上传失败...(image-b1eaba-1629442523311)]

image.png

视图结构

adb shell uiautomator dump查看当前app的页面元素，或者断点找到对应window的DecorView也能得出相同的结论。

image.png

看下Activity和Dialog对应的Window关联View的过程。

image.png

image.png

可以看到几乎所有鸿蒙上提供的继承自Component的控件最后都转换成了android上的View。但具体这种转换是如何进行的，需要看下native的代码。而且添加到window上的SurfaceView最后也找不到了，不知道为啥，也不知道这个SurfaceView有啥作用。

权限

image.png

ohos.app.Context#requestPermissionsFromUser(new String[] { "ohos.permission.CAMERA" } , MY_PERMISSIONS_REQUEST_CAMERA);可以实现鸿蒙上运行时权限的申请。

image.png

<uses-permission android:name="android.permission.INTERNET" />

image.png

image.png

由此，我们可以猜测鸿蒙应用在安装并解析manifest文件时将鸿蒙自定义的权限转换成了对应的android权限，然后在运行时申请权限时只需要做相应的权限转换即可。
所以，我们完全可以设法hook DevEco Studio打包时的gradle task，在manifest中添加我们需要声明的权限，然后在运行时反射拿到android context，然后就可以嗨皮的完成android的原生权限流程。

FA原子服务号

与RemoteViews的区别和联系

RemoteViews在Android上用于实现通知和桌面小部件，与卡片服务在跨进程展示view上有相似之处。
RemotViews将显示或更改UI的一系列行为封装成Parcelable对象，跨进程传递到launcher或systemUI进程，而这些进程都有对第三方app资源的访问权限，然后在这些进程通过包名会找到这些资源存放的目录，由此便完成了跨进程的资源传递。当通知或桌面组件需要更新时会通过BroadcastReceiver完成跨进程通信。

卡片服务的原理与此类似，只是将广播换成了Service+Binder来进行跨进程通信。

image.png

image.png

image.png

免安装与热更新

卡片服务号称具有免安装和热更的特性，但是根据以上分析，卡片服务本质上也存在apk安装的过程，特别是有四大组件或者权限的变更时还需要重新安装。但是由于apk只是作为一个壳，业务代码和资源都能实现动态加载，因此能达到较快的安装速度。

鸿蒙开源项目

鸿蒙开发者论坛

RemoteViews原理