Kuikly QA汇总
Kuikly QA汇总
Kuikly和以往跨平台框架有什么本质区别？
以往的跨平台技术通常是在原生之上构建中间层抹平平台差异，这个中间层或是虚拟机或是框架，不可避免会带来额外的成本：引入技术栈、非原生性能、框架场景受限、割裂的技术生态。Kotlin选择从编译产物的角度实现跨平台，它的编译产物与原生一致，打通了原平台技术生态，可以与存量库零成本互操作，以最小化可实现的方式在原工程中接入。这意味着统一的技术栈，原生的性能，融合的技术生态，源码级别的灵活性。 这个是Kuikly和其他跨平台框架本质差异，非虚拟机方案。
接入Kuikly, 安装包增量是多少呢?
- Android编译成AAR合入是0.3m。
- iOS 如果编译成.framework合入是1.2m，如果编译成JS合入是0.3m。
在业务落地情况如何?
Kuikly是腾讯广泛使用的跨端框架，已在15+APP落地500+页面，助力各业务通过跨端开发显著提效。随着鸿蒙平台的适配加速，未来将会发挥更大的价值。
Kuikly iOS的底层UI能力是UIKit吗？
是的, 底层渲染是使用iOS的UIKit。
我们之前也尝试过KMM在双端的复用，但是由于在ios端的一些调试、crash分析、产物生成等问题没有推广下去
- Android端编译生成AAR，这样保证了最原生的开发体验，也保证了性能，而且Kotlin/JVM是stable版本，稳定性有保证。如果有时需要在现网发布动态化能力的需求，我们编译成动态化产物下发。并且因为本地已有AAR版本，也有比较稳妥的降级措施，就是下发的动态化产物如果有问题会本地降级为已有的AAR；
- iOS因为KMM本身支持AS调试，所以我们本地开发时是可以在AS调试iOS的，跟原生调试没有区别，可以参考我们相关文章里的视频哈
kuikly渲染是使用native ui控件，那它如何解决两端UI的不一致性呢？
原生渲染有这个痛点，不过Kuikly针对这个问题，从框架设计之初，就着手这个问题进行了再设计，通过打薄native层，进行UI无逻辑化的原子组件暴露，kotlin跨平台层进行UI组件（即标签）逻辑封装调用，实现了最大化的一致性。
补充说明：大概的意思是，假如native层没有代码，理论一致性是100%，我们把native层的代码仅做原生原子控件的属性暴露，把原本类RN框架的原生封装UI组件标签的逻辑提到了kotlin跨平台层，实现了native层的ui无逻辑化。 其实原生渲染方案比较不一致的是高阶组件，而这部分组件，我们都是kotlin层实现的，没有让原生直接 映射提供组件，而是通过对齐原生对这些高阶组件的封装，在kotlin层。如：listView，瀑布流，轮播图，button等，都是kotlin组合封装的，相当于我们对齐原生的组件封装，在kotlin层进行封装，不直接让原生封装好直接提供，避免了原生侧有多余UI逻辑代码，最大程度减少了Native层代码，仅做UI原子属性暴露，然后组件封装统一提到Koltin跨平台层，所以相对于传统原生渲染跨平台框架来说，kuikly的原生渲染方案一致性已最大化。
Android同学无任何学习成本，那么iOS同学开发的话主要的学习成本在哪？
首先Kuikly使用的技术栈为：
- Kotlin开发语言：Kotlin作为安卓官方开发语言，对安卓同学可无缝上手，iOS同学需要另外学习，不过Kotiln和Swift都做为移动端原生现代化语言，其语法和设计相差不大，学过Swift的同学，看到Kotlin语言，还是触类旁通的
- Flex布局：2019年W3C 提出的方案----Flex 布局，可以简便、完整、响应式地实现各种页面布局。学习成本不高， 有一个1小时快速入门的教程：Flex 布局教程：语法篇 - 阮一峰的网络日志
- 声明式框架DSL：声明式在移动端都有对标框架，如安卓的Compose和iOS 的SwiftUI， 其声明式写法无本质区别，Kuikly基于Kotlin语法糖实现了一套类Compose和SwiftUI的声明式写法，所以该DSL的调试和开发同属于Kotlin语法层面技术成本
基于上述的3点，除了都需要掌握Flex布局和声明式写法外，iOS同学相对安卓同学，多出了一个学习Kotlin开发语言的成本（Kotlin和Swift语言相似）
Xcode如何调试Kotlin代码，是自己实现了一套插件还是有第三方的可用？
Xcode可以调试Kotlin代码，也可以AndroidStudio调试iOS平台的kolint代码，前者基于xcode-kotlin 插件，xcode-kotlin 插件允许直接从 Xcode 调试在 iOS 应用程序中运行的 Kotlin 代码，该插件为KCP生态提供的插件，非官方，也并非我们自己实现, 后者基于KMM插件（官方自带），可实现AS直接调试iOSApp。
Kotlin编译成iOS的framework后的堆栈还原是否有问题？
没问题，kotlin/native 编译的framework可完整还原堆栈，详情可参考官网文档（iOS framework模式堆栈翻译）
编译后的shared库，头文件庞大且无注释，目前是怎么处理的？
shared.framework的头文件内容包括Kotlin runtime类，Kuikly Core类、业务类，其中业务类是可以做到完全不导出在头文件中的，因为业务类不需要和原生直接交互，其交互通过KuiklyCore的CallNaitve/CallKotlin两个接口通信交互，所以接入层的业务方按理可以不理解share.framework的头文件。
同时，为了减少不必要的share.framework头文件导出，我们正在开发支持all-internal编译插件，通过编译时在业务类增加internal，避免业务类导出引起的产物增量。
既然已经可以用kotlin跨端，那么再进一步，是不是可以用kotlin.js再对接上前端呢
Kuikly已经支持小程序和 H5跨端，计划Q2开源
KMM的生态环境目前看还不那么成熟，如果有一些组件需要下沉到KMM层或者说遇到一些问题，目前是怎么解决的？
KMM作为后来者，生态上因发展时间较短尚还不具备其生态优势，不过基于KMM的多平台库也在快速丰富，可支撑业务常规第三方库需求，如网络库Ktor以及持久化缓存等, 详情可查看KMM生态组件
为了Kuikly能完全满足业务能力诉求（包括动态化诉求），我们和native生态实现融合，设计了一套可扩展的去中心化设计，业务方对于需要Native Api的场景下可通过Kuikly的扩展原生模块 来复用Native生态扩展Kuikly能力。
目前多业务场景深度使用后线上Crash数据有不？比较担心有一些特定平台下的Bug，只能等JB来解决
通过监控的crash数据来看，暂未发现KMM 相关的crash问题，已有crash为业务的代码基本为本身的安全性（如：？/！强解可空变量）crash
性能、单测Crash分析，目前有没有配套的工具？
Kuikly作为原生开发框架，理论配套开发工具可复用原生开发配套工具。如性能分析， 单测框架的使用以及分析
Kuikly响应式框架里的单项数据流是怎么做的，有可观测的工具不？
- Kuikly响应式原理同行业内的响应式框架类似，都为KVO模式，Kuikly利用了Kotlin的委托模式使得字段的读写时机可感知，在这个基础上实现了依赖收集和订阅分发。
- 若想观测其响应流向和过程，可通过AndroidStudo，对字段所在使用的区域进行断点调试，分析其调用栈来理解和分析响应过程，或以此来进行响应式问题调试。
非代理的情况下，Kuikly是否可完整实现logic层和data层的跨平台？（比如某个业务完整的网络请求，pb/jce数据的序列化，缓存，跳转和通信）
宿主非页面作为容器（局部使用Kuikly）有最佳实践不？（比如某个页面，其他都是原生的，Banner或者某个Section块需要用到Kuikly）
Kuikly提供给接入层的就是一个view粒度形式，所以可以把它简单当作如系统webview的概念来使用，该view粒度可用来页面级，也可以是嵌入其它原生场景的view级，两者的使用目前是一致的，无使用上的区别
注意
若在原生列表中嵌入Kuikly view，会因为Kuikly的异步机制，导致无法同原生列表其它卡片同时生存layout和view结果，造成显示上的不同步，我们后面也会排期提供同步机制来更好的和原生场景做嵌入使用，优化Kuikly卡片化使用场景